feat: componente pulumi, stacks e smoke da stack dev em kind

[thnbi]

O que mudou

• Componente Pulumi em Go em deploy/pulumi: PostgreSQL no namespace (ou banco externo por URL), Job de migração, API, e entrada por Gateway API, com Gateway e Issuer próprios ou pendurada num Gateway existente
• Projeto Pulumi em deploy/stacks com as stacks dev e prod
• Ambiente kind em deploy/kind com os requisitos do cluster de produção (Cilium em hostNetwork, Gateway API, cert-manager): make smoke-kind, make kind-up, make kind-painel, make kind-down
• CI: testes do componente e smoke da stack dev num kind, só quando muda servidor ou deploy
• Docs: ADR-0033, ADRs 0025 e 0027 revistos, DEPLOY.md, diagrama de implantação, glossário

Fixes #30
Fixes #31

Por quê

• O ADR-0027 escolheu Kubernetes, e o ADR-0025 escolheu Pulumi em Go como artefato de instalação
• Tudo o que o markupp cria fica no namespace dele, sem mexer na configuração do cluster
• Parte de uma divisão: servidor no feat: postgres, config por variavel de ambiente e migrate no servidor #32 (base deste), imagem no GHCR no chore: publica a imagem do servidor no ghcr #33

Respostas à revisão

• docs/release-notes-v1.0.0-rc.1.md saiu: tinha entrado por engano
• Gateway nas portas 80/443: confirmado no cluster que o Cilium em hostNetwork exige porta única por Gateway, e que o Gateway que já existe aceita só rotas do próprio namespace. O componente ganhou existingGateway, que cria só o HTTPRoute; a stack prod passa a usá-lo quando o admin do cluster oferecer um Gateway compartilhado
• Imagem privada no GHCR: o pacote vai ser público (chore: publica a imagem do servidor no ghcr #33), sem imagePullSecrets
• Postgres fixado em 17.9-alpine3.23, igual ao compose e aos testes; apiReplicas: 0 passa a ser aceito; a mensagem de campo vazio traz emissor e email ACME; o workflow virou smoke-dev.yml com paths:

Pendente, de propósito

• Requests, limits, liveness e securityContext do Postgres e da API ficam para o primeiro deploy em produção, que está bloqueado até existir autenticação. Até lá nada roda no cluster compartilhado

Como testar

• make smoke-kind (precisa de Docker, kind, helm, kubectl e Pulumi)
• make kind-up e make kind-painel para acompanhar no Headlamp; make kind-down no fim
• cd deploy/pulumi && go test ./...

Auto-review (checklist)

• Descrição clara (o que/por quê/como testar)
• PR pequeno e focado
• Casos limite considerados (ex.: vazio, 0, erro)
• Evidência de teste (manual ou automatizado)

[NicolasArthurDev]

Depende do #24, que precisa entrar antes.

Resolver antes do merge

1. Tamanho. São 62 arquivos e cerca de 2,6 mil linhas, misturando a troca do SQLite pelo Postgres, a config por variável de ambiente, o subcomando migrate, Pulumi e kind, a troca do Docker Hub pelo GHCR e docs. O próprio checklist deixa "PR pequeno" desmarcado. Sugiro separar pelo menos em: (a) storage, config e migrate; (b) Pulumi, kind e o workflow da stack dev; (c) release no GHCR.
2. Arquivo que entrou por engano. O docs/release-notes-v1.0.0-rc.1.md veio no commit 1335404 (docs: troca o cloudnativepg pelo postgres no namespace), que não tem relação com ele. O conteúdo está desatualizado: fala em SQLite e na imagem riedelgab/ifsces2 do Docker Hub. Ele não existe em main nem em dev.
3. A imagem do GHCR provavelmente não baixa em produção. Pacote de organização no GHCR nasce privado, e o componente não declara imagePullSecrets. A prod deve ficar em ImagePullBackOff. Ou o pacote vira público, ou o componente passa a aceitar um pull secret.
4. Gateway próprio nas portas 80/443 no cluster de produção. Precisa ser confirmado: com o Cilium em hostNetwork, um segundo Gateway nas mesmas portas do Gateway que o cluster já tem pode conflitar. A prod também já tem ClusterIssuer. Vale oferecer a opção de pendurar o HTTPRoute no Gateway compartilhado (parentRefs de outro namespace) em vez de criar Gateway e Issuer próprios.

Médio

• Postgres do StatefulSet (deploy/pulumi/database.go):
  • sem requests e limits e sem liveness probe;
  • sem securityContext, então o entrypoint roda como root e o pod é recusado se o namespace aplicar PodSecurity restricted;
  • a tag postgres:17-alpine é flutuante e se repete no componente, no compose e no testcontainers.
• API sem requests e limits em deploy/pulumi/workload.go.
• deploy-dev.yml: o nome diz deploy, mas o workflow só faz o smoke. Roda um kind de 5 minutos em todo PR, inclusive nos que só mexem em docs. Falta paths:.
• Config: MARKUPP_MAX_NOTE_SIZE=0 ou negativo cai no default sem avisar, enquanto MARKUPP_PORT=0 ou negativo é aceito. Melhor validar a faixa e devolver erro com o valor recebido. O Load também passa de 20 linhas.
• Makefile: o all ainda faz docker-up antes do test, mas o test agora roda no host com testcontainers.

Menor

• Mensagem do validate(): quando falta acmeEmail, a mensagem não traz certificateIssuer nem acmeEmail, só namespace, image e host.
• Réplicas: com withDefaults, apiReplicas: 0 vira 2, então não dá para pedir zero réplicas.
• Migração editada no lugar: a 00001 trocou TIMESTAMP por TIMESTAMPTZ sem migração nova. Só funciona porque ainda não existe banco Postgres; vale registrar isso na descrição.
• TDD por commit: alguns feat: vieram sem um test: antes (compose, cluster kind, stacks).

O que está bom

Os testes do componente Pulumi usam um monitor falso com nome, o storagetest cria um banco por teste e garante isolamento, e a migração saiu do boot para um Job. O controle de versão já trunca timestamp em milissegundo, então não há falso 409 com o Postgres.

[NicolasArthurDev]

Para aprovar: remover o docs/release-notes-v1.0.0-rc.1.md, resolver o pull da imagem privada do GHCR na prod, confirmar o Gateway próprio nas portas 80/443 contra o Gateway que o cluster já tem e, de preferência, quebrar o PR em partes menores.

[NicolasArthurDev]

Ficou bem melhor depois de quebrar o PR, parabéns! A opção existingGateway com testes para cada caso, o zero réplicas, a versão fixa do Postgres e o workflow de smoke com filtro de paths: resolveram tudo o que eu tinha comentado.

Sugestões para um próximo PR, sem bloquear:

• A stack em deploy/stacks/Pulumi.yaml ainda não expõe existingGateway, então a prod continua criando Gateway próprio. Vale expor quando a escolha do Gateway da prod for confirmada.
• Requests, limits e securityContext no Postgres e na API deixam o deploy pronto para um namespace com PodSecurity restricted.

Aprovado.