Argo CD: o deploy que se arruma sozinho
O que é o Argo CD, o que muda em relação ao jeito tradicional de colocar sistemas no ar e por que o Git virou a planta da obra. Explicado para quem não é da área.

Sabe aquele deploy de sexta-feira às 18h? Alguém roda um comando no servidor, confere se o site abriu, reza um pouquinho e vai para casa. Na segunda, aparece um problema e começa a investigação: quem mexeu, quando, e o que exatamente foi feito?
Deploy, para quem não é da área, é o momento de colocar uma versão nova de um sistema no ar. E o Argo CD existe para que esse momento deixe de depender de alguém digitando comandos. Em vez de uma pessoa (ou um script) empurrar o sistema para o servidor, o próprio ambiente olha para um lugar combinado e se ajusta sozinho até ficar igual ao que está escrito lá.
Primeiro, três palavras
Para entender o Argo CD, vale traduzir a definição que está na documentação oficial: uma ferramenta de entrega contínua, declarativa e baseada em GitOps, para Kubernetes. Por partes:
- Kubernetes é o “síndico” de um prédio de servidores. Ele decide em qual máquina cada pedaço do sistema roda, reinicia o que cai e cria cópias quando o movimento aumenta. Esse conjunto de máquinas gerenciado por ele se chama cluster.
- Declarativo quer dizer que você não escreve a receita passo a passo. Você descreve como o resultado deve ficar (“três cópias do site, na versão 2.4”) e a ferramenta se vira para chegar lá.
- Git é o histórico de versões que programadores usam para guardar código: dá para ver quem mudou o quê, quando, e voltar a qualquer ponto.
Uma ideia com nome: GitOps
Juntar essas peças tem nome. Foi na Weaveworks, uma empresa de software, que o CEO Alexis Richardson batizou a prática de GitOps, num texto de 2017 chamado “Operations by Pull Request”. Um ano depois, ele resumiu a ideia em outro post do blog da empresa: o repositório Git é a única fonte da verdade sobre como o sistema deve estar, e toda mudança passa por ele.
A analogia que eu mais gosto é a da obra. O Git é a planta da casa. O Argo CD é um mestre de obras que fica lá 24 horas por dia, comparando a obra com a planta. Se alguém derruba uma parede que está na planta, ele percebe e avisa, ou reconstrói. Se o arquiteto muda a planta, ele executa a mudança.
De onde veio o Argo CD
O projeto Argo foi criado e aberto ao público em 2017 pela Applatix, uma startup que depois foi comprada pela Intuit, segundo o anúncio da CNCF, a fundação que cuida do Kubernetes e de outros projetos do tipo. O Argo CD é uma das partes dessa família.
O projeto entrou na CNCF em abril de 2020 e, em 6 de dezembro de 2022, chegou ao nível mais alto de maturidade da fundação, o mesmo do próprio Kubernetes. Na época, mais de 350 organizações já usavam o Argo em produção, entre elas Adobe, Capital One, Google, Tesla e Volvo, segundo o mesmo anúncio.
Como ele funciona por dentro
O Argo CD roda dentro do próprio Kubernetes e faz uma coisa o tempo todo: compara o estado desejado (o que está no Git) com o estado atual (o que está de fato rodando). Quando os dois batem, a aplicação aparece como sincronizada. Quando alguém muda algo no Git, ou mexe direto no servidor, ela vira OutOfSync, “fora de sincronia”.
Nessa hora, ele mostra exatamente o que está diferente e pode sincronizar sozinho ou esperar alguém apertar o botão. Quem decide é o time. A documentação também diz que ele entende vários formatos de configuração (Helm, Kustomize, Jsonnet ou arquivos YAML simples) e que dá para acompanhar uma branch, uma etiqueta de versão ou um ponto exato do histórico.
O que muda em relação ao jeito tradicional
A grande virada é trocar o empurrar pelo puxar. Hoje, em muita empresa, existe uma esteira automática (o pipeline de CI/CD) que testa a versão nova e, no fim, entra no servidor e instala. Para isso, essa esteira precisa guardar as chaves de acesso à produção.
Com o Argo CD, a esteira continua testando e montando a versão nova, mas para no Git: ela só atualiza a planta. Quem leva a mudança para o servidor é o Argo CD, que já mora lá dentro. Resultado: as chaves de produção não precisam ficar espalhadas por aí, e o servidor nunca fica diferente do Git sem que alguém perceba.
As melhorias, segundo a documentação
Da lista de recursos da documentação oficial, estes são os que mais mudam a rotina:
- Voltar atrás para qualquer versão que já esteve no Git.
- Detecção automática de diferenças entre o que deveria estar rodando e o que está.
- Vários clusters num painel só, com a saúde de cada aplicação em tempo real.
- Login único e permissões por time, para cada um mexer só no que é seu.
- Registro de quem fez o quê, com trilha de auditoria de eventos e chamadas.
- Ganchos antes e depois de cada sincronização, que permitem estratégias como colocar a versão nova no ar só para uma parte dos usuários primeiro.
Como começar sem complicar
Quem já tem um cluster Kubernetes consegue instalar o Argo CD com dois comandos, que estão na própria documentação:
kubectl create namespace argocd
kubectl apply -n argocd --server-side --force-conflicts \
-f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
Depois disso, o caminho tranquilo é:
- Separar um repositório só para a configuração do que deve rodar, longe do código do sistema.
- Cadastrar uma aplicação pequena, num ambiente de testes, apontando para esse repositório.
- Começar com a sincronização manual, olhando no painel o que o Argo CD aplicaria antes de deixar ele aplicar.
- Tirar da esteira o passo de instalar no servidor: ela passa a só atualizar a versão no repositório.
- Ligar a sincronização automática quando o time estiver confiante.
O guia “Getting Started” da documentação tem o passo a passo completo, com acesso ao painel e uma aplicação de exemplo.
O que melhora no dia a dia
O ganho mais visível não é técnico, é de tranquilidade. Colocar uma versão nova no ar vira aprovar uma alteração no Git. Deu ruim? Desfaz a alteração e o ambiente volta sozinho. Acaba o “quem mexeu no servidor?”, porque tudo passa pelo histórico, com autor, data e motivo. Quem chega no time entende o ambiente lendo um repositório. E recriar tudo num servidor novo é apontar o Argo CD para a mesma planta.
Comecei a programar aos 11 anos, e de lá para cá vi muito deploy feito na unha, com aquele frio na barriga antes de apertar o Enter. O que mudou de lá para cá foi quem faz o trabalho braçal. O que continua igual é a pergunta de sempre: o que está no ar é mesmo o que a gente combinou? Com o Argo CD, a resposta fica escrita.


