Os dois tenants pagos estavam presos em `1.1-demo` desde 24/09 23:43,
sem conseguir ir para `1.2-auditoria`. O ArgoCD dizia Synced: o
Deployment batia com o git. O que nao acontecia era o rollout.
Em repouso os cinco Deployments somam 2944Mi. O maxSurge de 25% sobre
uma replica arredonda para cima e pede um pod inteiro a mais: 768Mi,
quando o que troca e um runtime. 2944 + 768 = 3712, contra 3584.
O cabecalho do arquivo ja tinha essa licao escrita -- para `pods`, que
derrubou o provisionamento do plataforma em 17/09. A memoria nao ganhou
o mesmo tratamento. Agora a regra esta escrita uma vez, para todos os
tetos, e o paragrafo velho que ainda dizia `pods: 8` saiu.
So limits.memory travava: medido hoje, requests.memory tinha 560Mi
livres (a troca pede 400), requests.cpu 1100m (pede 100), limits.cpu
1300m (pede 1000) e pods 5 de 10.
O nginx roteia /bff e /api com proxy_pass de variavel, e ai resolve por
requisicao usando a diretiva resolver. O resolver do nginx nao le os dominios
de busca do /etc/resolv.conf: pergunta o nome cru ao CoreDNS, que responde
NXDOMAIN para servico-bff.
O sintoma engana: 502 com could not be resolved no log do nginx, enquanto
getent hosts servico-bff dentro do MESMO pod resolve — porque o getent usa o
search e o nginx nao. E por isso que o escolinha sempre usou FQDN aqui.
O tenant provisionado subia com a tela de login de fabrica e o sistema vazio.
Quatro mudancas, medidas contra o escolinha que e o que funciona:
- 90-servico-bff.yaml: o quinto Deployment. A SPA chama o BFF para quase tudo;
sem ele /bff devolve 502. As URLs apontam para os RUNTIMES, e nao para os
treze servicos — e a diferenca deste molde para o do escolinha.
- a cota sobe para 10 pods e 2Gi: com quatro Deployments o tenant ja usava
1232Mi de 1536Mi, e o BFF pede 256Mi. Caberia em repouso e estouraria no
primeiro rollout.
- loginTheme athleticmap-v2 no realm, com o tema montado no Keycloak
compartilhado.
- imagens alinhadas: frontend 2.67-csp-script e os runtimes 1.2-auditoria.
O que NAO mudou, e por que: ATM_API_URL continua no runtime-operacao e o
Ingress continua com uma rota. Os dois estao certos — o nginx da SPA roteia
/bff e /api por conta propria, e ATM_API_URL e o destino do que nao pertence a
grupo nenhum, hoje o webhook em /api/public. O cabecalho do molde ja dizia.
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.
deploy