Acelerando los desarrollos con contenedores : Keycloak (Parte 2)

Publicado por Víctor Madrid el

Arquitectura de SolucionesKeycloakIAMIdPPersistenciaPostgresql

En este segundo artículo se va a mostrar cómo poder disponer de un contenedor de Keycloak con la característica de persistencia en base de datos.

Aconsejo leer el primer artículo para entender algunos conceptos y ciertos aspectos de la configuración y uso de Keycloak ;-)

Este artículo está dividido en 4 partes:

  • 1. Introducción
  • 2. Stack Tecnológico
  • 3. Ejemplos de Uso
  • 4. Conclusiones

1. Introducción

En este apartado se tratarán los siguiente puntos:

  • 1.1. Introducción al uso de contenedores como aceleradores del desarrollo
  • 1.2. ¿Qué necesidades tenemos para tener un "Keycloak" con contenedores?

1.1. Introducción al uso de contenedores como aceleradores del desarrollo

Para centralizar esta información en un único punto y así poder facilitar su consulta se ha diseñado un artículo específico

1.2. ¿Qué necesidades tenemos para requerir un "Keycloak" con contenedores (y persistencia)?

Los motivos principales que me llevaron a tratar de investigar en tener un Keycloak dentro de un contenedor fueron los siguientes:

  • Disponer de una instalación inmutable
  • Replicar la instalación del producto del cliente en local (versionado, entorno, etc.)
  • Minimizar en un entorno previo los posibles cambios de configuración que pudiéramos requerir --> Perdiendo el miedo a los cambios :-)
  • Asegurarse de que a todo el mundo le funcionaba de primeras
  • Ayudar al equipo a coger experiencia en el uso de Keycloak
  • Disponer en el entorno local de la misma pieza que se utilizará en entornos altos
  • Investigar previamente cómo funciona su API de integración
  • Ayudarme a establecer cierta lógica de negocio, gestión de errores sobre la pieza de desarrolla que contenga la integración

Y en concreto con persistencia de base de datos:

  • Poder persistir los cambios que realiza uno (guardar configuración previa, disponer de usuarios, etc.)
  • Poder integrarse con diferentes bases de datos (h2, oracle, mariadb, postgres, etc.)
  • ...

2. Stack Tecnológico

Este es stack tecnológico elegido para implementar la funcionalidad "Keycloak":

  • Docker - Tecnología de Contenedores/Containers
  • Docker Hub - Repositorio de Docker Público donde se ubican las imágenes oficiales
  • Keycloak - Herramienta IAM / IdP
  • Postgresql - Base de datos relacional

3. Ejemplos de Uso

Para enseñar a utilizarlo y así practicar se ha habilitado un repositorio, este repositorio se reutilizará para otros artículos de "Acelerando los desarrollos con contenedores".

La parte de que tiene que ver con este artículo se encuentra en el apartado de docker/keycloak/basic-with-persistence

Este proyecto consta del siguiente elemento:

  • Contenedor de Keycloak con persistencia en base de datos
  • Proporciona la instalación del producto en la versión establecida o bien en la última versión disponible en Docker Hub
  • Proporciona la configuración para su uso (usuarios, password, etc.) con una cuenta del tipo admin mediante variables de entorno (esta funcionalidad esta proporcionada por el propio contenedor)
  • Proporciona la configuración para ver trazas de depuración
  • Proporciona las variables de entorno para configurar la base de datos propuesta
  • Proporciona la base de datos seleccionada (en este caso postgres), su configuración y la definición de un volumen para persistencia

Ejemplo de fichero "docker-compose.yaml"

version: '3'  
services:

  db:
    #image: postgres
    image: postgres:14.2
    environment: 
      POSTGRES_DB: keycloakdb
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
    ports:
      - '5432:5432'
    volumes:
      - ./db:/var/lib/postgresql/data

  keycloak:
    #image: jboss/keycloak
    image: jboss/keycloak:16.1.0
    environment:
      DB_VENDOR: POSTGRES
      DB_ADDR: db
      DB_DATABASE: keycloakdb
      DB_USER: postgres
      DB_PASSWORD: postgres
      KEYCLOAK_USER: admin
      KEYCLOAK_PASSWORD: password
      #KEYCLOAK_LOGLEVEL: DEBUG
      #ROOT_LOGLEVEL: DEBUG
    ports:
      - '8083:8080'
    depends_on:
      - db

volumes:  
  db:
    driver: local

Para ver como lanzarlo ver fichero README dentro del proyecto.

3.1. Scripts de Soporte

N/A

3.2. Investigar lo que se usa

Cuando uno crea un contenedor basado en una imagen, ya se ha visto que consideraciones se deben tener para llegar a entender que es lo que hace.

Si tienes alguna duda vuelve a revisar el apartado "Soporte de Análisis de Contenedores" del artículo de introducción : Acelerando los desarrollos con contenedores: Introducción

Ejemplo de ejecución para mostrar la información del proceso ejecutado tras realizar un "up"

Ejemplo de inspección sobre el contenedor creado

Ejemplo de investigación general dentro del contenedor

Se podrán validar algunos de los aspectos configurados.

3.3. Verificar resultados

Se accede a la URL del Keycloak con:

http://localhost:8083/  

Accediendo a la consola de administración (Administration Console)

Verificando el acceso con el usuario declarado en las variables de entorno

3.4. Preparación de la Configuración

Si se quiere tener una configuración inicial se aconseja seguir la indicada en el primer artículo

3.5. Probar la persistencia

Pasos a seguir:

  • Arrancar el fichero docker-compose proporcionado
  • Acceder a la plataforma con el usuario admin utilizado (si es necesario)
  • Acceder a la opción "Users"
  • Pulsar sobre el botón "Add user" de la cabecera de la tabla
  • Establecer el id : user-temp
  • Pulsar sobre el botón "Save"
  • Verificar que aparece disponible en la tabla de usuarios
  • Para el fichero docker-compose
  • Arrancar el fichero docker-compose proporcionado
  • Acceder a la plataforma con el usuario admin utilizado (si es necesario)
  • Acceder a la opción "Users"
  • Verificar que sigue existiendo el usuari "user-temp"
  • NOTA: Acordaros de borrarlo porque no va a servir para nada

4. Conclusiones

En este caso mis conclusiones serán muy rápidas, son todas las mismas que las indicadas en el primer artículo, pero con la posibilidad de poder persistir todas las configuraciones que vayamos haciendo para adaptar la herramienta a las necesidades del proyecto o de la organización.

Espero que os haya gustado y sobre todo que os sea de utilidad.

Si te ha gustado, ¡síguenos en Twitter para estar al día de próximos posts!

Autor

Víctor Madrid

Líder Técnico de la Comunidad de Arquitectura de Soluciones en atSistemas. Aprendiz de mucho y maestro de nada. Técnico, artista y polifacético a partes iguales ;-)