Files

T

deploy f6aeb233a7 feat(moldes): o molde do tenant novo entra no repositorio GitOps

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.

2026-09-22 22:07:34 +00:00

2.3 KiB

Raw Blame History

Molde consolidado de tenant — P4.9

Quatro Deployments no lugar de quinze.

Os numeros, medidos e nao estimados


um tenant hoje (`escolinha`, 2026-09-18)	5.253 Mi em 18 pods
runtime-core	384 MiB
runtime-operacao	403 MiB
runtime-saude	366 MiB
frontend-spa	24 MiB
soma do molde novo	1.177 MiB em 4 pods

A cota (requests 1.5Gi / limits 2.5Gi / pods 8) sai desses numeros, com folga para o pod novo conviver com o velho durante um rollout — foi a falta disso que travou o provisionamento do plataforma em 2026-09-17.

O que este molde NAO tem

Postgres e Keycloak. Os dois passam a viver em plataforma-prod (P4.7 e P4.8). E por isso que o tenant caiu de 18 pods para 4.

O que falta antes de usar

A renomeacao dos quatro realms que ja existem. O molde usa agora um marcador PROPRIO, {{REALM}}, e nao mais {{TENANT}} — decidido em 2026-09-19: o realm passa a se chamar athleticmap-<N>, com N na ordem de criacao, e o tenant continua com o nome comercial. Sao coisas diferentes agora, e confundi-las gera um ATM_JWK_SET_URI apontando para um realm inexistente: o pod fica saudavel e ninguem consegue entrar. Os quatro tenants atuais ainda tem realm athleticmap, e a renomeacao deles e o card 156. A ordem de criacao nao foi conferida — esta no diario.
Nao ha Deployment do servico-bff neste molde, e o ATM_BFF_URL aponta para um Service que nao existe no namespace. Todo /bff daria 502. Ver o cabecalho do 95-frontend-spa.yaml e o diario: bloqueia os cards 158 e 159.
O asaas-credentials pode nao existir quando o pod subir. Com a decisao de 2026-09-19 (a plataforma abre subconta por cliente), a aprovacao passa por analise de documentos e nao cabe na janela de provisionamento. O secretKeyRef precisa virar optional: true, senao o runtime-operacao nao inicia.
scripts/provisionar_tenant.py procura o molde em tenants/<nome>, e este vive em moldes/. Precisa aprender o caminho.

O molde antigo continua onde estava

tenants/piloto e os outros nao foram tocados: eles sao o rollback. O card pede isso explicitamente, e nao e formalidade — enquanto os runtimes nao estiverem em producao, o que roda e o desenho antigo.

2.3 KiB Raw Blame History