GitOps: Quando o Git Vira a Única Fonte da Verdade da Operação

Imagine poder responder a estas três perguntas a qualquer momento, com certeza absoluta e sem entrar em nenhum servidor: o que exatamente está rodando em produção agora? Quem mudou, o quê e quando? E como volto ao estado de ontem se hoje der errado? Na maior parte das operações, essas perguntas geram silêncios desconfortáveis, respostas de "acho que", e escavações em históricos de comandos. O GitOps existe para que a resposta às três seja imediata e confiável, e o mecanismo que ele usa para isso é surpreendentemente simples: fazer do Git a única fonte da verdade sobre o estado do sistema.

GitOps não é uma ferramenta, é um modelo operacional, um conjunto de princípios sobre como operar sistemas declarativos usando o Git como centro de tudo. Ele nasce naturalmente da combinação de duas ideias que já exploramos, a infraestrutura como código e o modelo declarativo do Kubernetes, e as leva a uma conclusão que muda a forma como equipes operam. Este artigo apresenta os princípios do GitOps, a distinção crucial entre os modelos pull e push, e por que essa abordagem entrega auditabilidade e reversibilidade que outros métodos não alcançam.

Os princípios: declarativo, versionado, reconciliado#

O GitOps se apoia em quatro princípios que se encaixam com precisão.

O primeiro é que o sistema inteiro é descrito de forma declarativa. Todo o estado desejado, as aplicações, suas configurações, a infraestrutura, é expresso como declarações, não como scripts de passos. Isso é pré-requisito, e é por isso que o GitOps floresceu no Kubernetes, cujo mundo já é inteiramente declarativo: cada recurso é uma declaração de estado desejado.

O segundo é que o estado desejado é versionado no Git. Os arquivos que descrevem o sistema vivem num repositório Git, que passa a ser a fonte canônica da verdade. Não é uma cópia, não é documentação; é a definição autoritativa do que deve existir. Se não está no Git, não deveria estar rodando.

O terceiro é que as mudanças aprovadas são aplicadas automaticamente. Quando o estado desejado no Git muda, o sistema real é atualizado para corresponder, sem que ninguém rode comandos manuais de deploy. O Git é o gatilho.

O quarto, e mais importante, é que há um agente de reconciliação que continuamente compara o estado real do sistema com o estado desejado no Git e corrige as divergências. Esse agente não age só quando o Git muda; ele age o tempo todo, garantindo que a realidade nunca se afaste do que o Git declara. É o mesmo loop de reconciliação do Kubernetes, agora com o Git como fonte da verdade.

O Git como fonte da verdade muda tudo#

Quando o repositório Git é a definição autoritativa do que roda em produção, propriedades poderosas surgem de graça, herdadas do próprio Git.

Você ganha auditabilidade total. Cada mudança no sistema é um commit, com autor, data, mensagem e o conteúdo exato do que mudou. A pergunta "quem mudou isso e por quê?" tem resposta no histórico do Git, sempre. Não há mais mudanças fantasmas feitas direto no servidor por alguém que não avisou; se está rodando, está no Git, e o Git conta a história completa.

Você ganha revisão e controle de acesso naturais. Mudanças em produção passam a seguir o mesmo fluxo de qualquer código: um pull request, revisado por outra pessoa, aprovado antes de ser mesclado. A porta de entrada para produção deixa de ser o acesso direto ao cluster e vira a permissão de mesclar no repositório. Quem pode mudar produção é quem pode aprovar um PR, e isso é rastreável e governável.

E você ganha um rollback trivial. Como o estado desejado é versionado, voltar atrás é reverter um commit. Um git revert restaura o estado anterior no repositório, o agente de reconciliação percebe a mudança e traz o sistema de volta ao que era. Reverter um deploy ruim vira a mesma operação de reverter qualquer commit, uma habilidade que toda equipe já tem. Não há procedimento especial de emergência; há o fluxo normal do Git, aplicado à operação.

Pull versus push: a distinção que importa#

Há duas formas de implementar a aplicação automática das mudanças, e a diferença entre elas é substancial, especialmente para segurança. Entender as duas é o que separa quem entende GitOps de quem só ouviu falar.

No modelo push, tradicional dos pipelines de CI/CD, o processo é empurrado de fora. Um pipeline, ao detectar uma mudança, se conecta ao cluster e aplica as alterações. O pipeline empurra o estado para dentro do ambiente. Funciona, mas tem uma implicação de segurança séria: o pipeline precisa ter credenciais de acesso de escrita ao cluster, credenciais que vivem no sistema de CI, fora do cluster. Se o sistema de CI for comprometido, essas credenciais dão acesso a produção. A superfície de ataque inclui todo o ambiente de CI.

No modelo pull, que é o coração do GitOps moderno, a lógica se inverte. Um agente que roda dentro do próprio cluster observa o repositório Git e puxa as mudanças para si, aplicando-as de dentro. Ninguém de fora empurra nada; o agente interno puxa. A vantagem de segurança é significativa: as credenciais de acesso ao cluster nunca saem do cluster, porque quem aplica as mudanças já está lá dentro. O sistema de CI não precisa ter acesso de escrita ao ambiente; ele só precisa conseguir mesclar no Git. A superfície de ataque encolhe, porque não há credenciais poderosas guardadas fora do ambiente que elas protegem.

O modelo pull também sustenta melhor a reconciliação contínua. Como o agente vive dentro do cluster e observa o tempo todo, ele detecta e corrige não só mudanças vindas do Git, mas também drift, divergências causadas por alguém que alterou algo diretamente no cluster por fora. O agente percebe que a realidade se afastou do Git e a puxa de volta, restaurando o estado declarado. É a defesa contínua contra a erosão que discutimos no contexto da infraestrutura como código.

O combate ao drift, agora automático#

Vale aprofundar esse ponto, porque é onde o GitOps se destaca sobre a IaC rodada manualmente. Na infraestrutura como código tradicional, o drift, aquela divergência entre o que o código diz e o que existe de fato, precisa ser detectado por alguém que se lembre de rodar um comando de comparação de tempos em tempos. É uma vigilância manual e falha.

No GitOps com modelo pull, o combate ao drift é uma propriedade contínua e automática do sistema. O agente de reconciliação está sempre comparando o real com o declarado no Git. Se alguém, sob pressão de um incidente, altera algo diretamente no cluster, o agente detecta a divergência na próxima passada do seu loop e reverte a mudança manual, restaurando o que o Git declara. Isso tem uma consequência cultural forte e saudável: alterações manuais no cluster simplesmente não persistem, porque são desfeitas. A única forma de mudar algo em definitivo é mudar no Git. O sistema, por construção, força a disciplina de que o Git é a verdade, em vez de depender de as pessoas se comportarem.

Isso conecta o GitOps ao princípio de que servidores não devem ser editados à mão. Quando o ambiente é reconciliado continuamente a partir de um repositório versionado, editar o servidor diretamente deixa de ser apenas uma má prática desencorajada e vira uma ação sem efeito duradouro. A imutabilidade do ambiente, tantas vezes desejada e raramente alcançada, emerge naturalmente do modelo.

Onde o GitOps encaixa no ciclo de entrega#

É útil situar o GitOps em relação ao CI/CD, porque eles se complementam em vez de competir. O pipeline de integração contínua continua fazendo o que sempre fez: construir o artefato, rodar os testes, gerar a imagem imutável e publicá-la. Essa é a parte do CI, e ela não muda com o GitOps.

O que muda é o CD, a entrega. Em vez de o pipeline empurrar o deploy para o cluster, o passo final da esteira passa a ser apenas atualizar o repositório Git com a referência ao novo artefato, tipicamente a nova tag da imagem. A partir daí, o agente de reconciliação assume: ele vê a mudança no Git e reconcilia o cluster para rodar a versão nova. A fronteira fica limpa: o CI produz e valida o artefato, o Git registra a intenção de implantá-lo, e o agente GitOps executa a implantação de dentro do cluster. Cada parte tem uma responsabilidade única e uma interface clara com as outras. Se você quiser revisar os fundamentos da esteira que alimenta esse fluxo, vale reler os princípios de pipelines de CI/CD, sobre os quais o GitOps se apoia sem substituir.

O valor no fim das contas#

Voltando às três perguntas do início. O que roda em produção agora? O que o Git declara, porque o agente garante que a realidade o honra. Quem mudou, o quê e quando? O histórico de commits, com autor e mensagem em cada mudança. Como volto ao estado de ontem? Um revert do commit de hoje, reconciliado automaticamente. As três respostas que antes geravam silêncio passam a ser imediatas e confiáveis.

O GitOps não inventa conceitos novos; ele combina os que já existiam, o declarativo, o versionamento, a reconciliação, e os aponta para um lugar só, o Git, com uma coerência que produz auditabilidade, segurança e reversibilidade como subprodutos naturais. Para equipes que já operam sistemas declarativos, adotá-lo é menos uma revolução e mais o encaixe final de peças que já estavam na mesa. E o resultado é uma operação onde a pergunta "o que está rodando e por quê?" nunca mais precisa terminar em "deixa eu entrar no servidor para ver".

GitOps não é bala de prata#

Vale registrar o outro lado. GitOps adiciona uma camada de indireção: nada chega ao cluster sem passar pelo repositório e pelo controlador de reconciliação, e isso impõe disciplina que equipes pequenas às vezes sentem como fricção. Depurar um estado que não converge exige entender o operador, os eventos de reconciliação e os logs do controlador, não apenas o kubectl. Segredos precisam de uma estratégia própria — SOPS, Sealed Secrets ou um provedor externo — porque commitar credencial em texto puro no repositório declarativo seria o pior dos mundos. E a promessa de auditoria só se cumpre se o acesso de escrita direto ao cluster for de fato revogado; enquanto alguém puder aplicar um manifesto à mão por fora do fluxo, o Git deixa de ser a fonte única da verdade e vira apenas mais uma cópia. GitOps compensa quando a equipe assume esses custos conscientemente, não como moda.