Projeto 01: API com infraestrutura própria

Problema

#

Laboratório de infraestrutura num servidor Proxmox, com rede segmentada simulando produção. Um roteador MikroTik CHR separa quatro VLANs, e quatro VMs Linux rodam aplicação, banco, monitoramento e CI. A aplicação é uma API de contas e transferências idempotentes em PostgreSQL, intencionalmente simples, para que o foco fique na engenharia ao redor.

O Terraform cria as VMs e os discos de dados, o Ansible configura tudo, e o acesso administrativo só passa por VPN WireGuard.

A decisão que mais importa: o disco do sistema é descartável e o disco de dados sobrevive à recriação da VM. Testei isso: gravei um arquivo com checksum, destruí a VM, recriei e o arquivo estava lá com o mesmo checksum.

Decisões técnicas e o motivo

#

1. Disco de dados em stack separada (data/). Recriar a VM não pode apagar o banco. O disco pertence a uma stack com prevent_destroy, e a VM de banco só anexa esse disco. Equivale a um volume EBS que sobrevive à instância.
2. Duas stacks com estado separado. Dados mudam pouco, VMs mudam muito. O disco precisa existir antes da VM, então a ordem do apply importa.
3. VMs num for_each alimentado por um mapa de variáveis. Adicionar uma VM é uma linha no tfvars.
4. CHR tratado como “pet”. Ele é o ponto de entrada da rede: se cai, tudo cai. Por isso tem prevent_destroy e fica fora do for_each.
5. Firewall com menor privilégio por fluxo. Só o monitoramento acessa o banco para backup, e só o CI acessa o SSH do app. Validei com testes de isolamento: fluxos bloqueados dão timeout, fluxos permitidos respondem.
6. Estado remoto no GitLab, com lock. Cada stack tem o seu estado.
7. Segredos fora do código. Credenciais do Proxmox ficam em variáveis de ambiente, e as senhas no vault do Ansible.

Desafios reais

#

1. Clones paralelos no NFS travavam. Limitei o apply a -parallelism=1 e documentei o motivo.
2. Runner do GitLab ignorava o ansible.cfg. O diretório /builds era gravável por todos, e o Ansible descartava a configuração. Resolvi definindo ANSIBLE_CONFIG no job.
3. Primeiro boot lento. O cloud-init faz apt upgrade, então o Ansible espera a VM terminar.

O que eu faria diferente

#

1. Configuraria o CHR por automação, com teste das regras de firewall. Hoje ele foi configurado à mão.
2. Avaliaria o risco do path_in_datastore, que é experimental no provider bpg/proxmox, antes de depender dele em produção.

Evidências

#

Arquitetura do laboratório

#

Tecnologias

#

Terraform, Ansible, Proxmox, MikroTik, Docker, GitLab CI, PostgreSQL, Prometheus, Grafana, Alertmanager, Trivy, FastAPI.