GitOps avançado - automação de deploy, rollback e boas práticas para produção

#kubernetes #devops #gitops #argocd

1. Retomando: da sincronização manual à confiança em produção

Esta série cobriu, até aqui, o suficiente para operar Kubernetes com GitOps no dia a dia: conceitos fundamentais de Pods, Deployments e Services, kubectl, namespaces, ConfigMaps e Secrets, e uma introdução ao ArgoCD com uma Application sincronizando um repositório ao cluster. Este último artigo fecha a lacuna entre "o ArgoCD está instalado" e "confio nesse pipeline para colocar mudanças em produção sem supervisão constante": automação completa de deploy, rollback automático, sync policies mais refinadas e as boas práticas que separam um setup de demonstração de um setup pronto para produção.

2. Automatizando o deploy de ponta a ponta

Um pipeline GitOps completo normalmente combina CI (que constrói e testa a aplicação) com CD via ArgoCD (que aplica o resultado ao cluster). O CI não aplica nada diretamente ao cluster — sua única responsabilidade é atualizar o repositório de manifests com a nova versão, deixando o ArgoCD detectar e aplicar a mudança:

# .github/workflows/deploy.yml
name: build-and-release
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build e push da imagem
        run: |
          docker build -t registry.exemplo.com/minha-app:${{ github.sha }} .
          docker push registry.exemplo.com/minha-app:${{ github.sha }}

      - name: Atualizar tag da imagem no repositório de manifests
        run: |
          git clone https://github.com/minha-org/minha-app-manifests.git
          cd minha-app-manifests
          kustomize edit set image minha-app=registry.exemplo.com/minha-app:${{ github.sha }}
          git commit -am "deploy: minha-app@${{ github.sha }}"
          git push

Esse último passo — um commit automatizado no repositório de manifests, trocando a tag da imagem — é o gatilho que faz o ArgoCD (com syncPolicy.automated configurado, como visto no artigo anterior) detectar a diferença e aplicar o rollout automaticamente, sem que o pipeline de CI precise de nenhuma credencial de acesso ao cluster. Essa separação — CI só escreve no Git, só o ArgoCD escreve no cluster — é o núcleo do que torna GitOps mais seguro que um pipeline de CI tradicional com kubectl apply direto.

3. Rollback automático

Um dos ganhos mais concretos de GitOps aparece quando um deploy dá errado. Como cada mudança é um commit, reverter um deploy problemático é, em princípio, tão simples quanto reverter o commit:

# Reverter o último commit que trocou a tag da imagem
git revert HEAD
git push

O ArgoCD detecta essa reversão como qualquer outra mudança no repositório e aplica automaticamente, voltando o cluster para o estado anterior. Isso pode (e deve) ser combinado com verificações automáticas de saúde, para que o rollback aconteça sem esperar alguém perceber manualmente que algo quebrou:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: minha-app
  namespace: argocd
spec:
  # ...
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    retry:
      limit: 3
      backoff:
        duration: 30s
        factor: 2
        maxDuration: 5m

O bloco retry faz o ArgoCD tentar novamente uma sincronização que falhou, com backoff exponencial — útil para falhas transitórias (um readiness probe que demora um pouco mais que o normal, por exemplo) sem exigir intervenção manual. Para rollback automático baseado na saúde real da aplicação (não só no sucesso da sincronização), ferramentas complementares como o Argo Rollouts adicionam estratégias de deploy progressivo — canary ou blue-green — que promovem ou revertem uma nova versão automaticamente com base em métricas (taxa de erro, latência) coletadas durante o rollout.

4. Sync policies mais refinadas

Nem toda mudança deveria ser sincronizada automaticamente e sem revisão. O ArgoCD permite refinar isso por Application:

spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ApplyOutOfSyncOnly=true
  ignoreDifferences:
    - group: apps
      kind: Deployment
      jsonPointers:
        - /spec/replicas

CreateNamespace=true cria o namespace de destino automaticamente, se ainda não existir — evita um passo manual de setup antes do primeiro deploy de uma aplicação nova.
ApplyOutOfSyncOnly=true aplica só os recursos que de fato divergem do Git, reduzindo o "ruído" de reaplicar tudo a cada sincronização.
ignoreDifferences diz ao ArgoCD para ignorar divergências em um campo específico — no exemplo, spec/replicas de Deployments, útil quando um Horizontal Pod Autoscaler (HPA) ajusta o número de réplicas dinamicamente e não se quer que o ArgoCD reverta esse ajuste para o valor fixo declarado no Git.

Em ambientes com múltiplos times, é comum também restringir permissões via AppProject do ArgoCD — limitando quais repositórios, clusters e namespaces cada Application pode usar como fonte ou destino, em vez de dar acesso irrestrito a todo o cluster para qualquer Application criada.

5. Boas práticas para produção

Algumas práticas que separam um cluster GitOps de demonstração de um pronto para produção:

Nunca commitar Secrets em texto plano — retomando o ponto levantado no Artigo 2 desta série: use Sealed Secrets, SOPS ou integração com um cofre externo (Vault, AWS Secrets Manager) para versionar segredos com segurança dentro do fluxo GitOps.
Separar repositórios de aplicação e de manifests — o repositório com o código-fonte da aplicação e o repositório com os manifests Kubernetes costumam ser diferentes, cada um com seu próprio controle de acesso; isso também evita que um push no código dispare acidentalmente uma sincronização do ArgoCD antes de a imagem estar pronta.
Revisão obrigatória para produção — mesmo com sincronização automática ligada, proteger a branch/pasta que aponta para produção com exigência de pull request revisado, para que nenhuma mudança chegue ao cluster sem pelo menos um segundo par de olhos.
Monitorar o próprio ArgoCD — um controlador GitOps fora do ar (ou com a sincronização travada) significa que mudanças urgentes, incluindo rollbacks, não chegam ao cluster; alertas sobre a saúde do ArgoCD são tão importantes quanto alertas sobre a aplicação em si.
Começar com sync manual, migrar para automático aos poucos — para aplicações críticas, é razoável começar sem syncPolicy.automated, validar o processo com sincronizações manuais revisadas, e só ligar a automação depois que o time confia no pipeline de CI e nos testes que o precedem.

6. Conclusão da série

Ao longo desses quatro artigos, esta série foi do "o que é um Pod" a um pipeline GitOps completo: os conceitos fundamentais do Kubernetes (Pods, Deployments, Services), o kubectl e a organização de recursos com namespaces, ConfigMaps e Secrets, a introdução ao GitOps e ao ArgoCD, e finalmente automação de deploy de ponta a ponta, rollback automático via Git e as boas práticas que tornam esse fluxo seguro o suficiente para produção. A partir daqui, a base está posta para explorar tópicos mais específicos — deploys progressivos com Argo Rollouts, gestão de segredos com Sealed Secrets ou Vault, observabilidade de clusters — mas o par Kubernetes + GitOps, bem implementado, já resolve a maior parte do desafio de operar aplicações em produção com confiança e rastreabilidade.

Imagem de capa: Logo oficial do Kubernetes — repositório kubernetes/kubernetes

Referências:

DEV Community