Como Instalar OCP 4.4.3 sobre VMWare 6.7 y … ¡ No morir en el intento !

Dic 23 2020
como-instalar-opc-sobre-vmw

Introducción

No hace mucho tiempo, se ha tenido la suerte de poder afrontar el reto de hacer una POC para instalar Openshift Container Platform sobre vSphere 6.7.0   en una plataforma on-premise que necesitaba evidencias de que Openshift podría solventar necesidades de seguridad entre aplicaciones y entornos que actualmente tienen en su infraestructura y son requisitos fundamentales para el óptimo aseguramiento del dato.

El reto además se hizo más grande al tener que solventar algunas dificultades a la hora de poder instalar, gracias a varias peculiaridades en la infraestructura de red, por lo que ha sido necesario a realizar una instalación de OCP un poco distinta pero muy interesante y que se va a exponer a continuación.

En este artículo se refleja todos los problemas que hemos encontrado en esta instalación (y los que te podrías encontrar) y que nos hubiese gustado disponer  como :

    • Configuración del HAProxy

    • Tipo DNSs necesarios

    • Gestión/administración certificados CSR de Kubernetes

    • Modificaciones necesarias de los ficheros yaml

    • Configuración de ficheros Ignition

    • Generación ISO modificada para RH CoreOS

Todos estos temas los verás resaltados con el símbolo 

Empezando…  lo primero saber qué necesitamos.

upi o ipiLa primera decisión que nos encontramos fue elegir entre instalación IPI (Installer Provisioned Infrastructure) o UPI (User Provisioned Infrastructure)  y para VMWare solo podíamos elegir UPI para la versión OCP 4.4.3 (versión estable en ese momento, a fecha de este post está disponible la versión 4.6 ).  Además, nos vimos obligados a realizarla de tipo bare-metal, pero apoyada en vSphere 6.7.0u3. En términos generales, se ha seguido la documentación oficial de Red Hat.

Para este tipo de instalaciones OCP necesita 1 nodo de arranque temporal (bootstrap) , 3 nodos maestros (masters) y 2 nodos workers, en nuestro caso se han montado 4 workers.

Además, existen otros componentes necesarios para este tipo de instalación de OCP, como son un servidor de DHCP, un servidor que actuará como balanceador (HAProxy) y además contendrá un servidor web (Apache) para servir los ficheros de instalación. También se ha creado un servidor de apoyo (HAHelper) desde donde se ejecutarán todos los comandos y generación de la instalación.

DNS

Openshift Container Platform basa todo su funcionamiento en DNS, por lo que se necesita que se generen todos los DNS que se muestran en la Tabla 1. Es de vital importancia que estén verificados antes de continuar la instalación, o por lo contrario, la instalación fallará.

 

[atsistemas@hahelper ~]$ dig *.apps.openshift.atsistemas.at +short

10.52.153.200

[atsistemas@hahelper ~]$ dig api.openshift.atsistemas.at +short

10.52.153.200

[atsistemas@hahelper ~]$ dig api-int.openshift.atsistemas.at +short

10.52.153.200

[atsistemas@hahelper ~]$ dig master0.openshift.atsistemas.at +short

10.52.153.205

[atsistemas@hahelper ~]$ dig master1.openshift.atsistemas.at +short

10.52.153.206

[atsistemas@hahelper ~]$ dig master2.openshift.atsistemas.at +short

10.52.153.207

[atsistemas@hahelper ~]$ dig worker0.openshift.atsistemas.at +short

10.52.153.208

[atsistemas@hahelper ~]$ dig worker1.openshift.atsistemas.at +short

10.52.153.209

[atsistemas@hahelper ~]$ dig worker2.openshift.atsistemas.at +short

10.52.153.210

[atsistemas@hahelper ~]$ dig worker3.openshift.atsistemas.at +short

10.52.153.211

[atsistemas@hahelper ~]$ dig etcd-0.openshift.atsistemas.at +short

10.52.153.205

[atsistemas@hahelper ~]$ dig etcd-1.openshift.atsistemas.at +short

10.52.153.206

[atsistemas@hahelper ~]$ dig etcd-2.openshift.atsistemas.at +short

10.52.153.207

[atsistemas@hahelper ~]$ dig _etcd-server-ssl._tcp.openshift.atsistemas.at SRV +short

0 10 2380 etcd-2.openshift.atsistemas.at

0 10 2380 etcd-0.openshift.atsistemas.at

0 10 2380 etcd-1.openshift.atsistemas.at

 

A continuación, se muestra una tabla con los componentes utilizados durante esta instalación de OPC.

Tabla 1.

Host

IP

DNS Tipo A

DNS Tipo SRV

Descripción

haproxy.atsistemas.at

10.000.000.200

api.openshift.atsistemas.at

api-int.openshift.atsistemas.at

*.apps.openshift.atsistemas.at

 

MV HAProxy

hahelper.atsistemas.at

10.000.000.201

   

MV Instalación

bootstrap

10.000.000.202

bootstrap.openshift.atsistemas.at

 

MV Bootstrap

master0

master1

master2

10.000.000.205

10.000.000.206

10.000.000.207

master0.openshift.atsistemas.at

master1.openshift.atsistemas.at

master2.openshift.atsistemas.at

etcd-0.openshift.atsistemas.at

etcd-1.openshift.atsistemas.at

etcd-2.openshift.atsistemas.at

 

etcd-server-ssl._tcp.openshift.atsistemas.at

etcd-server-ssl._tcp.openshift.atsistemas.at

etcd-server-ssl._tcp.openshift.atsistemas.at

MVs Control Plane

worker0

worker1

worker2

worker3

10.000.000.208

10.000.000.209

10.000.000.210

10.000.000.211

worker0.openshift.atsistemas.at

worker1.openshift.atsistemas.at

worker2.openshift.atsistemas.at

worker3.openshift.atsistemas.at

 

MVs Worker

 

HAProxy

Se ha elegido HAProxy como el balanceador de carga utilizado en esta instalación. Este componente será el encargado de redirigir y distribuir las peticiones que se realicen sobre el clúster de Openshift.

Para su instalación, se ha generado una MV con RH 7 con la configuración de red indicada en la tabla de la infraestructura. En dicha MV se ha instalado HAProxy y se ha configurado de la siguiente manera:

Atención a la configuración del HAProxy , es clave para que la instalación de OCP funcione.

#---------------------------------------------------------------------

# Global settings

#---------------------------------------------------------------------

global

    log         /etc/haproxy/haproxy.log local0 info

    chroot      /var/lib/haproxy

    pidfile     /var/run/haproxy.pid

    maxconn     20000

    user        haproxy

    group       haproxy

    daemon

 

    # turn on stats unix socket

    stats socket /var/lib/haproxy/stats

#---------------------------------------------------------------------

# common defaults that all the 'listen' and 'backend' sections will

# use if not designated in their block

#---------------------------------------------------------------------

defaults

    mode                    http

    log                     global

    option                  httplog

    option                  dontlognull

    option http-server-close

    option forwardfor       except 127.0.0.0/8

    option                  redispatch

    retries                 3

    timeout http-request    10000ms

    timeout http-keep-alive 10000ms

    timeout check           10000ms

    timeout connect         40000ms

    timeout client          300000ms

    timeout server          300000ms

    timeout queue           50000ms

    maxconn                 20000

#---------------------------------------------------------------------

# stats cluster

#---------------------------------------------------------------------

listen stats

    bind :9000

    stats uri /stats

    #monitor-uri /healthz

    monitor-uri /readyz

    option  httpchk GET /readyz HTTP/1.0

    stats refresh 30000ms

#---------------------------------------------------------------------

# frontend to OpenShift K8s API Server                                  1

#---------------------------------------------------------------------

frontend openshift-api-server

    bind *:6443

    default_backend openshift-api-server

    mode tcp

 

#---------------------------------------------------------------------

# backend to OpenShift K8s API Server                                   1

#---------------------------------------------------------------------

backend openshift-api-server

    balance source

    mode tcp

    server bootstrap  10.000.000.202:6443 check

    server master0  10.000.000.205:6443 check

    server master1  10.000.000.206:6443 check

    server master2  10.000.000.207:6443 check

 

#---------------------------------------------------------------------

# frontend to OpenShift Machine Config Server                           2

#---------------------------------------------------------------------

frontend machine-config-server

    bind *:22623

    default_backend machine-config-server

    mode tcp

 

 

#---------------------------------------------------------------------

# backend to OpenShift Machine Config Server                            2

#---------------------------------------------------------------------

backend machine-config-server

    balance source

    mode tcp

    server bootstrap 10.000.000.202:22623 check

    server master0  10.000.000.205:22623 check

    server master1  10.000.000.206:22623 check

    server master2  10.000.000.207:22623 check

 

 

frontend ingress-http                                                   3

    bind *:80

    default_backend ingress-http

    mode tcp

    option tcplog

 

backend ingress-http                                                    3

    balance source

    mode tcp

    server worker0 10.000.000.208:80 check

    server worker1 10.000.000.209:80 check

    server worker2 10.000.000.210:80 check

    server worker3 10.000.000.211:80 check

 

frontend ingress-https                                                  4

    bind *:443

    default_backend ingress-https

    mode tcp

    option tcplog

 

backend ingress-https                                                   4

    balance source

    mode tcp

    server worker0 10.000.000.208:443 check

    server worker1 10.000.000.209:443 check

    server worker2 10.000.000.210:443 check

    server worker3 10.000.000.211:443 check

 

 

En el fichero se pueden encontrar 4 bloques diferenciados (cada uno con su frontend y backend):

  1. Openshift-api-server (puerto 6443): utilizado por los masters y bootstrap para exponer la API de Kubernetes y realizar los health check
  2. Machine-config-server (puerto 22623): utilizado por los masters y bootstrap para realizar la inicialización del cluster
  3. Ingress-http (puerto 80): utilizado por los workers para habilitar el tráfico HTTP en los Pods
  4. Ingress-https (puerto 443): utilizado por los workers para habilitar el tráfico HTTPS en los Pods

Una vez configurado el HAProxy, se podrá acceder mediante URL al estado de los componentes y sus estadísticas. Será muy útil durante la instalación del clúster de Openshift, ya que se podrá comprobar el estado de los Control Plane y Workers accediendo a la URL 10.000.000.200:9000/stats

 

Servidor Web (Apache)

Otro componente utilizado durante esta instalación ha sido Apache. Este servidor web se utiliza para que, durante la instalación, tanto los Control Plane como los Worker puedan recibir los ficheros de configuración necesarios para su inicialización.

Se ha reutilizado la MV determinada para el HAProxy y se ha configurado para que desde los componentes que forman el clúster puedan descargarse los ficheros Ignition (ficheros de configuración del clúster) y además para que pueda descargar la imagen comprimida del SO Red Hat CoreOS.

 

Install-config & Manifest & Ignition

El siguiente paso es generar los ficheros Manifest de Kubernetes y los ficheros de Ignition para las configuraciones de encendido para cada nodo.

    1. install-config.yaml  

La instalación de Openshift se basa en un fichero de instalación install-config.yaml  donde se proporciona a Openshift todos los parámetros necesarios para la generación de los ficheros de Manifest y de Ignition.

 

[ansiblebot@hahelper ~]$ cat install-config.yaml

apiVersion: v1

## The base domain of the cluster. All DNS records will be sub-domains of this base and will also include the cluster name.

baseDomain: atsistemas.at 1

proxy: 2

  httpProxy: http://{{URL_PROXY}}

  httpsProxy: http://{{URL_PROXY}}

  noProxy: {{URLS_NO_PROXY}}

imageContentSources: 3

- mirrors:

  - registry.lab.variantweb.net/ocp/release

  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev

- mirrors:

  - registry.lab.variantweb.net/ocp/release

  source: registry.svc.ci.openshift.org/ocp/release

- mirrors:

  - registry.svc.ci.openshift.org/ocp/release

  source: registry.svc.ci.openshift.org/ocp/release

compute:

- name: worker

  replicas: 4  4

controlPlane:

  name: master

  replicas: 3

metadata:

  ## The name for the cluster

  name: openshift

platform:

  vsphere:  5

    ## The hostname or IP address of the vCenter

    vCenter: {{NOMBRE_VCENTER}}

    ## The name of the user for accessing the vCenter

    username: {{USUARIO_VCENTER}}

    ## The password associated with the user

    password: {{PASSWORD_VCENTER}}

    ## The datacenter in the vCenter

    datacenter: {{NOMBRE_DATACENTER}}

    ## The default datastore to use.

    defaultDatastore: {{NOMBRE_DEFAULT_DATASTORE}}

## The pull secret that provides components in the cluster access to images for OpenShift components.

pullSecret: '{"auths":{.....}}'  6

## The default SSH key that will be programmed for `core` user.i

sshKey: 'ssh-rsa AAAA......'  7

 

1.- Dominio base que tendrán todos los DNS

2.- Definición del proxy (si fuera necesario) y de las URLs o IPs que no quiera que acudan al proxy.

3.- Mirror para los ImageRegistry que quiera añadir

4.- Numero de Replicas workers (0 para no limitar) y master debe de tener 3 réplicas como mínimo

5.- Definición de los parámetros para vSphere

6.- Pull Secret que obtendremos de Red Hat al obtener la licencia de OCP.

7.- La clave SSH generada para conectarnos con usuario core en Red Hat Enterprise Linux CoreOS (RH CoreOS), del bootstrap y master.

Este fichero se destruye en la generación de los ficheros de Manifest, por lo que cópialo a la ruta donde vayas a ejecutar la instalación.

    1.  Ficheros de Manifest de Kubernetes

Para la generación de los ficheros de Manifest , se utiliza el ejecutable de Openshift openshift-install proporcionado para esta versión.

[atsistemas@hahelper ~]$ ./openshift-install create manifests

WARNING There are no compute nodes specified. The cluster will not fully initialize without compute nodes.

INFO Consuming "Install Config" from target directory

 

 

Después de generar dichos ficheros de Manifest hay que modificar algunos de ellos y es aquí donde hay una de esas trampas que nosotros nos pegamos y que no se olvidan.

Modificaremos los ficheros:

      1. cluster-scheduler-02-config.yml

cambiaremos la propiedad mastersSchedulable False

      1. También editamos los ficheros 
        • openshift/99_openshift-machineconfig_99-master-ssh.yaml
        • openshift/99_openshift-machineconfig_99-worker-ssh.yaml
        • manifest/Cluster-config.yaml

Aquí deberemos de comprobar y corregir los saltos de línea en las claves ssh-key añadidas en estos ficheros (si los hay).

 

    1. Creación de los ficheros de ignition.

Después de crear y modificar los ficheros de Manifest estamos en predisposición de generar los ficheros de Ignition para la instalación, para ello se utiliza el mismo ejecutable de Openshift openshift-install, pero con distintos parámetros.

 

 

[atsistemas@hahelper ~]$ ./openshift-install create ignition-configs

 

 

                        Deberemos de ver que se ha generado una estructura similar a esta:

├── auth

│   ├── kubeadmin-password

│   └── kubeconfig

├── bootstrap.ign

├── master.ign

├── metadata.json

└── worker.ign        

 

Guarda la carpeta auth porque será utilizada más tarde para poder conectarnos por el cliente.

    1. Copia de los ficheros de ignition al servidor web apache

Ahora copiaremos los ficheros de Ignition generados al servidor web Apache para que las MV, en momentos de arranque, encuentren dichos ficheros e inicialicen los servers CoreOS.

 

 

[atsistemas@hahelper ~]$ scp *.ign haproxy:/var/www/html/ignition/

 

Imagen ISO Red Hat CoreOS.

Como se ha comentado a lo largo del documento, el SO utilizado por los componentes del clúster de Openshift es Red Hat CoreOS. RED

Al tratarse de una instalación en VMWare, se ha procedido a modificar la ISO que Red-Hat proporciona para que durante la instalación del SO dependiendo del componente a instalar se configure con sus ficheros Ignition correspondientes. Se esta manera, se utiliza el servidor Apache como servidor de ficheros para el clúster.

Para ello, se ha descargado de la web oficial de Red Hat la  ISO de CoreOS y se ha realizado los siguientes pasos:

 

  1. Primero montamos la ISO en local:

 

 

[atsistemas@hahelper ~]$ sudo mount -o loop rhcos-installer.x86_64.iso rhcos-4.3.3 <directorio>

 

 

  1.  En el directorio /isolinux se ha modificado el fichero isolinux.cfg. Se ha añadido un label por cada uno de los componentes del cluster de Openshift. En cada uno, según el tipo, irá al servidor Apache a descargarse sus ficheros correspondientes. Además, se ha establecido la configuración de red necesaria (IP, Gateway, NetMask , tarjeta de red, Hostname y servidor DNS). A continuación, se muestra como quedaría el label para instalar el bootstrap

 

Será necesario añadir un label por componente. Cada uno con su configuración específica.

 

label bootstrap

  menu label ^Install bootstrap

  kernel /images/vmlinuz

  append initrd=/images/initramfs.img nomodeset rd.neednet=1 coreos.inst=yes coreos.inst.install_dev=sda coreos.inst.image_url=http://10.000.000.200:8080/install/rhcos-metal.x86_64.raw.gz coreos.inst.ignition_url=http://10.000.000.200:8080/ignition/bootstrap.ign ip=10.000.000.202::10.000.000.255:255

.255.255.128:bootstrap.openshift.atsistemas.at:ens192:none nameserver=10.52.157.2 nameserver=10.52.157.3

 

  1. Generamos la nueva ISO modificada

 

 

sudo mkisofs -U -A rhcos-4.4.3 -V rhcos-4.4.3 -volset rhcos-4.4.3 -J -joliet-long -r -v -T -x ./lost+found -o ~/rhcos-4.4.3.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot -e images/efiboot.img -no-emul-boot .

 

 

 

  1. Por último, debemos de guardar la nueva ISO en el almacén de datos de VMWare, de esta manera, se podrá utilizar a la hora de la creación de las MV.

 

Creación de la MV en VMWARE

Ahora tenemos que generar las máquinas virtuales en VMWare. Para ello, es recomendable disponer de un Datacenter específico para el clúster de Openshift.

 

Previamente, se tiene que haber configurado el DCHP para la asignación de las IP´s de forma consecutiva, y así coincidan con las IPs indicadas en la Tabla 1.

 

A continuación, se muestran los pasos a seguir para la creación de la MV bootstrap (para el resto de MV que componen el clúster será igual cambiando los requerimientos mínimos indicados por Red Hat).

Se procede a crear la MV con el asistente y ubicarla dentro del Datacenter creado para Openshift.

indicar un nombre a la máquina virtual

 

En la sección de S.O. deberemos de seleccionar Red Hat Enterprise Linux 7 (64 bits), aunque luego vayamos a montar un CoreOS.

 

 

En el apartado de Hardware es necesario establecer los requisitos de CPU, RAM y Disco Duro siguiendo los parámetros recomendados por Red Hat. Es necesario configurar la MV para que utilice la ISO de CoreOS que ha debido ser cargada en almacén de datos de VMWare.

seleccionar el tipo de máquina virtual

La imagen ISO, se encuentra en el almacén de datos. Debe ser seleccionada y deber ser habilitada la opción “Conectar al encender”

 

añadimos openshitf

 

En el apartado de Hardware también debe añadirse un parámetro necesario para Kubernetes. Este parámetro permite disponer un UUID consistente para la MV. Se introduce en el apartado Opciones de Máquina Virtual -> Avanzado -> Editar Configuración

personalizar hardware de la máquina virtual

 

El nombre del parámetro que se introduce es disk.EnableUUID y el valor será TRUE.

 

parámetros máquina virtual

 

 

Finalizada esta configuración ya se ha generado la MV bootstrap (Igual para el resto de MV). Una vez creadas todas las MV necesarias para el clúster de Openshift, se deben arrancar para instalar el SO RH CoreOS.

 

Se ha configurado la ISO para que al arrancar el SO se solicite al usuario qué tipo de instalación se va a realizar (bootstrap, master/control plane o worker).

El menú es como el que se muestra a continuación:

nos saldrá un menú

Instalación.

Después de conseguir todas las tareas previas a la instalación, ahora se está en disposición de finalizar instalación inicializando el clúster de OCP.

Para ello ejecutaremos el siguiente comando:

 

[atsistemas@hahelper]$ ../openshift-install wait-for bootstrap-complete --log-level=debug

DEBUG OpenShift Installer 4.4.3

DEBUG Built from commit 78b817ceb7657f81176bbe182cc6efc73004c841

INFO Waiting up to 30m0s for the Kubernetes API at https://api.openshift.atsistemas.at:6443...

INFO API v.1.17.2 up

INFO Waiting up to 30m0s for bootstrapping to complete...

DEBUG Bootstrap status: complete

INFO It is now safe to remove the bootstrap resources

 

Ahora antes de terminar la instalación del OCP, tenemos que comprobar que todos los CSR están en Approved , por lo que comprobaremos con el comando.

 

Esta acción la deberemos de completar antes de 24h, sino el clúster de Kubernetes dejará de funcionar y será necesario volver a empezar la instalación.

 

 

[atsistemas@hahelper ~]$ oc get csr

 

 

Si nos sale algún certificado como Pending, debemos aprobarlo con el comando.

 

 

[atsistemas@hahelper ~]$ oc adm certificate approve <nombre_csr>

 

Además, comprobaremos que los nodos están Ready, para completar la instalación.

 

[atsistemas@hahelper ~]$ oc get nodes

 

           

NAME                              STATUS    ROLES    AGE   VERSION

master0.openshift.atsistemas.at   Ready     master   57d   v1.17.1

master1.openshift.atsistemas.at   Ready     master   57d   v1.17.1

master2.openshift.atsistemas.at   Ready     master   57d   v1.17.1

worker0.openshift.atsistemas.at   Ready     worker   57d   v1.17.1

worker1.openshift.atsistemas.at   Ready     worker   57d   v1.17.1

worker2.openshift.atsistemas.at   Ready     worker   57d   v1.17.1

worker3.openshift.atsistemas.at   Ready     worker   57d   v1.17.1

Ahora finalizaremos la instalación del OCP con el comando:

 

[atsistemas@hahelper ~]$ openshift-install wait-for install-complete --log-level=debug

 

Deberá de devolver un mensaje parecido a este, con la URL de la consola y la pass del kubeadmin para poder acceder la primera vez:

 

[atsistemas@hahelper]$ ../openshift-install wait-for install-complete --log-level=debug

DEBUG OpenShift Installer 4.4.3

DEBUG Built from commit 78b817ceb7657f81176bbe182cc6efc73004c841

DEBUG Fetching Install Config...

DEBUG Loading Install Config...

DEBUG   Loading SSH Key...

DEBUG   Loading Base Domain...

DEBUG     Loading Platform...

DEBUG   Loading Cluster Name...

DEBUG     Loading Base Domain...

DEBUG     Loading Platform...

DEBUG   Loading Pull Secret...

DEBUG   Loading Platform...

DEBUG Using Install Config loaded from state file

DEBUG Reusing previously-fetched Install Config

INFO Waiting up to 30m0s for the cluster at https://api.openshift.atsistemas.at:6443 to initialize...

DEBUG Cluster is initialized

INFO Waiting up to 10m0s for the openshift-console route to be created...

DEBUG Route found in openshift-console namespace: console

DEBUG Route found in openshift-console namespace: downloads

DEBUG OpenShift console route is created

INFO Install complete!

INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/atsistemas/poc-install-ignition/auth/kubeconfig'

INFO Access the OpenShift web-console here: https://console-openshift-console.apps.openshift.atsistemas.at

INFO Login to the console with user: kubeadmin, password: N0h3-mu3rt0-3n3l-1nt3nt0

 

            Ahora deberíamos de tener acceso a Openshift :

acceso a openshift

 

Ahora haremos login con el usuario kubeadmin y comprobaremos que el clúster está totalmente operativo.

login usuario kubeadmin y comprobaremos que el clúster está totalmente operativo.

Conclusión

En este articulo hemos visto que instalar Openshift Container Platform sobre VMWare  no es una tarea imposible si eres metódico en los pasos que marca la documentación oficial de RedHat y además tienes conocimiento tanto de Linux, comunicaciones y Kubernetes. 

Además, si sigues los trucos que se han comentado en este artículo, seguro que consigues finalizar la instalación con éxito.

Esperamos ( Roberto y Adolfo  ) que os ayude en el reto de instalar OCP sobre VMWare.

 

 

Adolfo del Pino López

Roberto Iglesias Castro


Comparte este artículo

Utilizamos cookies propias y de terceros para ofrecerte una mejor experiencia y servicio, dentro de nuestra Web de acuerdo a tus hábitos de navegación. Si continúas navegando, consideramos que aceptas expresamente su utilización. Puedes obtener más información de cómo gestionar y configurar las cookies en nuestra Política de Cookies.