En las tablas siguientes, la columna Valor por defecto / Requerida muestra el valor predeterminado. Un calificador en negrita identifica una variable que debes definir en el contexto descrito.
— significa que no hay valor predeterminado. 🔒 identifica un secreto: inyéctalo durante el despliegue desde tu almacén de secretos y nunca lo incluyas en un commit.Cómo se relacionan values.yaml y Systemplane
Para el despliegue inicial, el cliente proporciona la configuración mediante el values.yaml del Helm chart entregado con el release. Después de la inicialización, las claves de runtime se administran mediante Systemplane.
El chart transforma los values en variables de entorno del pod:
Cada dominio tiene un componente dedicado de Systemplane. El flujo es:
1
Renderiza el release
Helm crea el ConfigMap y referencia el Secret de cada componente. El Deployment carga ambos con
envFrom cuando se inicia el pod.2
Inicializa la configuración de runtime
El componente Systemplane lee las variables de entorno mapeadas y aplica un seed solo mientras el valor almacenado coincide con el valor predeterminado registrado. No sobrescribe un override administrativo existente.
3
Consume la configuración
Las APIs y los workers del dominio leen el store de Systemplane. La definición de cada clave determina si admite actualizaciones en runtime o si requiere un reinicio.
4
Cambia la fuente correcta
Para variables de bootstrap, actualiza
values.yaml, ejecuta el upgrade y realiza el rollout del componente. Después de la inicialización, modifica las claves de runtime mediante Systemplane; cambiar solo values.yaml no reemplaza un override almacenado.- Variables de entorno directas de bootstrap:
APPLICATION_NAME,SERVER_ADDRESS,DATABASE_URL,SYSTEMPLANE_POSTGRES_DSN,SYSTEMPLANE_SECRET_MASTER_KEY,VALKEY_URL,LICENSE_KEY,ORGANIZATION_IDS,SWAGGER_ENABLED,RABBITMQ_ENABLED,RABBITMQ_URIySTREAMING_*. - También usadas como seeds de Systemplane:
DEPLOYMENT_MODE,REQUEST_TIMEOUT_SEC,PLUGIN_AUTH_*,ORGANIZATION_ID,ISPB,ADAPTER_BASE_URL,MIDAZ_*,CRM_*,DICT_*,COB_*,SPI_*,KEY_CACHE_TTL_SECyVSYNC_*.
Define los seeds en el bloque de Systemplane que pertenece al dominio, no en el bloque de la API o del worker. Las claves sensibles siguen marcadas con
🔒 en las tablas siguientes.
Los tres bloques también reciben los seeds compartidos
DEPLOYMENT_MODE, REQUEST_TIMEOUT_SEC y PLUGIN_AUTH_*.
Pix Lerian no expone el descubrimiento del catálogo. Usa esta página como referencia de las claves admitidas y consulta Systemplane para conocer el modelo de autorización y actualización de runtime.
Servidor y modo de despliegue
Cada componente recibeSERVER_ADDRESS desde <componente>.configmap.SERVER_ADDRESS; el valor debe coincidir con <componente>.service.port en el mismo values.yaml. Las probes de liveness y readiness usan ese puerto. Consulta Servidor y Salud y disponibilidad.
Persistencia y configuración de runtime
SPI, DICT, COB y el adaptador mantienen stores separados. No reutilices la misma base de datos lógica entre dominios.Los valores de identidad, URLs y credenciales declarados en los componentes de configuración se usan como seeds solo en la primera inicialización. Después de que una clave existe en el store de runtime, reiniciar el servicio no sobrescribe el valor. Realiza los cambios posteriores mediante el plano autenticado de configuración.
Identidad de la institución
Midaz y CRM
SPI usa Midaz para la contabilización. SPI y DICT usan CRM para validar cuentas y titulares en los flujos que requieren esa información.Integraciones entre dominios
Las URLs siguientes apuntan a los componentes desplegados de Pix Lerian. Configuran la comunicación entre SPI, DICT, COB y el adaptador sin cambiar el contrato consumido por la aplicación cliente.Reconciliación de DICT (VSync)
El worker VSync reconcilia la base persistida de DICT con la fuente regulatoria. El transporte RabbitMQ está habilitado de forma predeterminada; cuando está activo, exige una URI válida.Streaming y observabilidad
La publicación de CloudEvents de SPI, DICT y COB usa la familiaSTREAMING_* y permanece desactivada de forma predeterminada. Cuando STREAMING_ENABLED=true, STREAMING_BROKERS es obligatoria. Si defines STREAMING_CLOUDEVENTS_SOURCE, el único valor aceptado es plugin-br-pix-lerian. Consulta Streaming y outbox y Observabilidad para los demás parámetros de broker, TLS, SASL y OpenTelemetry.
Fuente de configuración de bootstrap
Elvalues.yaml del Helm chart entregado es la fuente de bootstrap del despliegue. Mantenlo alineado con la versión del chart y conserva los nombres de los bloques y de las variables. Inyecta secretos desde el secret store y nunca almacenes credenciales en texto plano en el repositorio. Después del seed, usa Systemplane para cambiar las claves de runtime.
Salud y readiness
Configura las probes mediante<componente>.livenessProbe.path y <componente>.readinessProbe.path en values.yaml. Los paths predeterminados varían por componente; no asumas /health y /readyz sin prefijo.
La liveness probe verifica si el proceso está activo. La readiness probe verifica si las dependencias y configuraciones obligatorias permiten que el componente reciba tráfico. No dirijas tráfico a un componente hasta que su readiness probe responda correctamente.