O caminho anterior, /api/public/leads/health, nao existe: o LeadController tem um
unico @PostMapping. O pod subia e ficava 0/1 com a aplicacao dizendo Started no
log.
A quota copiada do molde (limits.cpu 4) impedia Keycloak, bff e captacao de criar
pod: os 8 deployments somam 6,2 CPU de limites. Redimensionada para 8 CPU / 8Gi,
e nao copiada do piloto, que roda 18 deployments.
O postgres ficava em ContainerCreating por montar um volume `postgres-tls` que
nao existia: e a mudanca de P2.2, preparada e nunca aplicada neste cluster.
Certificado gerado e selado para este namespace.
Acrescentado o 60-monitoring-netpol.yaml, que nao existia no molde. Sem ele o
tenant funciona e fica invisivel no Grafana. Seleciona os cinco pods de aplicacao
que existem aqui, e nao `app: backend` como o do piloto.
Namespace, banco, Keycloak e realm proprios, separados dos clientes e do tenant
de demonstracao. Leva 4 contextos (configuracao, cadastro, financeiro, captacao)
mais bff e SPA, e nao os 13 de um cliente: a Athletic Map nao e escolinha.
Ingress escrito do zero, sem o stub backend legado e sem catch-all /api. Duas
rotas publicas, ambas por desenho: /api/public/leads (o formulario da landing
page) e /api/public/webhooks/asaas (o aviso de pagamento, que chega da internet
sem token nosso).
Dominio em *.athleticmap.influxdigital.com.br, e nao no canonico athleticmap.com
do P0.9: aquele ainda nao tem registro A, e com desafio HTTP-01 nascer nele
daria certificado nao emitido e login quebrado.
Tres SealedSecret gerados para ESTE namespace, e a chave publica do backup no
lugar do placeholder. As 7 imagens locais exigidas estao no no, incluindo
servico-captacao:1.0 e atm-pg-backup:1.0, construidas hoje.
Preparado em P3.1 a P3.4. Validado com kubectl --dry-run: 32 documentos.
Athletic Map Deploy