DevOpsQuest
0 XP

DEVOPSQUEST

Minha Trilha
Módulo 9 · GitOps com ArgoCD

Organizando o repositório GitOps: ambientes, overlays e App of Apps

Avançado 35 min+25 XPKustomizeArgo CD

Objetivos desta aula

  • Estruturar um repositório GitOps para vários ambientes
  • Usar base + overlays do Kustomize sem duplicar YAML
  • Gerenciar muitas Applications com o padrão App of Apps
  • Definir quem pode mudar o quê no repositório

GitOps começa simples — uma pasta com YAMLs — e vira caos quando aparecem staging, produção e dez microsserviços. Esta aula mostra a estrutura que escala sem duplicar arquivo.

O padrão mais usado é base + overlays do Kustomize: a pasta base/ tem os manifests comuns (Deployment, Service); cada ambiente em overlays/staging e overlays/producao só declara o que muda — réplicas, imagem, domínio, recursos.

Exemplo de diferença entre ambientes: staging com 1 réplica e imagem :latest, produção com 3 réplicas e imagem com tag fixa. Tudo isso em patches pequenos, sem copiar o Deployment inteiro.

O App of Apps resolve outra escala: em vez de criar cada Application na mão, você cria uma Application “mãe” que aponta para uma pasta cheia de definições de Applications filhas. Adicionar um app novo = commitar um arquivo.

Estrutura recomendada: apps/ (uma pasta por aplicação, com base e overlays), clusters/producao/ (as Applications filhas apontando para os overlays certos) e um root-app.yaml apontando para clusters/producao.

Um repositório ou vários? Comece com um só (monorepo de config). Separe quando precisar de permissões diferentes por time ou de históricos independentes.

Controle de mudanças: toda alteração de produção passa por Pull Request com revisão. O Git vira a auditoria completa de quem mudou o quê, quando e por quê.

Dica final: valide os manifests no CI (kustomize build + kubeconform) antes do merge, para que YAML quebrado nunca chegue ao cluster.

Na prática

Estrutura de pastas

text

gitops-repo/
├── apps/
│   └── api/
│       ├── base/
│       │   ├── deployment.yaml
│       │   ├── service.yaml
│       │   └── kustomization.yaml
│       └── overlays/
│           ├── staging/      # 1 réplica, imagem :latest
│           └── producao/     # 3 réplicas, tag fixa, mais recursos
└── clusters/
    └── producao/
        ├── root-app.yaml     # App of Apps
        └── api.yaml          # Application apontando p/ overlay

Overlay de produção (só o que muda)

yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
replicas:
  - name: api
    count: 3
images:
  - name: minha/api
    newTag: 1.4.2

Por que isso importa

Uma estrutura clara de repositório é o que separa GitOps sustentável de uma pilha de YAML copiado e colado.

Erro comum

Copiar a pasta inteira por ambiente: qualquer correção precisa ser lembrada e repetida em todos.

Dica de produção

Proteja a branch main com revisão obrigatória — em GitOps, merge em main é deploy.

Pergunta de entrevista

Como você estrutura um repositório GitOps para staging e produção sem duplicar manifests?

Glossário

Kustomize
Ferramenta que monta YAMLs a partir de base + patches.
Overlay
Conjunto de mudanças de um ambiente sobre a base.
App of Apps
Application que gerencia outras Applications.
Monorepo
Um único repositório para toda a configuração.

Conexão com o CloudShop

O repositório GitOps do CloudShop usa base + overlays: staging e produção compartilham 90% do YAML.

Quiz da aula

  1. 1. Para que serve o overlay do Kustomize?

  2. 2. O que é App of Apps?

  3. 3. Em GitOps, um merge na main equivale a:

Minhas anotações

Salvo automaticamente neste navegador.

AnteriorPróxima