¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
¡Acceso ilimitado 24/7 a todos nuestros libros y vídeos! Descubra la Biblioteca Online ENI. Pulse aquí
  1. Libros
  2. Ansible
  3. Gestión de Kubernetes con ayuda de Ansible
Extrait - Ansible Administre la configuración de sus servidores y el despliegue de sus aplicaciones
Extractos del libro
Ansible Administre la configuración de sus servidores y el despliegue de sus aplicaciones Volver a la página de compra del libro

Gestión de Kubernetes con ayuda de Ansible

Objetivos del capítulo y requisitos

Kubernetes es una herramienta de gestión del ciclo de vida de los contenedores Docker. Este se asegura de que los contenedores tienen buena salud, están funcionando o utilizan la última versión de una aplicación.

La implementación de Kubernetes precisa de muchos conocimientos. En el ejercicio siguiente, todos los requisitos de acceso a un clúster deberán ser gestionados con anterioridad. Estos requisitos cubrirán los aspectos siguientes: 

  • Permisos de administrador en el clúster Kubernetes (o al menos en un espacio de nombres).

  • Presencia del archivo binario kubectl preconfigurado para el acceso al clúster. 

Una primera parte cubrirá un ejemplo simple de implementación. El resto del capítulo tratará sobre la creación de un operador Kubernetes. Este mecanismo permitirá definir los nuevos tipos de recursos (bases de datos, middleware de mensajería, etc.).

El conjunto de los ejercicios se basará en la aplicación Keycloak.

Introducción a la implementación de elementos  en Kubernetes

1. Contenedores y pods

Para poder funcionar, Kubernetes se apoya en la noción de contenedores. Sin embargo no utiliza directamente este mecanismo sino, más bien, la noción de pods. Esta opción representa la unidad mínima de tratamiento en la que Kubernetes trabaja.

2. Mecanismos de despliegue en Kubernetes

Los pods nunca se crean directamente. Estos últimos son gestionados gracias a recursos de más alto nivel, entre ellos se encuentran:

  • Los despliegues (objeto Deployment) para los contenedores de aplicaciones clásicos. 

  • Los conjuntos de estado (objeto StatefulSet) para las bases de datos o middlewares de mensajería.

  • Los conjuntos de demonios (objeto DaemonSet) para los agentes de monitoreo o la gestión de la red (si se tienen que implementar en todos los nudos de un clúster).

3. Despliegue de pods en Kubernetes

a. Keycloak

Keycloak es un portal de gestión de identidades. Una de sus características es soportar distintos proveedores de tipo OAuth2 (Google, Facebook, LinkedIn). También soporta el uso de tecnologías más tradicionales como un anuario LDAP/Active Directory.

Para saber más acerca de este programa, no dude en consultar la página web siguiente: https://www.keycloak.org/

b. Configuración de Keycloak

Red Hat ofrece una imagen oficial de Keycloak llamada jboss/keycloak. La versión utilizada en este ejercicio será la última (9.0.0).

En el momento del lanzamiento del contenedor se puede especificar el nombre del usuario de administración así como su contraseña. Estos parámetros se configuran gracias a las siguientes variables de entorno:

  • KEYCLOAK_USER: nombre del usuario de administración.

  • KEYCLOAK_PASSWORD: contraseña del usuario.

Para simplificar al máximo la configuración, estas dos variables se posicionarán con el valor «admin». El aspecto de persistencia gracias a una base de datos no será estudiado en este ejemplo.

Por defecto, Keycloak escucha en el puerto 8080.

c. Definición de un objeto StatefulSet

Se tiene que desplegar Keycloak gracias a un objeto de tipo StatefulSet. De hecho, Keycloak comprende la noción de clúster. Para que el ejemplo sea sencillo solo se iniciará un pod.

En Kubernetes...

Test del operador

1. Contexto

La creación del operador se ha terminado. Ahora solamente le queda ejecutarlo. Para ello el usuario tendrá que realizar las operaciones siguientes:

  • Aplicación de las definiciones del operador.

  • Construcción de la imagen del operador.

  • Despliegue del operador.

Estas operaciones son relativamente numerosas y complejas, y pueden ser fuente de errores. Con el objetivo de simplificar el procedimiento al máximo, se le mostrarán algunas técnicas que le permitan comprobar su operador sin tener que realizar un despliegue completo.

2. Definición del nuevo tipo de objeto

Los operadores han sido concebidos para lanzarlos en el interior de un clúster Kubernetes. Sin embargo, para su preparación, se aconseja lanzarlos directamente en la máquina usada para el desarrollo.

Lo primero que tendrá que hacer será crear un objeto CRD (Custom Resource Definition) para poder definir un nuevo tipo. El operador vigilará este nuevo tipo: en cada modificación, creación o supresión, el operador realizará las operaciones necesarias.

Como ya se vio anteriormente, esta definición se encuentra en el archivo keycloak.eni-editions.com_keycloaks_crd.yaml y en el directorio keycloak-operator/deploy/crds.

He aquí el contenido de este archivo:

apiVersion: apiextensions.k8s.io/v1beta1 
kind: CustomResourceDefinition 
metadata: 
 name: keycloaks.keycloak.eni-editions.com 
spec: 
 group: keycloak.eni-editions.com 
 names: 
   kind: Keycloak 
   listKind: KeycloakList 
   plural: keycloaks 
   singular: keycloak 
   shortNames: 
     - kc 
 scope: Namespaced 
 subresources: 
   status: {} 
 validation: 
   openAPIV3Schema: 
     type: object 
     x-kubernetes-preserve-unknown-fields: true 
 versions: 
 - name: v1 
   served: true 
   storage: true 

Ejecute este archivo para poder crear el nuevo tipo de objeto:

$ cd keycloak-operator/deploy/crds 
$ kubectl apply -f ./keycloak.eni-editions.com_keycloaks_crd.yaml 

3. Instalación de los requisitos

La ejecución del playbook realizada por un operador necesita...

Despliegue del operador

1. Contexto

El operador funciona correctamente fuera del clúster. Ahora es el momento de proceder a su despliegue. Este despliegue comprende las etapas siguientes:

  • Configuración del registro Docker.

  • Construcción y publicación de la imagen del operador.

  • Despliegue del operador.

  • Comprobación del despliegue.

Tenga en cuenta que a partir de ahora, el usuario deberá disponer de un registro de imágenes Docker. Los ejemplos que se le mostrarán estarán basados en el registro de imágenes de contenedor quay.io. No se tratará, sin embargo, la configuración de este espacio de almacenaje.

2. Configuración del registro Docker

La imagen estará almacenada en el espacio quay.io/yannig/keycloak-operator.

Para poder depositar la imagen, hay que conectarse al registro. Esta operación se hace gracias al comando docker seguido de las opciones siguientes:

  • La instrucción login.

  • La opción -u seguida de la cuenta que se utilizará.

  • La opción -p seguida de la contraseña del usuario.

  • Finalmente, la ubicación dónde conectarse.

He aquí el comando que tendrá que usar para conectar el usuario yannig al registro quay.io:

$ docker login -u="yannig" -p="my-password" quay.io 

En el caso de que la conexión se haga correctamente, obtendrá el siguiente retorno: 

WARNING! Using --password via the CLI is insecure. Use --password-stdin. 
WARNING! Your password will be stored unencrypted in /home/yannig/.docker/  
config.json. 
Configure a credential helper to remove this warning. See 
https://docs.docker.com/engine/reference/commandline/login/  
#credentials-store 
 
Login Succeeded 

La conexión al registro de imágenes está lista.

3. Construcción de la imagen del operador

La etapa siguiente consistirá en construir la imagen del operador. Esta construcción se realizará gracias al comando operator-sdk seguido de la opción build y del nombre de la imagen que se quiera construir.

En el caso de la imagen quay.io/yannig/keycloak-operator:v0.0.1, ejecute el comando siguiente:

$ operator-sdk build quay.io/yannig/keycloak-operator:v0.0.1 

Normalmente debería obtener la salida siguiente:

INFO[0000] Building OCI image quay.io/yannig/keycloak-operator 
Sending build context...