Desplegando ms-services: El Registro Central con REST y gRPC

Jul 19, 2025 - 6 min read - 968 words

En la fase anterior, construimos una plataforma de contenedores robusta. Ahora, estamos listos para el primer despliegue real del ecosistema CodeDesignPlus.

El primer microservicio que debemos desplegar es ms-services. Este componente es crucial porque actúa como el registro central de nuestra plataforma. Todos los demás microservicios que despleguemos reportarán a ms-services para su registro y descubrimiento.

La Arquitectura en Acción: Flujo y Responsabilidades de `ms-services`

Antes de desplegar, entendamos el rol específico de ms-services y cómo su arquitectura interna le permite cumplir su función.

Flujo de Peticiones y Casos de Uso

Este diagrama ilustra cómo las solicitudes que llegan a ms-services se procesan internamente.

Diagrama de Flujo CQRS de un microservicio

Peticiones REST (Lado Izquierdo): ms-services expone una API REST para operaciones de gestión. Por ejemplo, a través de esta API, un administrador podría registrar un nuevo microservicio o consultar los existentes.
Procesamiento Interno (Lado Derecho): Cada petición activa un “Caso de Uso” específico.
- Las operaciones de escritura (como CreateService) son manejadas como Commands. Estas modifican los datos y, al finalizar, emiten un Evento de Dominio (ej. ServiceCreated) a RabbitMQ. Esto permite que otros sistemas reaccionen a los cambios de forma asíncrona.
- Las operaciones de lectura (como GetService) son manejadas como Queries, optimizadas para devolver la información rápidamente.

El Modelo de Dominio

La lógica de negocio está encapsulada en un Agregado de Dominio, como se ve en este diagrama de clases.

Este Agregado se asegura de que cualquier “Microservicio” que se cree o modifique siempre cumpla con las reglas de negocio (ej. un microservicio no puede estar duplicado por el nombre o id, un nombre no puede estar vacío).

Parte 1: Almacenando Datos Confidenciales en Vault

Nuestra estrategia de configuración es híbrida:

Datos Confidenciales (Secretos): Todo lo que sea sensible (contraseñas, cadenas de conexión con credenciales) se almacenará exclusivamente en Vault.
Datos No Sensibles: Configuraciones como URLs de servicios internos, flags de características, etc., se pasarán como variables de entorno a través de Helm.

En nuestro artículo anterior, recolectamos toda la información. Ahora, almacenaremos solo la parte confidencial en Vault.

Ejecutar el Comando vault kv put Abre una terminal con la CLI de Vault autenticada y ejecuta el siguiente comando para guardar las credenciales.

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

Configurando los secretos confidenciales para ms-services en Vault

Podemos visualizar los secretos en la interfaz web de Vault:

Verificando los secretos de ms-services en Vault

Parte 2: Desplegando los Entrypoints con Helm

El microservicio ms-services tiene dos puntos de entrada, cada uno con su propio Helm Chart: REST y gRPC. Desplegaremos ambos.

Desplegando el Entrypoint REST (ms-services-rest)

Ver Chart en ArtifactHub: ms-services-rest
- Preparar el values-rest.yaml Local Creamos un archivo values-rest.yaml para gestionar la configuración.
```
# values-rest.yaml para ms-services-rest
ms-base:
  env:
    - name: RESOURCES__ENABLE
      value: "false"
    - 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-collector.svc.cluster.local:4317"
    - name: OBSERVABILITY__SERVEROTEL
      value: "http://inventory-opentelemetry-collector.otel-collector.svc.cluster.local:4317"

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

  virtualService:
    # ... (configuración de Istio)
```
  La Jerarquía de Configuración de .NET y CodeDesignPlus
  Esta configuración híbrida es posible gracias al potente sistema de configuración de .NET y a la inteligencia del SDK de CodeDesignPlus. El orden de precedencia es el siguiente:
  1. Base (appsettings.json): El microservicio se inicia con los valores por defecto definidos en su archivo appsettings.json.
  2. Variables de Entorno (Sobrescritura): .NET busca automáticamente variables de entorno que coincidan con la estructura de la configuración. La sintaxis SECTION__SUBSECTION se traduce a Section:Subsection. Por ejemplo, la variable RABBITMQ__HOST sobrescribe el valor de RabbitMQ:Host en el appsettings.json. Usamos esto para configuraciones no sensibles.
  3. Vault (Sobrescritura Final y Segura): Finalmente, el SDK de CodeDesignPlus se conecta a Vault y lee los secretos. Estos valores sobrescriben cualquier configuración previa, asegurando que los datos confidenciales (como RabbitMQ:Password) provengan siempre de la fuente más segura y nunca estén expuestos.
- Ejecutar el Despliegue con Helm Usamos helm upgrade --install para desplegar el chart en un nuevo namespace inventory.
  Terminal window
```
helm upgrade --install ms-services-rest codedesignplus/ms-services-rest -f ./values-rest.yaml --namespace inventory --create-namespace
```

Desplegando el Entrypoint gRPC (ms-services-grpc)

Ver Chart en ArtifactHub: ms-services-grpc

Preparar el values-grpc.yaml Local El values-grpc.yaml usa la misma lógica de variables de entorno y conexión a Vault, pero omite la configuración del VirtualService ya que no se expone a Internet.

# values-grpc.yaml para ms-services-grpc
ms-base:
env:
  - name: RESOURCES__ENABLE
    value: "false"
  - 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-collector.svc.cluster.local:4317"
  - name: OBSERVABILITY__SERVEROTEL
    value: "http://inventory-opentelemetry-collector.otel-collector.svc.cluster.local:4317"

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

Ejecutar el Despliegue con Helm Instalamos el segundo chart en el mismo namespace inventory.

helm upgrade --install ms-services-grpc codedesignplus/ms-services-grpc -f ./values-grpc.yaml --namespace inventory

Instalando el Helm chart de ms-services-grpc

Parte 3: Verificación y Próximos Pasos

Verificar los Despliegues en Lens En Lens, si vamos a “Workloads > Pods” y filtramos por el namespace inventory, ahora deberíamos ver los pods de ambos despliegues (ms-services-rest y ms-services-grpc) corriendo.
Verificar el VirtualService de Istio El Helm chart de ms-services-rest ya creó el VirtualService por nosotros. En Lens, podemos verificar que la regla para enrutar el tráfico de /ms-services/ está activa.
Probar el Acceso a la API REST Abre tu navegador o un cliente de API y navega a la URL del endpoint de salud: https://services.codedesignplus.app/ms-services/api/health

Si la respuesta es un código 200 (OK), ¡felicidades! Has desplegado y configurado exitosamente el registro central de servicios con sus dos entrypoints.

También podras visualizar el Swagger UI de ms-services-rest en:

https://services.codedesignplus.app/ms-services/swagger/index.html

Conclusión

Has completado el primer despliegue exitoso del ecosistema CodeDesignPlus. ms-services está ahora funcionando con su interfaz de gestión pública (REST) y su canal de comunicación interna de alto rendimiento (gRPC).

Este proceso dual sirve como una plantilla perfecta para microservicios más complejos que también tengan múltiples puntos de entrada. En los próximos artículos, continuaremos desplegando los demás microservicios, que ahora podrán registrarse en ms-services y empezar a formar una red de servicios conectados.