plataforma B: servicos cadastro/configuracao/financeiro apontam para os runtimes; SPA 2.126 + BFF 2.25; contextos vazios; comentario da cota

2026-10-07 20:11:00 +00:00
parent 9043e21a19
commit 5c754aafa3
6 changed files with 140 additions and 76 deletions
@@ -9,21 +9,9 @@ metadata:
    tenant: plataforma
    athleticmap.io/tier: platform
 ---
-# RASCUNHO — substitui SO o objeto ResourceQuota de
-# athletic-map-deploy/tenants/plataforma/00-namespace-quota-netpol.yaml (commit A).
-# Nao aplicar daqui: copiar para o GitOps na janela.
-#
-# Por que: medido em 07/10/2026, requests.memory 3762Mi de 4Gi. O runtime-core
-# (384Mi) nao cabe ao lado dos servicos antigos, e a migracao proposta sobe os
-# runtimes ANTES de tirar trafego dos antigos (troca sem buraco). Com 5Gi:
-#   3762 + 384 (core) + 384 (operacao) + 320 (pod novo do frontend-spa no rolling) = 4850Mi.
-# O no tem folga (12,6Gi de 32Gi pedidos em 07/10).
-#
-# Os LIMITES tambem estouram: limits.cpu 10900m/12 e limits.memory 9536Mi/11Gi
-# medidos; somando core (1 cpu/768Mi) + operacao (1 cpu/768Mi) + pod extra do
-# rolling do frontend-spa (0,7 cpu/640Mi) = 13,6 cpu / 11,7Gi. Dai 15 e 13Gi.
-#
-# Na fase 3 (antigos em replicas 0) o uso cai para ~3570Mi; voltar ao valor antigo e opcional.
+# Cota de recursos do tenant. 07/10/2026: requests.memory 4Gi->5Gi, limits 12->15 cpu e 11->13Gi para a
+# migracao aos runtimes (runtimes sobem ao lado dos servicos antigos, sem buraco). Historico das cotas
+# anteriores: git log deste arquivo. Ver docs/migrar-plataforma-para-runtimes.md no nova-atm.
 apiVersion: v1
 kind: ResourceQuota
 metadata:
@@ -1,6 +1,14 @@
-# Bounded context "configuracao" como app proprio (ADR-0002): Deployment/pod
-# medivel = centro de custo. Schema proprio "configuracao" no Postgres do silo
-# (criado pelo Flyway). Roteado em /api/configuracao no ingress do tenant.
+# RASCUNHO — tenants/plataforma/70-servico-configuracao.yaml (commit B). Nao aplicar daqui.
+#
+# Unica mudanca em relacao ao arquivo de hoje: o `selector` do Service passa de
+# `app: servico-configuracao` para `app: runtime-core`. Nome, porta e rotulo `app: servico-configuracao` do Service
+# NAO mudam: Ingress, CronJobs, BFF, port-forward dos scripts e o ServiceMonitor
+# athleticmap-servicos continuam apontando para o mesmo nome (mesmo desenho do
+# tenant escolinha).
+#
+# O Deployment antigo FICA com replicas 1 neste commit (volta instantanea: e so
+# reverter o selector). No commit C (D+2 a D+7) ele vai a `replicas: 0` — sem
+# apagar o arquivo: o Argo esta com prune=false e o manifesto e o rollback.
 ---
 apiVersion: apps/v1
 kind: Deployment
@@ -64,5 +72,5 @@ metadata:
  labels:
    app: servico-configuracao
 spec:
-  selector: { app: servico-configuracao }
+  selector: { app: runtime-core }
  ports: [{ name: http, port: 80, targetPort: 8083 }]
@@ -0,0 +1,56 @@
+# RASCUNHO — tenants/plataforma/73-servicos-dos-contextos-vazios.yaml (commit B).
+# OPCIONAL — depende da decisao do dono (docs/migrar-plataforma-para-runtimes.md §7, D3).
+#
+# O BFF tem URL para 13 contextos. Hoje, na plataforma, 10 deles apontam para
+# Services que NAO existem (servico-organizacao, -planejamento...): qualquer tela
+# do SPA que os chame da 502/erro dentro do BFF. Com os runtimes no ar, seis desses
+# contextos passam a existir de fato (vazios). Estes Services fazem o BFF acha-los
+# pelo mesmo nome que usa nos tenants de escola — mesmo desenho do escolinha.
+#
+# Sem este arquivo nada quebra que ja nao esteja quebrado hoje. Com ele, telas como
+# Inicio/Agenda/Elencos abrem vazias em vez de dar erro. Saude, nutricao,
+# pedagogico e assistencia social continuam sem destino (nao ha runtime-saude aqui).
+apiVersion: v1
+kind: Service
+metadata: { name: servico-organizacao, namespace: plataforma-prod }
+spec:
+  selector: { app: runtime-core }
+  ports: [{ name: http, port: 80, targetPort: 8083 }]
+---
+apiVersion: v1
+kind: Service
+metadata: { name: servico-documentos, namespace: plataforma-prod }
+spec:
+  selector: { app: runtime-core }
+  ports: [{ name: http, port: 80, targetPort: 8083 }]
+---
+apiVersion: v1
+kind: Service
+metadata: { name: servico-agenda, namespace: plataforma-prod }
+spec:
+  selector: { app: runtime-core }
+  ports: [{ name: http, port: 80, targetPort: 8083 }]
+---
+apiVersion: v1
+kind: Service
+metadata: { name: servico-planejamento, namespace: plataforma-prod }
+spec:
+  selector: { app: runtime-operacao }
+  ports: [{ name: http, port: 80, targetPort: 8083 }]
+---
+apiVersion: v1
+kind: Service
+metadata: { name: servico-campeonato, namespace: plataforma-prod }
+spec:
+  selector: { app: runtime-operacao }
+  ports: [{ name: http, port: 80, targetPort: 8083 }]
+---
+apiVersion: v1
+kind: Service
+metadata: { name: servico-administrativo, namespace: plataforma-prod }
+spec:
+  selector: { app: runtime-operacao }
+  ports: [{ name: http, port: 80, targetPort: 8083 }]
+# SEM rotulo `app: servico-<x>` de proposito: com ele estes Services entrariam no
+# ServiceMonitor athleticmap-servicos (plataforma-prod esta na lista) e o mesmo pod
+# seria raspado mais 3 vezes. As metricas ja saem por servico-cadastro/-financeiro.
@@ -1,5 +1,14 @@
-# Bounded context "financeiro" (2a onda): Cobranca + ApuracaoRateio (centros de custo).
-# Schema proprio "financeiro" (Flyway). Roteado em /api/financeiro no ingress.
+# RASCUNHO — tenants/plataforma/79-servico-financeiro.yaml (commit B). Nao aplicar daqui.
+#
+# Unica mudanca em relacao ao arquivo de hoje: o `selector` do Service passa de
+# `app: servico-financeiro` para `app: runtime-operacao`. Nome, porta e rotulo `app: servico-financeiro` do Service
+# NAO mudam: Ingress, CronJobs, BFF, port-forward dos scripts e o ServiceMonitor
+# athleticmap-servicos continuam apontando para o mesmo nome (mesmo desenho do
+# tenant escolinha).
+#
+# O Deployment antigo FICA com replicas 1 neste commit (volta instantanea: e so
+# reverter o selector). No commit C (D+2 a D+7) ele vai a `replicas: 0` — sem
+# apagar o arquivo: o Argo esta com prune=false e o manifesto e o rollback.
 ---
 apiVersion: apps/v1
 kind: Deployment
@@ -89,5 +98,5 @@ metadata:
  labels:
    app: servico-financeiro
 spec:
-  selector: { app: servico-financeiro }
+  selector: { app: runtime-operacao }
  ports: [{ name: http, port: 80, targetPort: 8083 }]
@@ -1,6 +1,14 @@
-# Bounded context "cadastro" como app proprio (ADR-0002/0003): Deployment/pod
-# medivel = centro de custo. Schema proprio "cadastro" no Postgres do silo
-# (criado pelo Flyway). Roteado em /api/cadastro no ingress do tenant.
+# RASCUNHO — tenants/plataforma/80-servico-cadastro.yaml (commit B). Nao aplicar daqui.
+#
+# Unica mudanca em relacao ao arquivo de hoje: o `selector` do Service passa de
+# `app: servico-cadastro` para `app: runtime-core`. Nome, porta e rotulo `app: servico-cadastro` do Service
+# NAO mudam: Ingress, CronJobs, BFF, port-forward dos scripts e o ServiceMonitor
+# athleticmap-servicos continuam apontando para o mesmo nome (mesmo desenho do
+# tenant escolinha).
+#
+# O Deployment antigo FICA com replicas 1 neste commit (volta instantanea: e so
+# reverter o selector). No commit C (D+2 a D+7) ele vai a `replicas: 0` — sem
+# apagar o arquivo: o Argo esta com prune=false e o manifesto e o rollback.
 ---
 apiVersion: apps/v1
 kind: Deployment
@@ -64,5 +72,5 @@ metadata:
  labels:
    app: servico-cadastro
 spec:
-  selector: { app: servico-cadastro }
+  selector: { app: runtime-core }
  ports: [{ name: http, port: 80, targetPort: 8083 }]
@@ -1,5 +1,30 @@
-# SPA Angular (shell OIDC + admin de catalogos + cadastro de Atleta) consumindo
-# o BFF. Substitui o stub estatico nginx/configMap. Roteado em / no ingress.
+# RASCUNHO — tenants/plataforma/95-frontend-spa.yaml (commit B). Nao aplicar daqui.
+#
+# frontend-spa 2.85 -> 2.124-conectar e servico-bff 1.98 -> 2.23-inscricao-externa,
+# as MESMAS imagens dos quatro tenants e do molde em 07/10/2026.
+#
+# O que muda, e por que:
+#   * nginx do SPA 2.124: `/api/` responde 404 (so passam /bff, os publicos da
+#     captacao e o webhook Asaas). O 2.85 repassava QUALQUER /api ao BFF — era o
+#     buraco fechado na borda pelo 31-ingress-api-fechada (05/10). O 31- continua.
+#   * ATM_API_CORE/OPERACAO_URL apontam para os runtimes, como no escolinha. O
+#     ATM_API_SAUDE_URL fica no BFF (nao ha runtime-saude aqui) — o render-config
+#     avisa "2 de 3 ATM_API_*_URL diferem"; e esperado, so os contextos de saude
+#     caem no destino generico. Alternativa sem aviso: nao definir nenhum dos tres.
+#   * BFF: URLs dos 13 contextos (como nos tenants). Os que nao existem aqui
+#     (saude, nutricao, pedagogico, assistencia-social) dao erro so na tela deles —
+#     igual a hoje com o 1.98.
+#   * ATM_MAQUINA_*: o BFF 2.x le a matriz de permissoes com o client `operacao`.
+#     ATM_MAQUINA_HOST_PUBLICO = auth-PLATAFORMA. O padrao do BFF e auth.athleticmap.com;
+#     com ele o token de maquina sai com `iss` diferente do ATM_ISSUER dos runtimes
+#     e toda leitura de maquina da 401 (a matriz cai no padrao/nega).
+#   * SEM consentimento-selo, fcm-credenciais e desafio: nao existem neste namespace;
+#     o BFF sobe e so registra aviso (mesmo comportamento de hoje).
+#   * Volume `publico` e os ConfigMaps frontend-publico-* INALTERADOS: sao a landing,
+#     /contratar, /preparando, /minha-conta e /painel-do-dono, publicados a parte.
+#   * strategy Recreate NAO: rolling padrao, com a cota do 00-quota.yaml. Se a cota
+#     nao for subida, trocar para `strategy: { type: Recreate }` (~40 s de 503 no SPA
+#     e nas paginas publicas servidas por este nginx, inclusive a landing).
 ---
 apiVersion: apps/v1
 kind: Deployment
@@ -21,16 +46,7 @@ spec:
    spec:
      containers:
        - name: frontend-spa
-          # Tag alinhada com o tenant `escolinha`, que e o mais atual do
-          # cluster. A que estava aqui vinha do molde defasado deste
-          # repositorio, e nenhum tenant real a usava mais.
-          #
-          # O preco disso apareceu no primeiro deploy: com
-          # `servico-financeiro:1.0`, o Flyway aplicou UMA migracao (V001) e
-          # parou — a imagem foi construida antes de V002..V007 existirem, e a
-          # tabela `plano_financeiro` nem chegou a ser criada. "Imagem
-          # presente no no" nao e o mesmo que "imagem atual".
-          image: docker.io/library/frontend-spa:2.85-lgpd-relatorio
+          image: docker.io/library/frontend-spa:2.126-apps-108
          imagePullPolicy: Never
          ports: [{ containerPort: 80 }]
          env:
@@ -38,32 +54,9 @@ spec:
            - { name: ATM_REALM, value: "athleticmap" }
            - { name: ATM_CLIENT, value: "spa" }
            - { name: ATM_TENANT, value: "plataforma" }
-            # Plano do tenant, lido pela BarreiraDePlano (P3.7). Sem esta
-            # variavel o servico nasce Bronze e responde 403 no que e pago.
            - { name: ATM_PLANO, value: "institucional" }
-            # P4.6 — o roteamento interno do nginx, com FQDN.
-            #
-            # O `resolver` do nginx NAO aplica os `search` do /etc/resolv.conf:
-            # `servico-bff` sozinho nao resolve, e a resposta e 502. Medido aqui
-            # em 2026-09-22, no log do proprio pod:
-            #   "servico-bff could not be resolved (3: Host not found)",
-            #   request: "POST /api/plataforma/provisionamentos"
-            #
-            # Os quatro tenants foram corrigidos mais cedo no mesmo dia; o
-            # plataforma ficou de fora, e so apareceu porque ele NAO tem
-            # catch-all /api — entao uma rota sem linha propria cai no frontend,
-            # e e ali que o defeito estava esperando.
-            #
-            # Aqui NAO ha runtime consolidado: os tres apontam para o BFF, que e
-            # o que `render-config.sh` ja faria por padrao — a diferenca e o FQDN.
-            # P4.6 fechado 2026-09-26: o BFF e o SEGUNDO CONTAINER deste
-            # mesmo pod (ver o container 'servico-bff' abaixo) — sem
-            # Deployment proprio. `127.0.0.1` porque os dois containers
-            # do pod compartilham a rede. O Service `servico-bff` continua
-            # existindo, so com o `selector` mudado para o rotulo
-            # `athleticmap.io/bff-aqui` deste pod — quem aponta direto para ele
-            # (o webhook do Garmin do escolinha, e o Prometheus) nao
-            # precisou de nenhuma edicao.
+            - { name: ATM_API_CORE_URL, value: "http://runtime-core.plataforma-prod.svc.cluster.local" }
+            - { name: ATM_API_OPERACAO_URL, value: "http://runtime-operacao.plataforma-prod.svc.cluster.local" }
            - { name: ATM_BFF_URL, value: "http://127.0.0.1:8083" }
            - { name: ATM_API_URL, value: "http://servico-bff.plataforma-prod.svc.cluster.local" }
          resources:
@@ -78,16 +71,7 @@ spec:
            initialDelaySeconds: 5
            periodSeconds: 10
        - name: servico-bff
-          # Tag alinhada com o tenant `escolinha`, que e o mais atual do
-          # cluster. A que estava aqui vinha do molde defasado deste
-          # repositorio, e nenhum tenant real a usava mais.
-          #
-          # O preco disso apareceu no primeiro deploy: com
-          # `servico-financeiro:1.0`, o Flyway aplicou UMA migracao (V001) e
-          # parou — a imagem foi construida antes de V002..V007 existirem, e a
-          # tabela `plano_financeiro` nem chegou a ser criada. "Imagem
-          # presente no no" nao e o mesmo que "imagem atual".
-          image: docker.io/library/servico-bff:1.98-barreira-de-plano
+          image: docker.io/library/servico-bff:2.25-grupos-direto
          imagePullPolicy: Never
          ports: [{ containerPort: 8083 }]
          env:
@@ -98,14 +82,25 @@ spec:
            - { name: ATM_CAMPEONATO_URL, value: "http://servico-campeonato" }
            - { name: ATM_SAUDE_URL, value: "http://servico-saude" }
            - { name: ATM_FINANCEIRO_URL, value: "http://servico-financeiro" }
+            - { name: ATM_DOCUMENTOS_URL, value: "http://servico-documentos" }
+            - { name: ATM_ADMINISTRATIVO_URL, value: "http://servico-administrativo" }
+            - { name: ATM_ASSISTENCIA_SOCIAL_URL, value: "http://servico-assistencia-social" }
+            - { name: ATM_PEDAGOGICO_URL, value: "http://servico-pedagogico" }
+            - { name: ATM_NUTRICAO_URL, value: "http://servico-nutricao" }
+            - { name: ATM_AGENDA_URL, value: "http://servico-agenda" }
            - { name: ATM_JWK_SET_URI, value: "http://keycloak:8080/realms/athleticmap/protocol/openid-connect/certs" }
            - { name: ATM_ISSUER, value: "https://auth-plataforma.athleticmap.com/realms/athleticmap" }
            - { name: ATM_TENANT, value: "plataforma" }
-            # Plano do tenant, lido pela BarreiraDePlano (P3.7). Sem esta
-            # variavel o servico nasce Bronze e responde 403 no que e pago.
            - { name: ATM_PLANO, value: "institucional" }
+            - { name: ATM_TRANSCRICAO_URL, value: "http://servico-voz.plataforma-prod.svc:8091" }
+            - { name: ATM_MAQUINA_TOKEN_URL, value: "http://keycloak:8080/realms/athleticmap/protocol/openid-connect/token" }
+            - { name: ATM_MAQUINA_HOST_PUBLICO, value: "auth-plataforma.athleticmap.com" }
+            - name: ATM_MAQUINA_SEGREDO
+              valueFrom:
+                secretKeyRef: { name: operacao-credentials, key: client-secret, optional: true }
+            - { name: GARMIN_FRONTEND_REDIRECT, value: "https://plataforma.athleticmap.com/integracoes/garmin" }
          resources:
-            requests: { cpu: 100m, memory: 256Mi }
+            requests: { cpu: 50m, memory: 256Mi }
            limits: { cpu: 500m, memory: 512Mi }
          readinessProbe:
            httpGet: { path: /bff/health, port: 8083 }