Desplegando ms-modules: Agrupando la Funcionalidad del Ecosistema

Jul 22, 2025 - 5 min read - 629 words

Con nuestros servicios base y de catálogos ya en funcionamiento, damos el siguiente paso lógico en la construcción de nuestra plataforma: definir las agrupaciones funcionales de nuestra aplicación. Para esta tarea, desplegaremos ms-modules.

El propósito de ms-modules es simple pero poderoso: nos permite crear Módulos y asociar a ellos los servicios (y sus endpoints) que han sido descubiertos y registrados por ms-services. Por ejemplo, podríamos crear un módulo “Gestión de Autenticación” y asociarle los servicios de ms-users, ms-roles y ms-rbac. Esta agrupación es la base sobre la que construiremos más adelante nuestro sistema de licenciamiento y control de acceso.

Un Vistazo a la Arquitectura de `ms-modules`

La arquitectura interna de ms-modules sigue fielmente nuestro arquetipo base, garantizando consistencia y calidad.

Flujo de la API a los Casos de Uso (CQRS)

Este diagrama muestra cómo las peticiones REST se traducen en acciones dentro del microservicio.

Peticiones REST: La API expone endpoints para gestionar Module y para añadir o quitar servicios de un módulo existente.
Casos de Uso: La lógica de negocio está separada en Commands (para crear, actualizar, eliminar, añadir/quitar servicios) y Queries (para leer la información de los módulos). Cada Command exitoso emite un Domain Event para notificar al resto del sistema.

El Modelo de Dominio

La lógica de negocio está encapsulada en el ModuleAggregate.

Diagrama de Agregado de Dominio de ms-modules

El Agregado ModuleAggregate no solo contiene la información básica del módulo, sino que también gestiona una lista de ServiceEntity. Esto asegura que la relación entre un módulo y sus servicios se mantenga siempre consistente y cumpla con las reglas de negocio.

Despliegue y Configuración Paso a Paso

Configurando los Secretos en Vault ms-modules necesita las mismas credenciales base que nuestros otros servicios para conectarse a RabbitMQ, Redis y MongoDB.

vault kv put -mount=inventory-keyvalue ms-modules `
    "RabbitMQ:UserName=<USERNAME_FROM_RABBITMQ_SECRET>" `
    "RabbitMQ:Password=<PASSWORD_FROM_RABBITMQ_SECRET>" `
    "Redis:Instances:Core:ConnectionString=<CONNECTION_STRING_FROM_REDIS>" `
    "Mongo:ConnectionString=<VAULT_TRANSIT_PASSWORD>"

Creando los secretos para ms-modules en Vault

Verificamos que los secretos se hayan guardado correctamente en la interfaz web de Vault.

Verificando los secretos de ms-modules en la UI de Vault

Desplegando con Helm desde ArtifactHub ms-modules solo expone una API REST, por lo que desplegaremos un único Helm Chart.

Ver Chart en ArtifactHub: ms-modules-rest

Preparar el values-rest.yaml Local Creamos un archivo values-rest.yaml con la configuración de las variables de entorno no sensibles y la conexión a Vault.

# values-rest.yaml para ms-modules-rest
ms-base:
  env:
    - name: RESOURCES__ENABLE
      value: "true"
    - name: RESOURCES__SERVER
      value: "http://ms-services-grpc.inventory.svc.cluster.local:5001"
    - name: SECURITY__VALIDISSUER
      value: "https://devcodedesignplus.ciamlogin.com/dfee7752-2c8a-4171-ad95-62ddc82d6ed8/v2.0/"
    - name: SECURITY__CLIENTID
      value: "305f759d-d1d2-467b-9eab-4a61389c7329"
    - name: SECURITY__VALIDAUDIENCES__0
      value: "305f759d-d1d2-467b-9eab-4a61389c7329"
    - name: RABBITMQ__HOST
      value: "rabbitmq-cluster.srv-rabbitmq.svc"
    - name: LOGGER__OTELENDPOINT
      value: "http://inventory-opentelemetry-collector.otel-inventory.svc.cluster.local:4317"
    - name: OBSERVABILITY__SERVEROTEL
      value: "http://inventory-opentelemetry-collector.otel-inventory.svc.cluster.local:4317"

  vault:
    server: http://vault.vault.svc.cluster.local:8200
    solution: inventory
    token: ANGq0*B2acD1n5%F

  virtualService:
    create: true
    namespace: istio-ingress
    hosts:
      - services.codedesignplus.app
    gateways:
      - istio-ingress/istio-inventory-gateway
    http:
    - name: ms-modules
      match:
      - uri:
          prefix: /ms-modules/
      rewrite:
        uri: /
      route:
      - destination:
          host: ms-modules-rest.inventory.svc.cluster.local
          port:
            number: 5000

Ejecutar el Despliegue con Helm Usamos helm upgrade --install para desplegar el chart en el namespace inventory.
Terminal window
```
helm upgrade --install ms-modules-rest codedesignplus/ms-modules-rest -f ./values-rest.yaml --namespace inventory
```

Parte 3: Verificación del Despliegue

Verificar el Pod en Lens En Lens, bajo “Workloads > Pods”, ahora vemos nuestro nuevo pod ms-modules-rest corriendo en el namespace inventory.
Verificar el VirtualService de Istio El Helm chart ha creado automáticamente el VirtualService que enruta el tráfico desde nuestro Gateway. En Lens, bajo “Custom Resources > VirtualService”, podemos ver la nueva regla para ms-modules.
Probar el Acceso a la API
- Endpoint de Salud: Verificamos que el servicio está vivo accediendo a su endpoint de salud: https://services.codedesignplus.app/ms-modules/health/ready
  
  Deberías ver una respuesta “Healthy”.
- Swagger UI: Para explorar la API de forma interactiva, usamos la interfaz de Swagger UI: https://services.codedesignplus.app/ms-modules/index.html
  
  Aquí puedes ver todos los endpoints disponibles para gestionar Módulos y los Servicios asociados a ellos.

Conclusión

Has desplegado con éxito ms-modules, un microservicio clave para la organización y estructuración de la funcionalidad de tu aplicación. Siguiendo nuestro patrón de despliegue, hemos añadido otra pieza a nuestro ecosistema de una manera rápida y estandarizada.

Con la capacidad de agrupar servicios en módulos, estamos un paso más cerca de poder implementar lógicas de negocio más complejas, como la gestión de licencias y el control de acceso a nivel de módulo, temas que abordaremos en los próximos artículos.