release: consolida a infraestrutura como codigo da Sprint 2 no main

[thnbi]

O que mudou

Consolidação da Sprint 2 da disciplina ISN, 84 commits, fechando o milestone "Sprint 2: infraestrutura como código", que espelha a Sprint 2 de ederson-torresini/isn20262.

Ambiente IaC (#30) e projeto e stacks no Pulumi (#31). Componente Pulumi em Go em deploy/pulumi, que cria PostgreSQL no namespace, Job de migração, API e entrada por Gateway API, com Gateway próprio ou pendurado num Gateway existente. Projeto em deploy/stacks com as stacks dev e prod. Ambiente kind em deploy/kind com os requisitos do cluster de produção, com make smoke-kind, make kind-up e painel Headlamp. (#28, #34)

Servidor. SQLite trocado por PostgreSQL com pgx/v5, testes contra Postgres real com testcontainers, configuração só por variável de ambiente com validação de faixa, e a migração saindo do boot para o subcomando markupp migrate. Compose sobe Postgres, migração e servidor. (#32)

Arquitetura. ADR-0032 (escala a zero com KEDA, Proposta), com a reserva por cofre com SKIP LOCKED. ADR-0033 recuperando o indexador como função pura. ADRs 0025 e 0027 revistos para Kubernetes com Pulumi, Gateway API e Postgres no namespace. Diagrama de implantação em draw.io. (#24, #28)

CI e entrega. Smoke da stack dev num kind quando muda servidor ou deploy, testes do componente Pulumi, govulncheck em todos os módulos no CI e no pre-push, e a imagem passando a ser publicada no GHCR da organização. (#28, #29, #33)

Por quê

Fecha o milestone Sprint 2, que vence em 01/10 e pede infraestrutura como código: ambiente IaC e projeto Pulumi com stacks dev e prod.

O que fica de fora

• Domínio e registros DNS (itens 26 e 28 da Sprint 2 do professor) ficam com o professor, no servidor da disciplina
• O deploy em produção espera a autenticação existir, e com ele os requests, limits, probes e securityContext do Postgres e da API
• O pacote no GHCR precisa ser tornado público por um admin da organização depois da primeira tag v*

Como testar

• make test (Go e Docker)
• make run e os curl da seção Validar do docs/DEPLOY.md
• make smoke-kind (Docker, kind, helm, kubectl e Pulumi)
• 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]

A sonda de liveness usa o /healthz, que faz ping no PostgreSQL (internal/api/health.go). Se o banco ficar fora do ar (por exemplo, o pod único do StatefulSet reiniciando por drain de nó ou troca de imagem), todas as réplicas da API falham a liveness e o kubelet as reinicia. Na volta, serve() chama OpenPool, que faz ping e encerra o processo se o banco ainda não responde, então os pods entram em CrashLoopBackOff e a API pode levar minutos para voltar depois que o banco já voltou. Sugestão: deixar só a readiness no /healthz e usar na liveness uma sonda que não dependa do banco (por exemplo, tcpSocket na porta 8080).