Um setup pragmático de Argo CD — GitOps que sobrevive ao contato com a realidade

Argo CD é um daqueles projetos extremamente populares e extremamente mal implantados. Todo time com que trabalho tem alguma versão do Argo CD rodando. Talvez um terço deles o configurou de uma forma que realmente economiza esforço em vez de ser uma versão pior do kubectl apply com YAML extra.

A diferença geralmente está em três lugares: estrutura do repo, orquestração de sync waves, e como você lida com secrets.

A disposição de repo App-of-Apps

gitops-repo/
├── bootstrap/                  # root app-of-apps
├── platform/                   # infra cluster-wide (ingress, cert-manager, …)
├── tenants/
│   ├── team-payments/{dev,staging,prod}/
│   └── team-search/{dev,staging,prod}/
└── projects/                   # fronteiras RBAC AppProject

Uma única Application raiz inicializa o cluster. platform/ é propriedade do time de plataforma. Cada tenant tem sua própria pasta por ambiente, então a promoção é um PR que copia manifestos de um diretório para o próximo.

O artigo completo cobre:

• Sync waves — a convenção de numeração que usamos em cada cluster
• Por que usamos External Secrets Operator + um vault, não sealed-secrets (rotação)
• Auto-sync para dev/staging, sync manual para prod (e por quê)
• ApplicationSet para padrões de frota-de-ambientes
• Notificações: os alertas do Slack que realmente importam
• Fazer backup do Argo CD e as lições da vez em que não fizemos

Entregamos essa disposição em cada cluster Kubernetes gerenciado.