DevOpsQuest
0 XP
Módulo 9 · GitOps com ArgoCD

Princípios de GitOps e estrutura do repositório

Intermediário 35 min+25 XPGitKustomize/Helm

Objetivos desta aula

  • Entender os princípios de GitOps
  • Estruturar repositório por ambiente
  • Separar aplicação de manifests

GitOps se apoia em quatro princípios: estado desejado declarativo, versionado e imutável em Git, aplicado automaticamente por agentes, com reconciliação contínua. A consequência prática é enorme: quem pode fazer merge pode implantar, e o histórico do Git é o histórico do que rodou em produção.

Separe o repositório da aplicação do repositório de manifests. A aplicação gera imagem versionada; o repositório GitOps registra qual versão deve rodar em cada ambiente. Isso permite políticas de revisão diferentes e evita que uma mudança de código altere produção sem passo explícito.

Estruture por ambiente com base comum e overlays: base/ com o essencial, overlays/dev e overlays/prod com réplicas, recursos e host. Kustomize é ideal para isso; Helm com values por ambiente também funciona e o ArgoCD suporta ambos.

1. Os quatro princípios

  1. Declarativo: o sistema é descrito como dados
  2. Versionado e imutável: o Git guarda cada estado
  3. Puxado automaticamente: um agente no cluster busca as mudanças
  4. Reconciliado continuamente: diferenças são detectadas e corrigidas

2. Push vs pull

No modelo push, o pipeline tem credencial de admin do cluster — alvo valioso para ataques. No pull, só o agente dentro do cluster aplica mudanças; o CI apenas escreve no Git.

3. Repositório de app vs de configuração

O código fica em cloudshop-app; o estado desejado dos ambientes em cloudshop-gitops. Separar evita loops de CI e dá permissões diferentes: muitos podem mexer no código, poucos aprovam produção.

4. Estrutura típica

Pastas apps/ (cada serviço com base e overlays por ambiente), clusters/ (o que cada cluster instala) e platform/ (ingress, cert-manager, monitoramento). Prefira pastas por ambiente a branches por ambiente — merges entre branches geram divergência escondida.

5. O Git vira trilha de auditoria

Quem mudou, quando, por quê e quem aprovou: tudo está no histórico e nos pull requests. Rollback é um git revert.

Na prática

Estrutura do cloudshop-gitops

text

cloudshop-gitops/
  base/
    kustomization.yaml
    deployment-api.yaml
    service-api.yaml
    ingress.yaml
  overlays/
    staging/
      kustomization.yaml      # replicas: 1, host: staging.cloudshop.dev
      image-tag.yaml
    producao/
      kustomization.yaml      # replicas: 3, recursos maiores
      image-tag.yaml
  apps/
    staging.yaml              # Application do ArgoCD
    producao.yaml

Overlay de produção com Kustomize

yaml

# overlays/producao/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: cloudshop
resources: [../../base]
replicas:
  - name: cloudshop-api
    count: 3
images:
  - name: ghcr.io/sua-org/cloudshop/api
    newTag: v1.2.0
patches:
  - target: { kind: Deployment, name: cloudshop-api }
    patch: |
      - op: replace
        path: /spec/template/spec/containers/0/resources/limits/memory
        value: 512Mi

Nota de segurança: Nada de senha nesses arquivos: o repositório é lido por várias pessoas e pelo agente do cluster.

Estrutura do repositório cloudshop-gitops

text

cloudshop-gitops/
├── apps/
│   └── api/
│       ├── base/                 # Deployment, Service, HPA comuns
│       └── overlays/
│           ├── staging/          # 2 réplicas, domínio de staging
│           └── prod/             # 6 réplicas, recursos maiores
├── platform/
│   ├── ingress-nginx/
│   └── cert-manager/
└── clusters/
    ├── staging/apps.yaml         # App of Apps do staging
    └── prod/apps.yaml

Por que isso importa

GitOps é o padrão dominante para entrega em Kubernetes e aparece cada vez mais nas descrições de vaga.

Erro comum

Misturar código e manifests no mesmo repositório e perder controle sobre o que vai a produção.

Dica de produção

Proteja o repositório GitOps com revisão obrigatória: ele é o botão de deploy da empresa.

Alerta de segurança

Quem tem escrita no repositório GitOps tem, na prática, acesso de deploy ao cluster.

Pergunta de entrevista

Por que separar repositório de aplicação e de manifests?

Glossário

overlay
Camada Kustomize que ajusta a base para um ambiente específico.
estado desejado
Descrição declarativa do que deve existir, versionada em Git.
GitOps
Operar sistemas tendo o Git como fonte da verdade, com reconciliação automática.
Modelo pull
Agente no cluster busca e aplica as mudanças, sem credencial externa de admin.
Overlay
Camada de ajustes por ambiente sobre uma base comum.

Conexão com o CloudShop

Criar a estrutura base/overlays do cloudshop-gitops.

Quiz da aula

  1. 1. Em GitOps, como se faz um deploy?

  2. 2. Qual a principal vantagem de segurança do GitOps pull?

  3. 3. Como se faz rollback em GitOps?

Minhas anotações

Salvo automaticamente neste navegador.

AnteriorPróxima