En las tablas siguientes, la columna Predeterminado / Obligatorio muestra el valor predeterminado. Un calificador en negrita marca una variable que debes definir en el contexto descrito.
— significa que no hay valor predeterminado. 🔒 marca un secreto. Inyéctalo en el momento del despliegue desde tu almacén de secretos y nunca lo incluyas en un commit.Cómo funcionan juntos values.yaml y Systemplane
Para el despliegue inicial, los clientes entregan la configuración a través del values.yaml del Helm chart que acompaña al release. Después de la inicialización, las claves de runtime se gestionan mediante Systemplane.
El chart convierte los valores en variables de entorno del pod:
Cada dominio tiene un componente de Systemplane dedicado. El flujo es:
1
Renderizar el release
Helm crea el ConfigMap de cada componente y referencia su Secret. El Deployment carga ambos con
envFrom cuando el pod arranca.2
Inicializar la configuración de runtime
El componente de Systemplane lee las variables de entorno mapeadas y aplica una semilla solo mientras el valor almacenado siga siendo igual al predeterminado registrado. Una anulación administrativa existente no se sobrescribe.
3
Consumir la configuración
Las APIs de dominio y los workers leen el almacén de Systemplane. La definición de cada clave determina si admite actualizaciones en runtime o exige un reinicio.
4
Cambiar la fuente correcta
Para las variables de bootstrap, actualiza
values.yaml, ejecuta el upgrade y haz el rollout del componente. Después de la inicialización, cambia las claves de runtime mediante Systemplane. Cambiar solo values.yaml no reemplaza una anulación almacenada.- Variables de entorno de bootstrap directas:
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 se usan como semillas 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 las semillas en el bloque de Systemplane que es dueño del dominio, no en el bloque de la API ni en el del worker. Las claves sensibles siguen marcadas con
🔒 en las tablas siguientes.
Los tres bloques también reciben las semillas compartidas
DEPLOYMENT_MODE, REQUEST_TIMEOUT_SEC y PLUGIN_AUTH_*.
Pix Lerian no expone descubrimiento de catálogo. Usa esta página como la referencia de claves admitidas y consulta Systemplane para el modelo de autorización y de actualización en runtime.
Servidor y modo de despliegue
Cada componente recibeSERVER_ADDRESS de <component>.configmap.SERVER_ADDRESS. El valor debe coincidir con <component>.service.port en el mismo values.yaml. Las sondas de liveness y readiness usan ese puerto. Consulta Servidor y Salud y readiness.
Persistencia y configuración de runtime
SPI, DICT, COB y el adaptador mantienen almacenes separados. No reutilices la misma base de datos lógica entre dominios.Los valores de identidad, las URL y las credenciales que se declaran en los componentes de configuración se usan solo como semillas de la primera inicialización. Cuando una clave ya existe en el almacén de runtime, reiniciar el servicio no sobrescribe el valor. Haz los cambios posteriores mediante el plano de configuración autenticado.
Identidad de la institución
Midaz y CRM
SPI usa Midaz para la contabilidad. SPI y DICT usan CRM para validar cuentas y titulares en los flujos que necesitan esta información.Integraciones entre dominios
Las URL siguientes apuntan a componentes desplegados de Pix Lerian. Configuran la comunicación entre SPI, DICT, COB y el adaptador sin cambiar el contrato que consume la aplicación cliente.Conciliación de DICT (VSync)
El worker de VSync concilia la base de datos DICT persistida con la fuente regulatoria. El transporte de RabbitMQ está habilitado de forma predeterminada. Cuando está activo, necesita una URI válida.Streaming y observabilidad
La publicación de CloudEvents desde SPI, DICT y COB usa la familiaSTREAMING_* y permanece deshabilitada de forma predeterminada. Cuando STREAMING_ENABLED=true, STREAMING_BROKERS es obligatorio. Si defines STREAMING_CLOUDEVENTS_SOURCE, el único valor aceptado es plugin-br-pix-lerian. Consulta Streaming y outbox y Observabilidad para el resto de los 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 de componente y de las variables. Inyecta los secretos desde el almacén de secretos y nunca guardes credenciales en texto plano en el repositorio. Después de sembrar los valores, usa Systemplane para cambiar las claves de runtime.
Salud y readiness
Configura las sondas mediante<component>.livenessProbe.path y <component>.readinessProbe.path en values.yaml. Las rutas predeterminadas varían según el componente. No supongas rutas /health y /readyz sin prefijo.
La sonda de liveness verifica si el proceso está vivo. La sonda de readiness verifica si las dependencias y la configuración necesarias permiten que el componente reciba tráfico. No enrutes tráfico a un componente hasta que su sonda de readiness tenga éxito.