DevOpsQuest
0 XP
Módulo 9 · GitOps com ArgoCD

Pipeline de imagem + GitOps: o fluxo completo

Avançado 40 min+25 XPGitHub ActionsArgoCDKustomize

Objetivos desta aula

  • Conectar CI de imagem a atualização de manifests
  • Automatizar bump de versão por PR
  • Definir governança de deploy

O fluxo maduro tem dois repositórios e dois papéis. O CI da aplicação testa, constrói e publica a imagem com tag imutável. Em seguida, um passo abre PR no repositório GitOps atualizando a tag do overlay do ambiente. Quem revisa esse PR está autorizando o deploy.

Para staging, esse PR pode ter merge automático — feedback rápido é mais valioso que cerimônia. Para produção, revisão humana e janela definida. Assim o mesmo mecanismo atende dois níveis de risco sem ferramentas diferentes.

Alternativa: ArgoCD Image Updater observa o registry e atualiza a tag automaticamente. É conveniente, mas reduz a rastreabilidade de 'quem decidiu implantar'. Em produção, prefira o PR explícito.

1. O fluxo ponta a ponta

  1. Dev abre PR em cloudshop-app
  2. CI roda testes, lint e scan
  3. No merge, build da imagem com tag do commit, SBOM e assinatura
  4. CI abre PR (ou commit) em cloudshop-gitops trocando a tag de staging
  5. ArgoCD sincroniza staging; smoke tests validam
  6. Promoção para prod via PR aprovado

2. Tag imutável e digest

Use a tag do commit (sha-abc1234) ou, melhor, o digest @sha256:…. latest impede saber o que roda e quebra rollback.

3. Quem atualiza o Git

Opções: o próprio CI com um GitHub App de escopo mínimo, ou o Argo CD Image Updater observando o registry. Em ambos, a credencial só escreve no repo de config, nunca no cluster.

4. Garantindo a cadeia

Uma política no cluster (Kyverno ou Sigstore policy-controller) só admite imagens assinadas pelo seu pipeline. Assim, mesmo alguém com acesso ao Git não sobe imagem desconhecida.

5. Medindo o resultado

Com o fluxo completo você mede as métricas DORA: frequência de deploy (merges no gitops), lead time (commit → sync em prod), taxa de falha e tempo de recuperação (revert → sync).

Na prática

CI abre PR no repositório GitOps

yaml

name: promover-staging
on:
  workflow_run:
    workflows: [ci]
    types: [completed]
    branches: [main]

permissions:
  contents: read

jobs:
  bump:
    if: github.event.workflow_run.conclusion == 'success'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          repository: sua-org/cloudshop-gitops
          token: ${{ secrets.GITOPS_PR_TOKEN }}
      - uses: imranismail/setup-kustomize@v2
      - name: Atualizar tag da imagem no overlay de staging
        run: |
          cd overlays/staging
          kustomize edit set image ghcr.io/sua-org/cloudshop/api=ghcr.io/sua-org/cloudshop/api:sha-${{ github.event.workflow_run.head_sha }}
      - uses: peter-evans/create-pull-request@v6
        with:
          token: ${{ secrets.GITOPS_PR_TOKEN }}
          branch: bump/staging-${{ github.event.workflow_run.head_sha }}
          title: "chore(staging): atualiza api para sha-${{ github.event.workflow_run.head_sha }}"
          body: "Promocao automatica apos CI verde na main."

Nota de segurança: O token de acesso ao repositório GitOps deve permitir apenas abrir PR, nunca fazer push direto na main.

Job do CI que atualiza o repositório GitOps

yaml

update-gitops:
  needs: build
  runs-on: ubuntu-latest
  steps:
    - uses: actions/create-github-app-token@v1
      id: app
      with:
        app-id: ${{ vars.GITOPS_APP_ID }}
        private-key: ${{ secrets.GITOPS_APP_KEY }}
        repositories: cloudshop-gitops          # escopo mínimo
    - uses: actions/checkout@v4
      with: { repository: cloudshop/cloudshop-gitops, token: "${{ steps.app.outputs.token }}" }
    - run: |
        cd apps/api/overlays/staging
        kustomize edit set image ghcr.io/cloudshop/api@${{ needs.build.outputs.digest }}
        git config user.name "cloudshop-bot"
        git config user.email "bot@cloudshop.dev"
        git commit -am "chore(staging): api ${{ github.sha }}" && git push

Por que isso importa

Esta é a arquitetura de entrega que as vagas de Platform Engineering descrevem hoje.

Erro comum

Dar push direto na main do repositório GitOps pelo pipeline, eliminando a revisão.

Dica de produção

Registre no PR o link do build, os testes e o digest da imagem: revisão informada em trinta segundos.

Pergunta de entrevista

Descreva o caminho de um commit até produção em uma arquitetura GitOps.

Glossário

Image Updater
Componente que atualiza tags de imagem automaticamente a partir do registry.
promoção automática
Atualização automatizada de manifests após validação em CI.
Digest
Hash sha256 que identifica uma imagem de forma imutável.
Image Updater
Componente do ArgoCD que atualiza tags no Git ao detectar novas imagens.
Admission policy
Regra que aceita ou rejeita recursos ao entrarem no cluster.

Conexão com o CloudShop

Automatizar a promoção do CloudShop para staging após CI verde.

Quiz da aula

  1. 1. Qual prática preserva a rastreabilidade do deploy em GitOps?

  2. 2. Por que referenciar a imagem por digest em vez de 'latest'?

  3. 3. Que credencial o CI precisa ter no fluxo GitOps?

Minhas anotações

Salvo automaticamente neste navegador.

AnteriorPróxima