Lección 222: Spring Cloud Config: cómo gestionar configuraciones de forma centralizada

En la última clase vimos por qué hace falta gestionar configuraciones de forma centralizada y conocimos Spring Cloud Config. Hoy desgranaremos cómo funciona por dentro y nos prepararemos para la práctica.

Cómo funciona Spring Cloud Config por dentro

¿Recuerdas que hablamos de Config Server y Config Client? Vamos a ver cómo se comunican estos colegas entre sí.

El esquema de funcionamiento es así:

• Git u otro repositorio almacena las configuraciones
• Config Server las lee y las expone vía REST API
• Los microservicios, con ayuda de Config Client, piden sus ajustes

Cómo funciona Spring Cloud Config por dentro

¿Recuerdas que hablamos de Config Server y Config Client? Imagínate que Config Server es como un bibliotecario sabio que sabe dónde están todos los libros (las configuraciones). Y Config Client son los lectores (nuestros microservicios), que vienen y piden sus libros.

El esquema de funcionamiento es bastante simple:

[Git/Archivos] <--- [Config Server] <--- [Microservicios]
Almacenamiento     REST API + lógica    Config Client

Dónde guardar las configuraciones

Spring Cloud Config puede trabajar con diferentes repositorios. Vamos a ver sus pros y contras.

Repositorio Git

Ejemplo de estructura del repositorio:

configs/
  ├── application.yml         # Configuración común
  ├── order-service.yml       # Configuración para pedidos
  └── payment-service.yml     # Configuración para pagos

Sistema de archivos

Para quienes prefieren todo más sencillo

• Simplemente una carpeta con archivos
• Ideal para desarrollo y experimentos
• Sin flujo de Git
• Úsalo solo para pruebas

Cómo Config Server entrega las configuraciones

Config Server funciona como un REST API. Imagina que es el catálogo de la biblioteca:

GET /{aplicación}/{perfil}/{versión}

Por ejemplo:

GET /order-service/prod/main

Es como decir: "Dame la configuración para el servicio de pedidos, entorno de producción, la última versión". Y en respuesta recibirás algo como:

{
    "name": "order-service",
    "profiles": ["prod"],
    "properties": {
        "database.url": "jdbc:postgresql://prod-db:5432/orders",
        "kafka.brokers": "kafka1:9092,kafka2:9092"
    }
}

Características útiles de Spring Cloud Config

Puedes crear configuraciones comunes para todos los servicios y sobrescribirlas para casos concretos:

# application.yml - configuración común
logging:
  pattern: "%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n"

# order-service.yml - configuraciones específicas
logging:
  level: DEBUG  # ¡Para el servicio de pedidos necesitamos más logs!

La seguridad ante todo

Spring Cloud Config puede cifrar datos secretos. Se ve más o menos así:

# Configuración habitual
database:
  url: jdbc:postgresql://localhost:5432/myapp
  username: postgres
  password: {cipher}AQA6EN7aXNXrBFBEpw==

¿Has visto {cipher}? Eso significa que la contraseña está cifrada. Config Server la descifrará antes de enviársela al cliente.

Integración con Spring Security

Config Server se puede (¡y debería!) proteger:

spring:
  security:
    user:
      name: configuser
      password: {cipher}AQB6yvk+yL...

Y para distintos equipos puedes configurar distintos permisos:

• El equipo de desarrollo ve las configuraciones dev
• El equipo de soporte ve prod
• Y que el becario trabaje con el entorno de pruebas

HashiCorp Vault para casos especiales

Cuando el cifrado normal no basta, sacamos la artillería pesada — HashiCorp Vault:

• Almacena los secretos por separado de las configuraciones
• Cambia contraseñas automáticamente
• Lleva auditoría del acceso a los secretos

Qué hay que recordar

1. Orden de carga de las configuraciones

Config Server carga los ajustes en este orden:

1. Ajustes generales (application.yml)
2. Ajustes del servicio (order-service.yml)
3. Ajustes por perfil (order-service-prod.yml)

Las configuraciones posteriores sobrescriben a las anteriores. Como en CSS, ¿recuerdas?

2. Tolerancia a fallos

¿Qué hacer si Config Server deja de estar disponible? Hay opciones:

• Cachear las configuraciones localmente
• Usar valores por defecto
• Tener réplicas de Config Server

Lo importante es planearlo con antelación, ¡no durante la caída del prod!

3. Monitorización

Qué vigilar en Config Server:

• Número de peticiones a las configuraciones
• Tiempo de respuesta del servidor
• Errores al obtener ajustes
• Historial de cambios en las configuraciones

La próxima vez

Pasaremos de la teoría a la práctica:

• Levantaremos nuestro propio Config Server
• Lo conectaremos a Git
• Configuraremos el servicio cliente
• Aprenderemos a actualizar configuraciones "en caliente"

Y recuerda: una buena configuración es como un buen código. Hay que revisarla, testearla y protegerla.