Saltar al contenido principal
Pix Indirecto vía BTG llega al arreglo Pix a través de BTG como participante directo. Se distribuye como varios componentes: una API, más los workers de conciliación, de programación y de webhooks entrantes y salientes. DevOps define las variables de entorno de cada componente en el momento del despliegue. Para cambiar una variable, reinicias ese componente. Esta página cubre las variables distintivas de este riel. Para las variables de los workers, consulta la sección de capas de worker de Integración y, para el worker de salida, Webhooks. El worker de programación ejecuta Pix programados solo con 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 en SERVER_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 prefijo DB_* 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. Para PLUGIN_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. Cuando ANTIFRAUD_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. Cuando STREAMING_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.