Většina týmů, které říkají, že dělají GitOps, ve skutečnosti dělají „Git-triggered CI/CD.” Rozdíl je zásadní. GitOps není jen „manifesty v Gitu” — je to architektonický vzor s pull-based reconciliation loop, deklarativním desired state a automatickou detekcí driftu. Tenhle článek vysvětluje, co GitOps skutečně je, jak ho nasadit s ArgoCD nebo Flux, a kde většina implementací tiše selhává.
Co je GitOps — a co není¶
Termín GitOps poprvé použil Alexis Richardson z Weaveworks v roce 2017. Od té doby se z něj stal jeden z nejzneužívanějších buzzwordů v DevOps světě. V roce 2021 vznikla pracovní skupina OpenGitOps pod CNCF, která definovala čtyři principy, bez kterých nelze o GitOps mluvit.
Čtyři principy OpenGitOps (v1.0.0)¶
1
Declarative¶
Celý systém musí být popsán deklarativně. Ne skripty, které něco dělají krok po kroku,
ale manifesty, které říkají „takhle má systém vypadat.” Kubernetes YAML, Terraform HCL,
Helm charts — všechno to jsou deklarativní popisy desired state. Imperativní kubectl run
nebo kubectl scale příkazy jsou přesný opak toho, co GitOps vyžaduje.
2
Versioned and Immutable¶
Desired state žije v Git repozitáři — verzovaném, auditovatelném, immutable storage.
Každá změna je commit. Každý commit má autora, timestamp a diff. Rollback znamená
git revert. Audit trail dostanete zdarma. Žádný jiný systém v software
engineeringu nedává takovou transparentnost tak levně.
3
Pulled Automatically¶
Tohle je bod, kde většina „GitOps” implementací selhává. Skutečný GitOps používá
pull model — agent běžící uvnitř clusteru (ArgoCD, Flux) průběžně
sleduje Git repozitář a stahuje si změny. Push model, kde CI pipeline volá
kubectl apply, není GitOps. Je to CI/CD s manifesty v Gitu. Rozdíl:
v pull modelu cluster sám ví, jak má vypadat. V push modelu závisíte na externím systému,
který mu to řekne.
4
Continuously Reconciled¶
Agent neustále porovnává actual state (co běží v clusteru) s desired state (co je v Gitu). Pokud se liší — protože někdo ručně změnil deployment, protože pod spadl, protože cokoliv — agent automaticky opraví stav tak, aby odpovídal Gitu. Toto se nazývá reconciliation loop a je to srdce GitOps. Drift není tolerován, je opravován.
Proč na tom záleží? Protože push-based CI/CD má fundamentální slabinu: po deployi nevíte,
co se v clusteru děje. Někdo spustí kubectl edit, změní repliky, upraví env var —
a váš Git repozitář o tom neví. Za týden deployujete znovu a ty ruční změny zmizí. Nebo hůř —
nezmizí, protože pipeline deployuje jen změněné soubory. GitOps tento problém eliminuje
tím, že cluster je nepřetržitě synchronizován s Gitem.
ArgoCD vs Flux: Praktické srovnání¶
Dva CNCF graduated projekty, dva přístupy ke stejnému problému. Oba implementují GitOps principy, ale liší se ve filozofii, architektuře a uživatelském zážitku. Výběr mezi nimi není akademický — ovlivní, jak váš tým pracuje každý den.
| Kritérium | ArgoCD | Flux |
|---|---|---|
| UI | Bohaté webové UI s vizualizací resource tree, diff view, sync status | Žádné nativní UI (existují community dashboardy jako Capacitor) |
| Architektura | Centralizovaný server + API, spravuje více clusterů z jednoho místa | Distribuované controllery, každý cluster má vlastní Flux instanci |
| Multi-tenancy | AppProjects s RBAC, SSO integrace (OIDC, LDAP, SAML) | Nativní Kubernetes RBAC, tenant izolace přes namespace a ServiceAccount |
| Helm podpora | Helm charts renderuje a aplikuje jako plain manifesty | Nativní HelmRelease CRD s automatickými upgrady a rollbacky |
| Image automation | Argocd Image Updater (separátní komponenta) | Vestavěný Image Reflector + Image Automation controller |
| Onboarding | Rychlejší díky UI — nový tým vidí stav okamžitě | Strmější learning curve, ale hlubší Kubernetes-native integrace |
| CNCF status | Graduated (prosinec 2022) | Graduated (listopad 2024) |
Kdy ArgoCD¶
ArgoCD volíme, když tým potřebuje vizuální přehled, když do clusteru nasazuje více týmů s různými oprávněními, nebo když klient vyžaduje SSO integraci. UI je killer feature — vidíte resource tree celé aplikace, diff mezi desired a actual state, historii sync operací. Pro platform týmy, které spravují desítky aplikací, je to nenahraditelné.
Kdy Flux¶
Flux volíme pro prostředí, kde je Kubernetes-native přístup prioritou. Flux je sada controllerů — GitRepository, Kustomization, HelmRelease — které jsou plnohodnotné Kubernetes CRD. Spravujete je stejně jako jakýkoliv jiný K8s resource. Pro týmy, které chtějí maximální composability a nemají problém pracovat přes CLI a kubectl, je Flux elegantnější volba. Image automation je v Fluxu výrazně jednodušší — controller sleduje container registry, detekuje nové tagy a automaticky commitne aktualizovanou verzi do Gitu.
Repozitářová strategie: Mono vs Multi¶
Jak strukturovat Git repozitáře pro GitOps je rozhodnutí, které ovlivní workflow na roky. Existují dvě školy a obě mají legitimní argumenty.
Oddělené repozitáře: app repo + config repo¶
Aplikační kód žije v jednom repozitáři, deployment manifesty v druhém. CI pipeline builduje image z app repo, pushne ho do registry a otevře PR v config repo s aktualizovaným image tagem. GitOps agent sleduje config repo.
Výhody: čistá separace concern, jiná oprávnění pro devs (app repo) a ops (config repo), CI pipeline nemá přístup ke clusteru. Nevýhody: dva repozitáře na údržbu, složitější onboarding, PR v config repo může být bottleneck.
`# Typická struktura config repo
config-repo/
├── base/
│ ├── deployment.yaml
│ ├── service.yaml
│ └── kustomization.yaml
├── overlays/
│ ├── staging/
│ │ ├── kustomization.yaml # image: v1.24.0
│ │ └── replicas-patch.yaml
│ └── production/
│ ├── kustomization.yaml # image: v1.23.2
│ └── replicas-patch.yaml
└── README.md`
Monorepo: vše na jednom místě¶
Aplikační kód i deployment manifesty ve stejném repozitáři. Jednodušší workflow — developer mění kód i konfiguraci v jednom PR. Funguje dobře pro menší týmy a mikroslužby, kde každá služba má vlastní repo.
Naše doporučení: Pro většinu enterprise klientů volíme oddělené repozitáře. Separace app a config repo je bezpečnější — CI pipeline nepotřebuje cluster credentials a config repo slouží jako audit log všech deployment změn. Pro startupy a menší týmy je monorepo zcela legitimní volba.
ArgoCD: Produkční setup krok za krokem¶
ArgoCD instalujeme přes Helm chart do dedikovaného argocd namespace.
Default instalace funguje pro demo — pro produkci je třeba několik úprav.
Application CRD¶
Každá aplikace v ArgoCD je Kubernetes custom resource. Definujete odkud (Git repo, path, revision) a kam (cluster, namespace) se má deployovat. Sync policy určuje, jestli se změny aplikují automaticky nebo čekají na manuální schválení.
`apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: payment-service
namespace: argocd
spec:
project: backend-team
source:
repoURL: https://github.com/acme/k8s-config.git
targetRevision: main
path: apps/payment-service/overlays/production
destination:
server: https://kubernetes.default.svc
namespace: payment
syncPolicy:
automated:
prune: true # Smaže resources, které zmizely z Gitu
selfHeal: true # Opraví manuální změny v clusteru
syncOptions:
- CreateNamespace=true
- PruneLast=true
retry:
limit: 3
backoff:
duration: 5s
maxDuration: 3m
factor: 2`
Self-heal a prune: Dvě klíčová nastavení¶
selfHeal: true znamená, že pokud někdo ručně změní resource v clusteru, ArgoCD ho vrátí do stavu definovaného v Gitu. Typicky do 3 minut (default sync interval). To je přesně ten reconciliation loop, který dělá GitOps GitOpsem.
prune: true je odvážnější — pokud z Gitu smažete manifest, ArgoCD smaže odpovídající resource z clusteru. Bez prune by se smazané resources hromadily jako zombie. S prune je Git skutečně single source of truth — co tam není, neexistuje.
AppProject pro multi-tenancy¶
AppProject definuje, co tým smí a nesmí. Který repozitář může použít jako zdroj, do jakých clusterů a namespace smí deployovat, jaké resource typy jsou povoleny. Backend tým nemůže deploynout ClusterRole. Frontend tým nemůže sahat na namespace jiného týmu. Bezpečnost na úrovni GitOps operátora, ne jen na úrovni Kubernetes RBAC.
`apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: backend-team
namespace: argocd
spec:
description: Backend microservices
sourceRepos:
- https://github.com/acme/k8s-config.git
destinations:
- server: https://kubernetes.default.svc
namespace: payment
- server: https://kubernetes.default.svc
namespace: orders
clusterResourceWhitelist: [] # Žádné cluster-scoped resources
namespaceResourceBlacklist:
- group: “”
kind: ResourceQuota # Quotas spravuje platform tým`
Secrets v GitOps: Slon v místnosti¶
Největší praktický problém GitOps: jak dostat secrets do clusteru, když vše má být v Gitu, ale secrets do Gitu nepatří? Existují tři přístupy, každý s jinými trade-offs.
1. Sealed Secrets (Bitnami)¶
Asymetrická kryptografie. Zašifrujete secret veřejným klíčem, uložíte do Gitu jako SealedSecret. Controller v clusteru má privátní klíč a dešifruje ho. Jednoduché, funguje out of the box, ale klíč je vázán na konkrétní cluster — migrace je bolest a rotace klíčů vyžaduje re-encrypt všech secrets.
2. SOPS + Age/KMS¶
Mozilla SOPS šifruje hodnoty přímo v YAML souborech — klíče zůstávají čitelné, hodnoty jsou
šifrované. Dešifrování řeší Flux nativně (Kustomize controller s SOPS dekrypcí) nebo
ArgoCD plugin. Výhoda: secrets jsou diffovatelné (vidíte, že se změnil DB_PASSWORD,
jen nevidíte na co). KMS backend (AWS KMS, GCP KMS, Azure Key Vault) eliminuje problém
se správou klíčů.
`# SOPS-encrypted secret — klíče čitelné, hodnoty šifrované
apiVersion: v1
kind: Secret
metadata:
name: db-credentials
stringData:
username: ENC[AES256_GCM,data:8bR2…truncated,type:str]
password: ENC[AES256_GCM,data:kL9x…truncated,type:str]
sops:
kms:
- arn: arn:aws:kms:eu-central-1:123456:key/abc-def
encrypted_suffix: _encrypted`
3. External Secrets Operator¶
Náš preferovaný přístup pro enterprise. ESO synchronizuje secrets z externích providerů (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) do Kubernetes Secrets. V Gitu máte jen ExternalSecret manifest — referenci na secret, ne secret samotný. Rotace, audit, access control — všechno řeší provider. Git zůstane čistý.
`# ExternalSecret — reference na Vault, ne samotný secret
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: db-credentials
spec:
refreshInterval: 1h
secretStoreRef:
name: vault-backend
kind: ClusterSecretStore
target:
name: db-credentials
data:
- secretKey: username
remoteRef:
key: secret/data/production/db
property: username
- secretKey: password
remoteRef:
key: secret/data/production/db
property: password`
Multi-cluster GitOps¶
Reálné enterprise prostředí nemá jeden cluster. Má development, staging, production — často v různých regionech nebo u různých cloud providerů. GitOps musí tuto realitu reflektovat.
Promotion workflow: staging → production¶
Nejčistší model: staging a production jsou různé directories v config repo (viz Kustomize overlays výše). Nový image tag se nejdřív commitne do staging overlay. Po validaci (smoke testy, canary metriky) se otevře PR, který aktualizuje production overlay. Review, approve, merge — a ArgoCD synchronizuje produkci. Žádný manuální deploy, plný audit trail.
Alternativa pro pokročilé: ArgoCD ApplicationSet s progressive delivery. Jeden ApplicationSet generuje Application pro každý cluster z listu. Combined s Argo Rollouts dostanete canary deployment řízený metrikami — nová verze dostane 5 % trafficu, pokud error rate zůstane pod prahem, postupně se zvyšuje na 100 %. Pokud ne, automatický rollback. Zero human intervention.
Anti-patterny GitOps implementací¶
GitOps vypadá jednoduše na diagramech. V praxi je plný pastí, do kterých týmy padají s předvídatelnou pravidelností.
Push-based „GitOps”¶
CI pipeline, která po buildu volá kubectl apply nebo helm upgrade.
Manifesty jsou v Gitu, ale deploy je push-based — CI potřebuje cluster credentials,
není reconciliation loop, drift nikdo nedetekuje. Tohle je CI/CD s lepším branding, ne GitOps.
Ruční kubectl „jen tentokrát”¶
Hotfix přímo v clusteru, protože „commit a sync trvá moc dlouho.” Pokud máte selfHeal zapnutý, ArgoCD vaši změnu vrátí do 3 minut. Pokud ho nemáte — gratulujeme, máte drift. Řešení: zrychlete deployment pipeline (ArgoCD webhook notifikace dá sync pod 30 sekund) místo obcházení procesu.
Secrets v plaintextu v Gitu¶
„Ale je to privátní repo!” Privátní repo s přístupem 40 lidí není bezpečné. Git historii nelze snadno vymazat. Jednou commitnutý secret v plaintextu je kompromitovaný secret. Použijte SOPS, Sealed Secrets nebo External Secrets Operator — viz sekce výše.
Jeden obří Application pro celý cluster¶
Všechny manifesty v jedné ArgoCD Application. Sync trvá minuty, jeden broken manifest blokuje deploy všeho ostatního, diff view je nečitelný. Granularita: jedna Application per microservice nebo per team. App of Apps pattern pro orchestraci.
Ignorování webhook a polling overhead¶
Default polling interval ArgoCD je 3 minuty. Pro 200 repozitářů to znamená tisíce Git API calls za hodinu — GitHub rate limiting vás zastaví. Řešení: webhook notifikace z Git provideru na ArgoCD API a zvýšení polling intervalu na 10–15 minut jako fallback.
Jak implementujeme GitOps v CORE SYSTEMS¶
GitOps nasazujeme u klientů v regulovaných odvětvích — bankovnictví, pojišťovnictví, veřejná správa — kde auditovatelnost a repeatabilita nejsou nice-to-have, ale regulatorní požadavek. Náš přístup má tři fáze.
Assessment. Zmapujeme stávající CI/CD pipeline, deployment procesy a týmovou strukturu. Identifikujeme, kde vzniká drift, kde chybí audit trail a kde ruční zásahy způsobují incidenty. Výstupem je migration plan s jasným ROI — kolik incidentů GitOps eliminuje, kolik hodin týdně ušetří na deployment koordinaci.
Pilot. Začínáme s jednou nekritickou službou. Nastavíme config repo, ArgoCD/Flux, secrets management a promotion workflow. Tým se učí nový workflow na reálném projektu, ne na workshopu. Po 2–4 týdnech evaluujeme a iterujeme.
Rollout. Postupná migrace dalších služeb. Dokumentace, runbooky, alerting na sync failures. Školení pro vývojáře — GitOps mění způsob práce a bez buy-in týmu skončíte s nástrojem, který nikdo nepoužívá správně. Cíl: za 3 měsíce má celá platforma GitOps workflow a každý deploy je traceable z commitu po running pod.
Závěr: GitOps není nástroj, je to provozní filozofie¶
GitOps není ArgoCD. Není to Flux. Není to „manifesty v Gitu.” Je to provozní model, kde Git je jediný zdroj pravdy o stavu infrastruktury a software agenti tento stav nepřetržitě vynucují. Nástroje jsou vyměnitelné — principy ne.
Reálný přínos GitOps se neprojeví u prvního deploye. Projeví se u prvního incidentu,
kdy potřebujete rollback (jeden git revert). U prvního auditu, kdy ukážete
kompletní historii změn. U prvního dne nového člověka v týmu, který vidí celý deployment
stav v Git logu místo v hlavě kolegy, co je na dovolené.
Pokud váš tým dnes deployuje přes kubectl apply nebo CI pipeline, která
pushuje do clusteru — začněte malým pilotem. Jedna služba, jeden config repo, ArgoCD
s defaultním nastavením. Za týden uvidíte rozdíl. Za měsíc se nebudete chtít vrátit.