Náš workflow: Jenkins buildí image → pushne do registry → operátor spustí helm upgrade → modlí se. GitOps otáčí model: Git repozitář popisuje stav clusteru, Flux zajistí, že cluster odpovídá. Žádný imperativní helm upgrade. Jen git push.
Proč GitOps¶
Problém: nikdo neví, co na clusteru běží. Kubectl apply tu, helm upgrade tam, ruční edit configmapy. Configuration drift. GitOps princip: co je v gitu, to běží. Vždy. Automaticky. Ruční změnu agent vrátí zpět.
Bonusy: audit trail (git log), rollback = git revert, code review pro infra změny (pull request), reproducibilita (nový cluster = git clone).
Flux vs. Argo CD¶
Argo CD: hezčí UI, víc features. Flux: lightweight, composable, lepší integrace s Helm. Pro 12 služeb s Helm charts vyhrál Flux jednoduchostí.
Struktura repozitáře¶
infrastructure/
├── base/ # Shared resources
├── environments/
│ ├── staging/ # Kustomize patches
│ └── production/
└── apps/
├── notification-service/
├── user-service/
└── ...
Workflow v praxi¶
- Vývojář pushne kód → Jenkins buildí image myapp:1.23.5
- Flux detekuje nový tag v registry
- Flux aktualizuje manifest v gitu (image tag)
- Flux aplikuje změnu na cluster
- Rollback? git revert commit → Flux aplikuje předchozí stav
Drift detection¶
Někdo udělá kubectl edit na produkci? Flux to detekuje a vrátí zpět. Zpočátku frustrace pro ops tým zvyklý na quick fixy. Ale eliminuje „kdo co kdy změnil a proč to nefunguje” hádanky.
Multi-environment¶
Staging branch → staging cluster. Main branch → production. Promotion = merge/cherry-pick. Kustomize pro environment-specific patches. Celý flow auditovatelný, review-able, reproducibilní.
Git jako single source of truth¶
GitOps eliminuje configuration drift, dává audit trail zdarma a zjednodušuje rollback. Investice do Flux setupu se vrátí v prvním měsíci, kdy potřebujete zjistit „co se změnilo”.