Nas tabelas abaixo, a coluna Padrão / Obrigatório mostra o valor padrão. Um qualificador em negrito marca uma variável que você deve definir no contexto descrito.
— significa que não há padrão. 🔒 marca um segredo. Injete o valor no momento do deploy a partir do seu cofre de segredos e nunca faça commit dele.Como o values.yaml e o Systemplane funcionam juntos
No deploy inicial, os clientes fornecem a configuração pelo values.yaml do Helm chart entregue com a release. Depois da inicialização, as chaves de tempo de execução são gerenciadas pelo Systemplane.
O chart transforma os valores em variáveis de ambiente do pod:
Cada domínio tem um componente dedicado de Systemplane. O fluxo é:
1
Renderize a release
O Helm cria o ConfigMap de cada componente e referencia o Secret dele. O Deployment carrega os dois com
envFrom quando o pod sobe.2
Inicialize a configuração de tempo de execução
O componente de Systemplane lê as variáveis de ambiente mapeadas e aplica um seed apenas enquanto o valor armazenado ainda é igual ao padrão registrado. Um override administrativo existente não é sobrescrito.
3
Consuma a configuração
As APIs de domínio e os workers leem o armazenamento do Systemplane. A definição de cada chave determina se ela aceita atualizações em tempo de execução ou exige um reinício.
4
Mude a fonte correta
Para as variáveis de bootstrap, atualize o
values.yaml, rode o upgrade e faça o rollout do componente. Depois da inicialização, mude as chaves de tempo de execução pelo Systemplane. Mudar apenas o values.yaml não substitui um override armazenado.- Variáveis de ambiente de bootstrap direto:
APPLICATION_NAME,SERVER_ADDRESS,DATABASE_URL,SYSTEMPLANE_POSTGRES_DSN,SYSTEMPLANE_SECRET_MASTER_KEY,VALKEY_URL,LICENSE_KEY,ORGANIZATION_IDS,SWAGGER_ENABLED,RABBITMQ_ENABLED,RABBITMQ_URIeSTREAMING_*. - Também usadas como seeds do Systemplane:
DEPLOYMENT_MODE,REQUEST_TIMEOUT_SEC,PLUGIN_AUTH_*,ORGANIZATION_ID,ISPB,ADAPTER_BASE_URL,MIDAZ_*,CRM_*,DICT_*,COB_*,SPI_*,KEY_CACHE_TTL_SECeVSYNC_*.
Defina os seeds no bloco de Systemplane dono do domínio, não no bloco de API ou de worker. As chaves sensíveis continuam marcadas com
🔒 nas tabelas abaixo.
Os três blocos também recebem os seeds compartilhados
DEPLOYMENT_MODE, REQUEST_TIMEOUT_SEC e PLUGIN_AUTH_*.
O Pix Lerian não expõe descoberta de catálogo. Use esta página como referência das chaves aceitas e veja Systemplane para o modelo de autorização e de atualização em tempo de execução.
Servidor e modo de deploy
Cada componente recebeSERVER_ADDRESS de <component>.configmap.SERVER_ADDRESS. O valor deve corresponder a <component>.service.port no mesmo values.yaml. As probes de liveness e readiness usam essa porta. Veja Servidor e Health e readiness.
Persistência e configuração em tempo de execução
SPI, DICT, COB e o adaptador mantêm armazenamentos separados. Não reutilize o mesmo banco de dados lógico entre domínios.Valores de identidade, URLs e credenciais declarados nos componentes de configuração são usados apenas como seeds de primeira inicialização. Depois que uma chave existe no armazenamento de tempo de execução, reiniciar o serviço não sobrescreve o valor. Faça as mudanças posteriores pelo plano de configuração autenticado.
Identidade da instituição
Midaz e CRM
O SPI usa o Midaz para contabilidade. O SPI e o DICT usam o CRM para validar contas e titulares nos fluxos que exigem essa informação.Integrações entre domínios
As URLs abaixo apontam para componentes do Pix Lerian com o deploy já feito. Elas configuram a comunicação entre SPI, DICT, COB e o adaptador sem mudar o contrato consumido pela aplicação cliente.Conciliação do DICT (VSync)
O worker VSync concilia o banco de dados persistido do DICT com a fonte regulatória. O transporte RabbitMQ vem habilitado por padrão. Quando ativo, ele exige uma URI válida.Streaming e observabilidade
A publicação de CloudEvents pelo SPI, DICT e COB usa a famíliaSTREAMING_* e continua desabilitada por padrão. Quando STREAMING_ENABLED=true, STREAMING_BROKERS é obrigatório. Se você definir STREAMING_CLOUDEVENTS_SOURCE, o único valor aceito é plugin-br-pix-lerian. Veja Streaming e outbox e Observabilidade para os demais parâmetros de broker, TLS, SASL e OpenTelemetry.
Fonte de configuração de bootstrap
Ovalues.yaml do Helm chart entregue é a fonte de bootstrap do deploy. Mantenha-o alinhado com a versão do chart e preserve os nomes dos blocos de componente e das variáveis. Injete os segredos a partir do cofre de segredos e nunca guarde credenciais em texto puro no repositório. Depois de aplicar os seeds, use o Systemplane para mudar as chaves de tempo de execução.
Health e readiness
Configure as probes por<component>.livenessProbe.path e <component>.readinessProbe.path no values.yaml. Os caminhos padrão variam por componente. Não suponha caminhos /health e /readyz sem prefixo.
A probe de liveness verifica se o processo está vivo. A probe de readiness verifica se as dependências e a configuração necessárias permitem que o componente receba tráfego. Não roteie tráfego para um componente até a probe de readiness dele passar.