Blog/Artigos · Cloud e Plataforma
O Git como fonte única de verdade, o laço de reconciliação, o modelo pull e as ferramentas ArgoCD e Flux, com os princípios do OpenGitOps.
O lamento pede o retorno: faze-nos voltar, e voltaremos ao estado certo. Há um desejo declarado e um mecanismo que puxa a realidade de volta a ele, sem cessar. GitOps é isso aplicado à operação de sistemas. O estado desejado de tudo o que roda vive escrito no Git, e um controlador compara o que existe com o que está escrito e, quando divergem, puxa a realidade de volta ao declarado. Deploy deixa de ser um comando que alguém dispara e vira um commit que o sistema persegue. Rollback deixa de ser corrida de pânico e vira reverter um commit. O repositório declara para onde voltar, e o laço não descansa até chegar lá.
O termo GitOps foi cunhado pela Weaveworks em 2017, e a CNCF depois destilou o conceito em quatro princípios no OpenGitOps. O primeiro e mais importante: o estado desejado do sistema é declarativo. O segundo: esse estado é versionado e imutável, guardado no Git, com histórico completo. O terceiro: a mudança é puxada e aplicada automaticamente por um agente. O quarto: o sistema é reconciliado sem parar, corrigindo qualquer divergência. Juntos, eles transformam a operação num artefato que se lê, se revisa e se reverte como código.
A consequência prática é poderosa. Toda mudança de produção passa a ter um pull request, com revisão e aprovação antes de chegar ao cluster. O histórico do Git responde à pergunta que atormenta toda operação: o que mudou, quando e por quem, no dia em que algo quebrou. E o rollback deixa de ser um procedimento tenso decorado às pressas e vira reverter o commit, com a mesma calma de qualquer revert de código. A operação herda toda a disciplina que o desenvolvimento já tinha, e o operador solitário mudando produção por fora do processo simplesmente deixa de existir.
O motor do GitOps é o laço de reconciliação. Um controlador dentro do cluster observa duas coisas sem parar: o estado desejado, que está no Git, e o estado atual, que está no cluster. Quando os dois batem, ele descansa. Quando divergem, seja porque um commit novo mudou o desejado, seja porque alguém mexeu no cluster à mão, ele age para trazer o atual de volta ao desejado. É o mesmo laço que o Kubernetes já usa internamente para manter o número de réplicas, agora estendido para o estado inteiro do sistema, vindo do Git.
Esse laço muda a natureza do drift. Sem GitOps, a mudança feita à mão no cluster durante um incidente fica lá, silenciosa, até quebrar algo depois. Com GitOps e o self-heal ligado, o laço desfaz a mudança manual em minutos, porque ela não está no Git, e força quem corrigiu a fazer a correção do jeito certo: commitando. Isso incomoda no começo e salva depois: o cluster para de acumular remendos invisíveis, e o Git volta a ser a verdade, não uma ficção que já não descreve o que roda. A disciplina é chata na emergência e impagável na auditoria.
GitOps favorece o modelo pull, e a razão é de segurança. No modelo push tradicional, o pipeline de CI tem credenciais do cluster de produção e empurra a mudança de fora. Isso significa que o sistema de CI, exposto e alvo constante, guarda a chave da produção, e comprometê-lo é comprometer o cluster. No modelo pull do GitOps, um agente vive dentro do cluster e puxa o estado desejado do Git para dentro; o cluster não precisa aceitar conexão de fora, e o CI não precisa guardar credencial de produção.
A inversão parece um detalhe e é uma mudança grande de superfície de ataque. A credencial poderosa deixa de morar no pipeline e passa a ser um segredo interno do cluster, que só lê o Git. O deploy deixa de ser algo empurrado por um sistema externo e passa a ser algo que o próprio ambiente busca, no seu tempo, verificando a assinatura do que puxa. Para ambiente regulado, isso é ouro: reduz o número de sistemas que têm acesso de escrita à produção a praticamente um, e esse um faz uma coisa só, auditável, que é reconciliar o que está escrito.
Duas ferramentas dominam GitOps em Kubernetes, ambas projetos graduados da CNCF. O ArgoCD, da Intuit, traz uma interface visual forte, que mostra a árvore de recursos e o estado de sincronização de cada um, e o padrão app-of-apps, onde uma aplicação GitOps gerencia outras, escalando para dezenas de times. O Flux, da Weaveworks e hoje comunitário, é mais enxuto e componível, feito de controladores pequenos que se combinam, e integra bem com quem prefere operar por linha de comando e por manifesto, sem portal.
A escolha entre os dois é menos importante que o compromisso com o modelo. Os dois fazem o essencial: sincronizam o cluster com o Git, detectam drift e reconciliam, com self-heal opcional. O ArgoCD tende a agradar quem quer visibilidade visual e governança multi-time num painel; o Flux, quem quer minimalismo e composição. O erro não é escolher errado entre eles; é adotar a ferramenta e continuar mudando o cluster à mão por fora, o que transforma o GitOps numa mentira bonita: um painel verde que jura sincronia enquanto a operação real acontece nas costas dele.
| Aspecto | ArgoCD | Flux |
|---|---|---|
| Origem | Intuit, graduado na CNCF | Weaveworks, comunitário, graduado na CNCF |
| Interface | portal visual forte, árvore de recursos | enxuto, orientado a manifesto e linha de comando |
| Escala multi-time | app-of-apps, um app gerencia outros | controladores componíveis, GitOps por namespace |
| Perfil | quem quer visibilidade e governança num painel | quem quer minimalismo e composição |
| O essencial | sincroniza, detecta drift, self-heal | sincroniza, detecta drift, self-heal |
GitOps amadurece em degraus claros. No começo é um repositório com manifestos aplicados à mão, ganhando só o histórico. No meio é uma ferramenta sincronizando o cluster a partir do Git, com deploy virando commit. No topo é o modelo pull com self-heal ligado, drift corrigido sozinho, promoção entre ambientes por pull request e a operação inteira sendo, de fato, o que está escrito. Cada degrau tira mais um caminho de mudança que não passa pelo Git, até sobrar só um.
GitOps não vive isolado: ele senta sobre o IaC, que escreve a infraestrutura, e sobre o Kubernetes, cujo laço de reconciliação ele estende. É a peça que fecha a promessa da plataforma, porque transforma o golden path de deploy em algo que o próprio ambiente persegue, sem ninguém empurrar. Quando a operação inteira volta sozinha ao que está escrito, o lamento se cumpre ao contrário: não é mais o operador que faz o sistema voltar, é o sistema que volta sozinho ao estado certo, e o trabalho humano se desloca para decidir qual é o estado certo, escrevendo-o no Git.
GitOps faz a operação voltar sozinha ao estado escrito no Git, como o lamento que pede o retorno. Os quatro princípios do OpenGitOps, declarativo, versionado, puxado e reconciliado sem parar, transformam deploy em commit e rollback em revert. O laço de reconciliação corrige o drift, o modelo pull tira a credencial de produção do pipeline, e ArgoCD ou Flux implementam o essencial. A IA explica a divergência e denuncia a mudança feita por fora. Mas decidir qual é o estado certo, e escrevê-lo no Git, continua sendo o trabalho humano, agora sem o operador solitário mudando produção no escuro.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Cloud e Plataformaכְּתָב
Infra criada no clique não se reproduz e ninguém sabe explicar. IaC escreve a infraestrutura como código versionado e revisável, e o que está escrito se materializa igual toda vez. O perigo mora no state, e a maturidade em tratar servidor como gado, não como bicho de estimação.
Cloud e Plataformaחוֹבֵל
Kubernetes é grego para timoneiro, e é isso que ele faz: você declara o estado desejado e ele conduz a frota de contêineres até lá, corrigindo sozinho o que sai da rota. O poder é real, e a complexidade também, e a maturidade começa em saber quando não içar essa vela.
