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.
Os quatro tenants foram corrigidos mais cedo hoje; o plataforma nao. O defeito
so apareceu agora, e por um motivo que vale registrar: ele e o unico SEM
catch-all /api. Nos outros, uma rota sem linha propria era engolida pelo
backend legado; aqui ela cai no frontend — e e ali que o bug estava esperando.
Medido no log do proprio pod:
servico-bff could not be resolved (3: Host not found)
request: "POST /api/plataforma/provisionamentos"
O resolver do nginx nao aplica os search do /etc/resolv.conf, entao nome curto
nao resolve. As cinco variaveis estavam vazias, e toda ausente cai em
ATM_API_URL, que cai no nome curto `servico-bff`.
Aqui nao ha runtime consolidado: os destinos apontam para o BFF, que ja era o
padrao — a diferenca e so o FQDN.
Achado ao conferir o PLATAFORMA_ADMIN_TOKEN recem-ligado: a consulta de estado
devolvia 502 em vez de 401, e o 502 era isto.
Vai DEPOIS do commit que selou os Secrets, e nao junto: secretKeyRef de Secret
ausente impede o pod de subir. Os dois ja materializaram no cluster.
PLATAFORMA_WEBHOOK_TOKEN destrava a etapa que recebia o aviso de assinatura e
recusava tudo por falta de configuracao. Falta CADASTRAR o mesmo valor no painel
do Asaas, na conta da Athletic Map — quem for cadastrar le uma vez com:
kubectl -n plataforma-prod get secret plataforma-webhook-token \
-o jsonpath='{.data.token}' | base64 -d
PLATAFORMA_ADMIN_TOKEN destrava a consulta de estado do provisionamento, que e
interina e vive no cabecalho x-atm-admin-token.
Ao conferir que os Secrets tinham materializado, o comando imprimiu o campo
`.data` inteiro — ou seja, parte do valor em base64 dos dois tokens foi parar na
conversa. Curto, e o bastante para nao dar por confiavel.
Regerados. Custo zero: nada os referenciava ainda (nenhum Deployment, e o
webhook nao estava cadastrado no Asaas), entao nao houve janela de uso.
A licao, que ja valia para senha e vale igual para Secret: conferir existencia
com `-o name`, e nunca com `-o custom-columns=...:.data` nem `-o yaml`. O que se
quer saber e SE existe, nao O QUE e.
PLATAFORMA_ADMIN_TOKEN e PLATAFORMA_WEBHOOK_TOKEN. Os dois sao gerados aqui, ao
contrario da api-key do Asaas, que vem do painel do provedor.
O valor nasceu, foi selado e morreu dentro de um unico shell no servidor: nao
foi ecoado, nao foi para arquivo, nao entrou no historico e nao apareceu em ps.
O que se commita e o cifrado, que e publico por natureza.
Vao SOZINHOS neste commit, sem a referencia no Deployment: secretKeyRef de
Secret ausente impede o pod de subir. Primeiro o Secret materializa, depois o
env aponta para ele.
O webhook-token precisa ser CADASTRADO no painel do Asaas com o mesmo valor. Ele
pode ser lido uma vez, por quem for cadastrar:
kubectl -n plataforma-prod get secret plataforma-webhook-token \
-o jsonpath='{.data.token}' | base64 -d
Mesma mudanca do commit anterior, agora nos tres restantes. O demo foi primeiro
e ficou conferido de fora: os 13 contextos em 200, /bff em 200, /inicio e
/lp-escolinhas em 200, e — o que mais importava — /api/nao-mapeado continua
devolvendo 401, como antes. O comportamento visivel nao mudou.
Catorze linhas saem de cada um. O destino do /api passa de backend (o legado)
para frontend-spa; a decisao "401 ou 404" segue aberta e intacta.
Catorze linhas saem. Quem conhece a topologia interna passa a ser o
frontend/nginx.conf.template, que viaja junto com a imagem — antes, cada
mudanca de topologia obrigava a editar o Ingress de todos os tenants.
O destino do /api mudou de backend (o legado) para frontend-spa. O que o
visitante ve NAO muda: caminho nao mapeado continua recebendo 401 — antes do
backend legado, agora do BFF, para onde o nginx manda o /api que sobra. A
decisao "401 ou 404" segue aberta e intacta; isto so tira o legado do caminho
do trafego.
Pre-condicao resolvida hoje: as cinco variaveis de destino do nginx estavam
vazias e, mesmo apontadas, precisavam de FQDN (o resolver do nginx nao aplica os
search do resolv.conf). Sem isso, esta mudanca derrubaria os treze contextos e o
/bff de uma vez.
ORDEM: /api/public e /api/public/webhooks/asaas vivem no
96-ingress-garmin-public.yaml e tem prefixo mais longo, entao vencem o /api — o
Traefik ordena por tamanho.
Primeiro tenant. Os outros tres so depois de conferido.
O arquivo 96-ingress-garmin-public.yaml foi criado para o callback do Garmin e
leva TODO o /api/public para o servico-bff. O BFF relaya o Garmin de proposito
(GarminBffController), mas NAO tem controlador para /api/public/webhooks/asaas —
so o financeiro tem (WebhookAsaasController).
Resultado nos quatro tenants: o aviso de pagamento do Asaas chegava ao BFF e
parava ali. O sintoma seria o pior possivel — a cobranca e paga e NUNCA baixada,
sem erro nenhum do nosso lado; o provedor so registra uma entrega recusada.
Esta dormente hoje porque nenhum dos quatro tem asaas-credentials (cada cliente
traz a propria chave, decisao de 19/09). Passaria a morder no primeiro cliente
que ligasse a cobranca — e o diagnostico comecaria pelo lado errado, olhando o
financeiro, que nunca recebeu nada.
O Traefik ordena por TAMANHO do prefixo, entao a rota nova vence a generica
sozinha; fica escrita primeiro mesmo assim, para ninguem reordenar sem perceber.
Achado a partir do scripts/conferir_rotas_publicas.py, que acusou o piloto. A
acusacao estava certa no problema e errada no alcance: ele le a copia PARCIAL do
monorepo, que nao tem o Ingress de nenhum dos quatro, e concluiu sobre um.
Medido no cluster, os quatro eram identicos e os quatro estavam quebrados.
O Ingress do plataforma nao tem catch-all, por desenho: rota publica nova
precisa ser acrescentada a mao, ou devolve 404. Duas estavam faltando, as duas
achadas por scripts/conferir_rotas_publicas.py.
/api/public/conta (P5.8) — a tela de espera depois do pagamento. Quem acabou de
pagar AINDA NAO TEM CONTA, logo nao tem token. O controlador existia
(EstadoDaContaController) e a cadeia ja liberava (permitAll), mas o Ingress
devolvia 404: a tela que existe para tranquilizar quem pagou nao respondia.
/api/public/webhooks/assinatura (P5.1) — e outra coisa do webhooks/asaas que ja
estava la: aquele avisa que uma COBRANCA de cliente foi paga e vai para o
financeiro do tenant; este avisa que alguem assinou a Athletic Map, e dispara o
provisionamento de um tenant NOVO. Contas diferentes no Asaas, servicos
diferentes aqui. Sem esta linha, alguem assinaria, pagaria, e nenhum tenant
seria criado — sem erro em lugar nenhum do nosso lado.
Ao conferir o P4.6, o nginx do frontend devolveu 502 em TODOS os caminhos
internos, inclusive /bff. O log diz o porque:
servico-bff could not be resolved (3: Host not found)
runtime-saude could not be resolved (3: Host not found)
O "resolver" do nginx NAO aplica os "search" do /etc/resolv.conf: ele consulta o
nome exatamente como esta escrito. O comando "getent hosts servico-bff", de
dentro do MESMO pod, resolve — porque usa o resolv.conf, que tem
"search escolinha-prod.svc.cluster.local ...". O nginx nao usa.
Isso e PREEXISTENTE e estava invisivel: o Ingress roteia /bff e as treze linhas
de /api/<contexto> direto para os Services, entao o nginx nunca foi exercitado
nesses caminhos. Quem removesse as linhas do Ingress — que e exatamente o que
P4.6 quer — derrubaria os treze contextos E o /bff de uma vez, com 502 e nenhuma
pista no Ingress para explicar.
As cinco variaveis passam a usar FQDN. Conferido depois, batendo no nginx por
dentro (sem passar pelo Ingress): os 13 contextos respondem 200, e o /bff
tambem. De fora, os quatro tenants seguem em 200 — nada regrediu.
As tres variaveis estavam VAZIAS nos quatro tenants, e render-config.sh faz toda
ausente cair em ATM_API_URL, que cai em http://servico-bff. O nginx mandaria
/api/cadastro para o BFF, que responde 401 em vez da resposta do contexto.
Nada quebrava porque o INGRESS atende antes, com uma linha por contexto — e sao
justamente essas linhas que P4.6 quer remover. Sem isto, remove-las quebraria os
treze caminhos de uma vez.
Aditivo: enquanto o Ingress existir, o trafego nem chega a este nginx.
O ipBlock da deny-cross-tenant nao vale para destino em outro namespace (o k3s
avalia depois do DNAT), entao a variavel sozinha daria FalhaTemporaria. Vai
junto a netpol estreita: so o servico-captacao, so o pod do controlador, so a
porta 8080, so saida.
deploy