Files
athletic-map-deploy/moldes/consolidado/30-ingress.yaml
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

75 lines
3.5 KiB
YAML

# =============================================================================
# P5.5 — a entrada do tenant, com certificado automatico.
#
# ── O MOLDE NAO TINHA INGRESS NENHUM ────────────────────────────────────────
#
# Achado em 2026-09-19, ao comecar o card 165: os cinco arquivos do molde
# consolidado criavam namespace, tres runtimes e a SPA — e nenhuma entrada. Um
# tenant provisionado a partir dele subiria inteiro e **nao seria alcancavel de
# fora**, com todos os pods saudaveis.
#
# ── UMA REGRA SO, E ISSO E O PONTO DE P4.6 ──────────────────────────────────
#
# O Ingress do `plataforma` tem SETE caminhos: um por contexto, mais o BFF, mais a
# SPA. Aqui ha um. O nginx da imagem do frontend roteia `/bff` e `/api` por conta
# propria (P4.6), entao a topologia interna deixou de ser problema do Ingress — e
# mudar de cinco pods para tres runtimes nao obriga mais a editar o Ingress de
# todos os tenants.
#
# ── SEM HOST DE AUTENTICACAO ────────────────────────────────────────────────
#
# O `plataforma` tem um segundo host, `auth-plataforma...`, porque tinha Keycloak
# proprio. Com o Keycloak compartilhado (P4.8) o tenant nao tem: a autenticacao
# acontece no host da plataforma, e o realm e que separa um cliente do outro.
#
# ── O CERTIFICADO, E POR QUE HTTP-01 ────────────────────────────────────────
#
# `cert-manager.io/cluster-issuer: letsencrypt-prod` — o mesmo que o `plataforma`
# ja usa, com desafio HTTP-01.
#
# A alternativa seria um certificado CURINGA, e ele exigiria desafio DNS-01, e
# DNS-01 exige um solver do provedor de DNS. **O provedor e a Hostinger, e o
# cert-manager nao tem solver nativo para ela** — seria preciso escrever um
# webhook. Conferido em 2026-09-19.
#
# Com HTTP-01 cada tenant tem o proprio certificado e nao ha solver nenhum a
# escrever. O que se precisa do provedor e UMA entrada de DNS curinga
# (`*.athleticmap.com` apontando para o cluster), feita uma vez a mao.
#
# **A ORDEM E OBRIGATORIA:** o host precisa resolver para o cluster ANTES de o
# cert-manager pedir o certificado, porque o desafio HTTP-01 e uma requisicao que
# a Let's Encrypt faz ao proprio host. Sem o curinga no ar, o certificado fica em
# `False` para sempre e o tenant responde so em HTTP.
# =============================================================================
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
name: redirect-https
namespace: {{TENANT}}-prod
spec:
redirectScheme:
scheme: https
permanent: true
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: {{TENANT}}
namespace: {{TENANT}}-prod
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
# O middleware e por namespace: `<namespace>-<nome>@kubernetescrd`.
traefik.ingress.kubernetes.io/router.middlewares: {{TENANT}}-prod-redirect-https@kubernetescrd
spec:
ingressClassName: traefik
tls:
- hosts:
- {{TENANT}}.athleticmap.com
secretName: {{TENANT}}-tls
rules:
- host: {{TENANT}}.athleticmap.com
http:
paths:
# UMA rota. O nginx da SPA resolve /bff e /api internamente (P4.6).
- { path: /, pathType: Prefix, backend: { service: { name: frontend-spa, port: { number: 80 } } } }