Files
athletic-map-deploy/tenants/plataforma/README.md
T
Athletic Map Deploy ea7da4364a feat(plataforma): tenant proprio da Athletic Map
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.
2026-09-17 17:58:21 +00:00

103 lines
4.9 KiB
Markdown

# Tenant `plataforma`
**Este não é um cliente.** É onde a Athletic Map opera a si mesma: o namespace,
o banco e o realm da própria empresa, separados dos clientes e separados também
do tenant de demonstração.
Gerado em 2026-09-17 pela tarefa **P3.1** (card 137).
## Estado: preparado, não aplicado
Nada aqui foi publicado. Os manifests estão prontos para o ArgoCD, mas **faltam
duas credenciais que só um humano pode gerar** — veja
[`05-sealed-db-credentials.yaml`](05-sealed-db-credentials.yaml) e
[`06-sealed-keycloak-admin.yaml`](06-sealed-keycloak-admin.yaml). No lugar dos
`SealedSecret` há um `ConfigMap` marcador, com nome impossível de confundir
(`CREDENCIAL-DO-BANCO-NAO-FOI-GERADA`) e com o comando `kubeseal` a rodar.
Enquanto os marcadores estiverem no lugar, o `postgres` e o `keycloak` não
sobem. É deliberado: melhor não subir do que subir com senha conhecida.
**Por que o assistente não gerou as credenciais:** `SealedSecret` é selado
**para um namespace**. O do `piloto-prod` não decifra em `plataforma-prod` — o
controlador recusa. E gerar segredo novo significaria escrevê-lo em algum lugar
antes de selar, o que o preâmbulo das tarefas proíbe.
## O que este tenant leva, e o que não leva
Um cliente roda 13 contextos. Aqui rodam 4, porque a Athletic Map não é uma
escolinha — não tem atleta, treino, campeonato nem prontuário.
| Leva | Para quê |
| --- | --- |
| `servico-configuracao` | catálogos e parâmetros |
| `servico-cadastro` | pessoas — os próprios funcionários |
| `servico-financeiro` | o financeiro da casa (veja a ressalva abaixo) |
| `servico-captacao` | **só existe aqui**: os leads da landing page |
| `bff` + `frontend-spa` | a porta de entrada |
| `postgres`, `keycloak`, `backup` | a infraestrutura do silo |
**Não leva**, de propósito:
- os 9 contextos restantes (agenda, saúde, pedagógico, nutrição, campeonato,
organização, planejamento, assistência social, administrativo) — sem uso aqui;
- o `30-apps-stubs.yaml` do piloto, que carrega o stub `backend` legado. P0.5
mediu: 11 requisições externas em 50 dias, todas 401. Tenant novo não nasce
com dívida, então o Ingress foi escrito do zero
([`30-ingress.yaml`](30-ingress.yaml)) e **sem o catch-all `/api`**.
## Domínio
Hoje: `plataforma.athleticmap.influxdigital.com.br` e
`auth-plataforma.athleticmap.influxdigital.com.br`.
Não é o canônico. O canônico decidido em 2026-09-16 é
`<tenant>.athleticmap.com` (P0.9), mas **o corte ainda não foi executado**.
Conferido em 2026-09-17: `plataforma.athleticmap.com` não tem registro A, e o
apex `athleticmap.com` resolve para 72.61.42.87, que não é o cluster
(187.77.37.184). Como o cert-manager usa desafio HTTP-01, nascer no `.com` hoje
daria certificado não emitido e login quebrado.
`*.athleticmap.influxdigital.com.br` é wildcard para o cluster, então este
tenant sobe já e **deve atravessar o corte junto com os demais**, no passo 5 do
plano.
> **Atenção — este tenant NÃO está no corte preparado.** O plano vive em
> `docs/p09-plano-de-corte-dominio.md`, **que não existe nesta branch**: está em
> `feat/dominio-app-athleticmap` (commit `f71480a`). E esse commit altera
> `acme`, `demo` e `piloto` — o `plataforma` ainda não existia quando foi
> escrito. Quem executar o P0.9 precisa **incluir esta pasta à mão**, senão ela
> fica sozinha no domínio do fornecedor.
Os hosts a trocar aqui estão em `30-ingress.yaml`,
`20-keycloak.yaml`, `35-realm-import-cm.yaml`, `realm/athleticmap-realm.json`,
`95-frontend-spa.yaml`, o `ATM_ISSUER` dos quatro serviços e o `CAPTACAO_ORIGEM`.
## Uma ressalva sobre "cobrar a si mesma"
O card 137 descreve este tenant como "onde a Athletic Map cobra a si mesma".
Isso **contradiz** `project-docs/Escolinhas esportivas/Produto e negócio/Planos
de assinatura.md:137`, que diz: *"Billing da assinatura é outro sistema. O `servico-financeiro` cobra o
aluno do cliente; cobrar o cliente exige gateway próprio (Asaas, Stripe, Iugu) e
ciclo de inadimplência/suspensão — não dá para reaproveitar."*
O tenant foi montado assim mesmo porque a infraestrutura é idêntica nas duas
leituras — namespace, banco, realm e login não mudam. O que muda é se o
`servico-financeiro` daqui serve para cobrar assinatura. **Isso está em aberto** e
é o que os cards 138 (P3.2) e 139 (P3.3, Asaas) decidem.
## Como verificar, quando for aplicado
O critério do card é *"login no tenant plataforma funciona e o financeiro abre
vazio"*. Depois de gerar as duas credenciais e deixar o ArgoCD sincronizar:
```sh
kubectl -n plataforma-prod get pods # postgres, keycloak e os 6 serviços prontos
kubectl -n plataforma-prod get ingress # certificado emitido, ADDRESS preenchido
curl -sI https://plataforma.athleticmap.influxdigital.com.br | head -1 # 200
```
O "financeiro vazio" é o esperado: banco novo, nenhuma cobrança. Se vier dado,
o tenant está apontando para o banco errado — pare e confira o
`05-sealed-db-credentials.yaml`.