Uso real ~5m por container; a reserva de 100m travava o no em 13 tenants.
Com 50m o teto passa a ser a memoria: 16. Limites continuam 1 vCPU.
Ver docs/capacidade-kvm8.md no repositorio de codigo.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- 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>
Aditiva de proposito: nenhum endereco antigo sai. Quem esta usando
<tenant>.athleticmap.influxdigital.com.br continua entrando, e o cert-manager
passa a emitir tambem o certificado de <tenant>.athleticmap.com.
Foi possivel porque o dono criou o curinga hoje: *.athleticmap.com resolve para
187.77.37.184, conferido com um nome ALEATORIO — demo. ou www. responderiam
mesmo sem curinga, e a conferencia passaria por engano.
9 arquivos, 28 trocas, 317 insercoes e 4 remocoes. As 4 sao as linhas de TLS em
fluxo, reescritas com os dois dominios na mesma lista.
Cada regra de Ingress foi DUPLICADA com os mesmos paths, e nao trocada: uma
regra com host: X so atende X.
`platform/` (ArgoCD e Grafana) fica FORA: mexer no Ingress do ArgoCD no meio de
uma migracao de dominio e perder o instrumento de rollback.
Conferido antes de aplicar: YAML valido em todos os Ingress, e ZERO host sem
entrada de TLS.
O que NAO muda aqui: ATM_ISSUER, ATM_KC_URL e as URLs do Garmin. Ninguem e
deslogado nesta fase.
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.
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.
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.
deploy