provisionamento Athletic Map
706a6e67ab
Cliente: Teste5 Assinatura: sub_zx7fdtz40b8is2gk Plano: (nao informado) Realm: athleticmap-9 Gerado pelo provisionamento automatico (P5.2/P5.3) a partir do molde consolidado de P4.9. O ApplicationSet cria a Application sozinho pelo gerador de diretorio sobre tenants/*.
75 lines
3.5 KiB
YAML
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: teste5-prod
|
|
spec:
|
|
redirectScheme:
|
|
scheme: https
|
|
permanent: true
|
|
---
|
|
apiVersion: networking.k8s.io/v1
|
|
kind: Ingress
|
|
metadata:
|
|
name: teste5
|
|
namespace: teste5-prod
|
|
annotations:
|
|
cert-manager.io/cluster-issuer: letsencrypt-prod
|
|
# O middleware e por namespace: `<namespace>-<nome>@kubernetescrd`.
|
|
traefik.ingress.kubernetes.io/router.middlewares: teste5-prod-redirect-https@kubernetescrd
|
|
spec:
|
|
ingressClassName: traefik
|
|
tls:
|
|
- hosts:
|
|
- teste5.athleticmap.com
|
|
secretName: teste5-tls
|
|
rules:
|
|
- host: teste5.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 } } } }
|