Isso aconteceu de verdade, no trabalho. Tirei nomes de empresa, contas, domínios, repositórios e qualquer detalhe sensível.
01 / CONTEXTO
O deploy funcionava. O difícil era responder qual versão estava rodando, e desde quando.
Eram vários microsserviços, vários ambientes e vários times. O pipeline fazia o deploy direto no cluster, então precisava de permissão no cluster, e construir a imagem e mexer no ambiente viravam uma coisa só.
Com GitOps, o Git passou a dizer o que deve rodar, e o Argo CD a fazer o cluster ficar igual ao Git. O pipeline só gera a imagem e anota a versão. Quem entrega é o Argo CD, que fica o tempo todo comparando o repositório com o cluster.
PRINCÍPIO DO PROJETOSe não está no Git, não deveria estar rodando.
02 / DESAFIO
Cada ambiente tem um ritmo, mas todos precisavam seguir as mesmas regras.
Desenvolvimento recebe mudança o dia inteiro. Homologação precisa segurar uma release até ela ficar estável. Produção só recebe o que foi aprovado. Eu queria respeitar essas diferenças sem acabar com três jeitos de fazer deploy para manter.
Escala
Muitos serviços no mesmo padrão, sem tirar a autonomia de cada time.
Promoção
A versão testada tinha que subir de ambiente sem ser buildada de novo.
Regras
Cada branch, release, aprovação e correção precisava de um papel claro.
Drift
Mudança feita na mão no cluster não podia virar o novo normal.
03 / MODELO OPERACIONAL
O CI gera a imagem. O Git diz o que rodar. O Argo CD aplica.
Separei o fluxo em partes, cada uma com um dono. O repositório da aplicação tem o código e os testes. O ECR guarda a imagem com a versão. O repositório GitOps diz qual imagem roda em cada ambiente. E o Argo CD coloca isso no cluster.
DESENVOLVIMENTORecebe tudo o que entra e serve para testar integração rápido.
HOMOLOGAÇÃOSegura a release até ela ficar estável e gera as versões candidatas.
PRODUÇÃOSó recebe a versão que já foi testada e aprovada.
04 / DECISÕES TÉCNICAS
As decisões que impediram o GitOps de virar só outro nome para deploy automático.
Imagem imutável e versão rastreável
Cada build gera uma imagem com identificação única. É essa mesma imagem que sobe de ambiente. Se eu buildasse de novo em cada ambiente, poderia ter duas imagens diferentes com o mesmo número de versão.
Branches com papéis explícitos
Cada branch tem um papel: develop para o dia a dia, release para estabilizar e main para produção. Uma correção na release sai da própria release, para não levar junto código que ainda está em desenvolvimento.
development:
source: develop
version: commit_sha
homologation:
source: release/*
version: release_candidate
production:
source: main
version: approved_releaseApplicationSet para consistência em escala
Em vez de escrever uma Application por serviço, usei um molde comum e só mudei o que era específico. Ficou fácil colocar serviço novo, e acabaram as diferenças de configuração que aconteciam por descuido.
- Mesmo padrão de nome para namespace, projeto e repositório.
- Valores próprios por aplicação e por ambiente.
- Um lugar só para ver se tudo está sincronizado e saudável.
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: brown-applications
namespace: argocd
spec:
generators:
- list:
elements:
- app: lab-test
namespace: brown
- app: brown-test
namespace: brown
template:
metadata:
name: "{{app}}-production"
spec:
project: brown
source:
repoURL: https://github.com/brown-cloud/gitops-lab.git
targetRevision: main
path: "apps/{{app}}/overlays/production"
destination:
server: https://kubernetes.default.svc
namespace: "{{namespace}}"
syncPolicy:
automated:
prune: true
selfHeal: truePipeline sem acesso administrativo ao cluster
O CI só faz um commit dizendo qual imagem deve rodar. Ele não precisa rodarkubectl apply nem ter permissão de administrador no cluster. Quem aplica é o Argo CD, que já está dentro do cluster e só mexe onde foi autorizado.
05 / OPERAÇÃO
GitOps só funciona se o time entende o que o Argo CD está mostrando.
- 01
Padronização
Combinei com os times o padrão de repositório, branches, versões, manifests e aplicações.
- 02
Ambiente piloto
Rodei o ciclo inteiro em desenvolvimento antes de levar para os outros ambientes.
- 03
Homologação
Coloquei o fluxo de versões candidatas e de correção durante a estabilização.
- 04
Produção
A imagem aprovada sobe para produção, com histórico de quem aprovou o quê.
- 05
Sustentação
Acompanho com os times sync, health, drift e erro de configuração.
06 / RESULTADOS
O deploy deixou de ser um comando e virou um estado que dá para explicar.
Não tenho números que possa publicar, então vou contar o que mudou no dia a dia.
Dá para seguir o caminho inteiro do commit até a imagem e a versão que está rodando.
Ambientes parecidos de verdade porque todos saem do mesmo molde, versionado no Git.
Produção recebe o que foi testado a mesma imagem que passou na homologação.
Menos coisa feita na mão o Argo CD corrige sozinho o que sai do padrão.
Tudo visível sincronização, saúde, diferenças e histórico de cada aplicação.
07 / APRENDIZADOS
GitOps é um jeito de trabalhar, não só uma ferramenta.
Instalar o Argo CD não resolve nada sozinho. Antes é preciso combinar quem pode mudar o que roda, como uma versão sobe de ambiente, o que precisa de aprovação e o que o time faz quando aparece drift ou falha de sincronização.
A diferença apareceu quando dev e operação começaram a conversar pelo Git. Toda mudança passou a ter revisão e histórico, e o cluster sempre volta para uma configuração que todo mundo conhece.
william@devops:~$ echo $LESSON_LEARNED
"Com GitOps, todo deploy é um commit: alguém revisou, fica no histórico e o cluster segue o que está ali."