O Desafio da Escalabilidade no GitOps

Atualmente, esse assunto está sendo muito falado, mas afinal, o que seria GitOps e o Argo CD? Hoje eu vou te explicar de maneira básica e simplificada para facilitar o seu entendimento.

No modelo tradicional de implantação, nós usamos pipelines (como Gitlab ou GitHub Actions) para “empurrar” (push) o nosso código para dentro do Kubernetes usando comandos como kubectl apply.

Embora funcione bem no início, esse modelo quebra quando a infraestrutura cresce. Se um desenvolvedor alterar um recurso direto pelo terminal ou painel da nuvem, o seu pipeline não fica sabendo. Isso gera o Configuration Drift: o código no Git diz uma coisa, mas a realidade no cluster é totalmente outra.

Para resolver esse caos nasce o GitOps: um paradigma onde o repositório Git passa a ser a Fonte Única da Verdade da sua infraestrutura. Se uma configuração está no Git, ela deve estar no cluster; se não está no Git, ela não deve existir.

O GitOps na Prática: Exemplos do Dia a Dia
Para entender como essa “Fonte da Verdade” funciona na vida real, imagine estes três exemplos comuns em um e-commerce:

Exemplo 1 (Deploy de Nova Versão): Você atualizou a API de pagamentos. Em vez de rodar um comando no cluster, você apenas altera a tag da imagem de v1.0 para v1.1 no seu arquivo YAML dentro do Git. O sistema lê o Git e atualiza o Kubernetes sozinho.

Exemplo 2 (Segurança e Auditoria): Um desenvolvedor apagou um Ingress por engano direto pelo terminal. O motor de GitOps detecta que o cluster divergiu do Git e recria o Ingress imediatamente, revertendo a falha humana sem nenhuma intervenção manual.

Exemplo 3 (Criação de Ambientes): A empresa precisa criar um ambiente de homologação idêntico ao de produção. Com GitOps, você não refaz nada no braço: basta apontar a ferramenta para a pasta do Git e ela constrói o novo cluster do zero em minutos.

O Modelo Tradicional (Self-Managed / Core Básico)
Quando instalamos o Argo CD e começamos a dar os nossos primeiros passos, tudo parece mágico. Você vai lá na interface web ou na CLI, cria um Ingress, um Service ou um Deployment e vê tudo sincronizando em tempo real.

Mas o que acontece quando o e-commerce da sua empresa cresce e passa de 2 para 50 microsserviços?

Se continuarmos nessa abordagem tradicional, para cada novo microsserviço (como a API de carrinho ou o frontend), você terá que ir até a tela do Argo CD e criar manualmente um recurso chamado Application.

Cada Application é um arquivo YAML independente que diz ao Argo CD: “Olhe para este repositório Git específico e jogue os manifestos dele dentro do Kubernetes”.

Exemplo de Yaml:

Exemplo de uma aplicação criada para a API de Carrinho

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: ecommerce-carrinho
namespace: argocd
spec:
project: default
source:
repoURL: ‘https://github.com/devops-team/meu-ecommerce-gitops.git’
targetRevision: HEAD
path: manifestos/carrinho
destination:
server: ‘https://kubernetes.default.svc’
namespace: ecommerce
syncPolicy:
automated:
prune: true
selfHeal: true

Vantagens dessa abordagem:
Simplicidade visual: É muito fácil ver o status de cada pecinha do sistema de forma isolada na tela do Argo CD.

Curva de aprendizado baixa: Ótimo para quando você está testando o ambiente ou trabalhando com poucos serviços.

O Gargalo (Por que ela quebra na escala?):
Ficar criando aplicações manualmente na tela do Argo vira um pesadelo de gerenciamento e quebra a própria premissa do GitOps de ter “tudo como código”. Se o seu cluster quebrar hoje, você terá que aplicar manualmente esses 50 arquivos de Application no braço de novo. Não existe uma “mãe” que gerencie essas aplicações.

O Padrão App-of-Apps (A Solução de Elite)
Para resolver o pesadelo de gerenciar dezenas de aplicações manualmente, a comunidade de Kubernetes adotou um padrão de design elegante chamado App-of-Apps.

A ideia é simples, mas genial: em vez de você cadastrar 50 aplicações no painel do Argo CD, você cadastra apenas uma única aplicação, chamada de Root App (Aplicação Raiz). Essa Root App não aponta para o código do seu e-commerce, mas sim para uma pasta no Git que contém… os manifestos de todas as outras aplicações!

O próprio Argo CD se encarrega de ler essa pasta e criar todas as “Aplicações Filhas” de forma 100% automatizada.

Como funciona na prática?
Primeiro, você cria o arquivo da Root App. Ele é o único manifesto que você vai aplicar manualmente no seu cluster uma única vez:

root-app.yaml – A aplicação que gerencia todas as outras

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: root-application
namespace: argocd
spec:
project: default
source:
repoURL: ‘https://github.com/devops-team/meu-ecommerce-gitops.git’
targetRevision: HEAD
path: manifestos/apps # <– Pasta no Git onde ficam os YAMLs das outras apps
destination:
server: ‘https://kubernetes.default.svc’
namespace: argocd
syncPolicy:
automated:
prune: true
selfHeal: true

Depois, dentro da pasta manifestos/apps no seu repositório Git, você joga os arquivos YAML das suas aplicações de verdade (como a API de carrinho, API de pagamento, frontend, etc.).

Quando o Argo CD sincroniza a Root App, ele olha para dentro da pasta, encontra as definições das aplicações filhas e começa a implantar tudo em cascata.

vantagens do App-of-Apps:

Cluster Bootstrap em um único comando: Se o seu cluster do Kubernetes sumir do mapa, você não precisa se desesperar. Basta subir um cluster novo e rodar kubectl apply -f root-app.yaml. O Argo CD vai puxar o Git e reconstruir o ambiente inteiro sozinho em minutos.

Tudo como Código de verdade: Quer adicionar um novo microsserviço no cluster? Você não abre o painel do Argo. Você apenas cria um arquivo YAML novo, joga na pasta do Git e dá um git push. O Argo CD se auto-gerencia e cria o novo sistema.

Governança centralizada: Você tem um único repositório Git que dita exatamente tudo o que deveria estar rodando no cluster.

Desvantagens:
Complexidade estrutural: Exige que o time seja muito organizado com a estrutura de pastas do Git.

Ponto único de falha: Se alguém cometer um erro de sintaxe bizarro no manifesto da Root App, pode travar temporariamente a sincronização ou a leitura das aplicações filhas.

O Próximo Passo na sua Jornada GitOps

Implementar o GitOps com o Argo CD vai muito além de apenas automatizar o kubectl apply. É sobre criar uma cultura onde a infraestrutura é previsível, auditável e, acima de tudo, resiliente a falhas.

O modelo tradicional (Self-Managed) é uma excelente porta de entrada. Ele te ajuda a entender como o motor do Argo funciona, como as sincronizações acontecem e como debugar os primeiros erros de comunicação e Ingress no Kubernetes.

No entanto, quando olhamos para cenários reais de mercado — como o ecossistema de um grande e-commerce que precisa lidar com dezenas de microsserviços em paralelo —, o padrão App-of-Apps deixa de ser um luxo e se torna uma necessidade de sobrevivência para o time de Arquitetos. Ele garante que o seu Argo CD se gerencie sozinho, transformando o gerenciamento de aplicações em um processo escalável, elegante e totalmente declarativo.

Agora que você já conhece a diferença entre essas duas abordagens, que tal olhar para o seu cluster atual e planejar a migração para o App-of-Apps? A sua resiliência a desastres (e as suas noites de sono) com certeza vão agradecer!