- runtime-core dos quatro antigos ganha ATM_KC_ADMIN_URL e ATM_KC_REALM do
Keycloak compartilhado (o padrao apontava para o Keycloak proprio, parado)
- molde e os quatro nascidos dele: client cadastro-keycloak criado no realm,
segredo selado em 05-sealed-kc-admin-secret.yaml, variaveis no runtime-core
(secretKeyRef optional) e o Secret na Role de leitura do provisionamento
- plataforma: o captacao pode anotar o ApplicationSet para varrer na hora
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
db-credentials (a senha do papel) e <tenant>-tls (so a existencia, que e como a
etapa DNS_PUBLICADO sabe que o cert-manager terminou). Por tenant porque o nome
do TLS depende dele e resourceNames nao aceita curinga — e dar get em qualquer
Secret do namespace deixaria o provisionamento ler a chave Asaas DO CLIENTE.
Ate aqui ele vivia SO no monorepo, e o provisionamento roda DENTRO do cluster —
o pod do servico-captacao nao tinha como enxerga-lo. A etapa MANIFESTOS_GERADOS
falhava por configuracao vazia, e falhar fechado era o comportamento certo; o
que faltava era o molde chegar.
Pondo-o aqui, o pod precisa de UM volume em vez de dois: o mesmo clone do GitOps
serve de molde (moldes/consolidado) e de copia de trabalho (tenants/<nome>).
Os tres marcadores — TENANT, REALM e PLANO — batem com o RenderizadorDeMolde. Os
arquivos NAO sao YAML valido antes de renderizados, e isso e de proposito: um
`{{PLANO}}` literal aplicaria sem reclamar e criaria um tenant cujo plano se
chama "{{PLANO}}", com a barreira negando tudo depois.
ATM Platform