Saltar al contenido principal
Esta página proporciona una referencia completa y anotada de values.yaml optimizada para despliegues en producción. Cópiala, adapta los marcadores de posición a tu entorno y despliega.
Esta es una configuración de referencia. Debes reemplazar todos los valores de marcador de posición (marcados con {...}) con los datos reales de tu infraestructura antes de desplegar.

Cómo usar


  1. Copia la configuración completa a continuación en un archivo llamado values-production.yaml
  2. Reemplaza todos los marcadores {...} con tus valores reales
  3. Revisa cada sección y ajusta los límites de recursos para tu carga de trabajo esperada
  4. Despliega:

Valores completos de producción


Las variables de entorno ACCOUNT_TYPE_VALIDATION y TRANSACTION_ROUTE_VALIDATION han sido deprecadas y reemplazadas por la API de Configuración de Ledger. Usa PATCH /v1/organizations/{org_id}/ledgers/{ledger_id}/settings para configurar la validación contable por ledger.

Decisiones clave explicadas


¿Por qué Ledger en lugar de Onboarding + Transaction?

El servicio unificado ledger es el enfoque recomendado para todas las nuevas instalaciones. Combina ambos módulos en un solo despliegue, reduciendo la carga operativa:
  • Menos pods para gestionar y monitorear
  • Configuración simplificada (un solo configmap/secret)
  • Un solo endpoint de ingress
  • Mejor utilización de recursos
  • Será la única opción en futuras versiones

¿Por qué bases de datos externas?

Los despliegues de producción deben usar servicios de bases de datos administrados para:
  • Copias de seguridad automáticas y recuperación en un punto en el tiempo
  • Alta disponibilidad con failover automático
  • Monitoreo y alertas integrados
  • Escalamiento sin tiempo de inactividad
  • Parches de seguridad administrados por el proveedor
Servicios administrados recomendados:
DependenciaAWSGCPAzure
PostgreSQLAmazon RDSCloud SQLAzure Database for PostgreSQL
MongoDBAmazon DocumentDB o MongoDB AtlasMongoDB AtlasAzure Cosmos DB (MongoDB API)
RabbitMQAmazon MQAuto-administrado en GKEAuto-administrado en AKS
Redis/ValkeyAmazon ElastiCacheMemorystoreAzure Cache for Redis

¿Por qué usar Kubernetes Secrets en lugar de contraseñas en línea?

Las contraseñas en línea en values.yaml son visibles en el historial de versiones de Helm y pueden ser comprometidas en control de versiones. Usar useExistingSecret: true con Secrets de Kubernetes pre-creados:
  • Mantiene las credenciales fuera de los valores de Helm
  • Permite rotación sin necesidad de upgrade de Helm
  • Se integra con herramientas de gestión de secretos (Vault, External Secrets Operator, Sealed Secrets)

Anti-afinidad de pods

La regla podAntiAffinity distribuye los pods de Ledger en diferentes nodos, de modo que la falla de un solo nodo no afecte todo el servicio.

Checklist antes de desplegar


1

Crear Kubernetes Secrets

Crea todos los secrets requeridos en el namespace midaz antes de ejecutar helm install:
  • midaz-ledger (credenciales de bases de datos y broker de mensajes)
  • midaz-crm (claves de encriptación y contraseña de MongoDB)
  • otel-api-key (si usas telemetría de Lerian)
2

Configurar DNS

Apunta tus dominios a la IP externa del controlador de ingress:
  • {your-midaz-api-domain} → IP del ingress
  • {your-crm-api-domain} → IP del ingress
  • {your-grafana-domain} → IP del ingress
3

Provisionar certificados TLS

Usa cert-manager para el aprovisionamiento automático de certificados o crea manualmente los secrets TLS para cada dominio.
4

Verificar conectividad a bases de datos

Asegúrate de que tu cluster Kubernetes pueda alcanzar todas las bases de datos externas. Pruébalo con:
5

Revisar límites de recursos

Ajusta los límites de CPU y memoria según tu volumen de transacciones esperado. Los valores de esta referencia son puntos de partida para cargas de trabajo moderadas.
6

Desplegar

7

Verificar despliegue

Recursos relacionados