SCHEDULE_WORKER_ENABLED=true. Para los ajustes de streaming, telemetría y autenticación compartidos por todos los servicios Go de Lerian, consulta Aspectos esenciales de configuración BYOC.
En las tablas siguientes, la columna Predeterminado / Obligatorio muestra el valor predeterminado. Un calificador en negrita (por ejemplo Obligatorio) marca las variables que debes definir.
— significa que no hay valor predeterminado. 🔒 marca un secreto. Inyecta cada secreto en el momento del despliegue desde tu almacén de secretos. Nunca incluyas un secreto en un commit. Esta página solo lista nombres de variables y su comportamiento. No imprime valores de secretos.Este riel no monta la API de administración de systemplane. Sus variables de datastore usan el prefijo
DB_* en lugar de la forma compartida POSTGRES_*. Consulta Datastores más abajo.Componentes y puertos
El componente de API escucha enSERVER_ADDRESS (por ejemplo :4014). El puerto principal sirve las rutas de la API, GET /health (una respuesta constante) y GET /version. Cada componente, workers incluidos, sirve el readiness y las métricas en HEALTH_PORT. Consulta Health y readiness y Puertos de red predeterminados.
Licencia
Cada componente verifica la licencia al iniciar. La API, el worker de conciliación, el worker de programación y los workers de webhooks entrantes y salientes no inician sin una licencia válida. Si el servicio de licencia no responde al iniciar, el componente sigue en pie, no listo, y sigue intentando.
Consulta La licencia de Lerian.
Integración con BTG y mTLS
Estas variables guardan las credenciales de BTG y la configuración de TLS mutuo en ambas direcciones: el certificado de cliente que el plugin presenta a BTG y la verificación del certificado que BTG presenta en los webhooks entrantes.Datastores
Este riel usa el prefijoDB_* para los datastores, no la forma compartida POSTGRES_*. Se conecta a un PostgreSQL primario, a una réplica de lectura aparte, a MongoDB y a Redis.
Midaz y CRM
Webhooks internos y programación
La API y los workers intercambian eventos por un canal interno de webhooks. También ejecutan flujos Pix recurrentes y programados.Ámbito de Pix y del ledger
Access Manager
Estas variables se aplican al componente de la API. ParaPLUGIN_AUTH_ENABLED y PLUGIN_AUTH_ADDRESS, consulta Aspectos esenciales de configuración BYOC.
Con
DECLARATION_ENABLED=true, la API no inicia cuando PLUGIN_IDENTITY_HOST, M2M_CLIENT_ID o M2M_CLIENT_SECRET está vacío. Tampoco inicia cuando PLUGIN_AUTH_ENABLED no es true, o cuando PLUGIN_IDENTITY_HOST o PLUGIN_AUTH_ADDRESS no es una URL absoluta http o https.
Verificación de fraude en Pix entrante
Estas variables configuran la verificación de fraude en Pix entrante en el componente de la API. CuandoANTIFRAUD_HOOK_ENABLED es false, la API ignora las demás variables de esta tabla.
Eventos de negocio
Estas variables configuran los eventos de Pix BTG en el componente de la API. CuandoSTREAMING_ENABLED es false, la API ignora las demás variables de esta tabla.
Health y readiness
Apunta la sonda de readiness de cada componente a su
HEALTH_PORT.
Un componente no está listo hasta que se acepta una licencia. La API y el worker de conciliación también esperan a PostgreSQL (primario) y a Redis. Los workers de webhooks entrantes y salientes también esperan a PostgreSQL. El worker de programación también informa su propio loop. Después del inicio, una réplica de PostgreSQL o un MongoDB con fallo aparece como degraded y el pod sigue en rotación. Con STREAMING_ENABLED=true, la verificación streaming informa de la misma forma. Cada worker también informa su propio loop de trabajo como una verificación de liveness. Consulta Health y readiness para conocer la forma de la respuesta.
