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