GitOps

Begrebet blev skabt i 2017 af Alexis Richardson fra Weaveworks, hvis værktøj Flux først implementerede det til Kubernetes. CNCF-projektet OpenGitOps har siden kogt det ned til fire principper (v1.0.0): systemets ønskede tilstand udtrykkes deklarativt; den gemmes versioneret og uforanderligt med en komplet historik; softwareagenter trækker automatisk den ønskede tilstand fra denne kilde; og agenterne afstemmer løbende den faktiske tilstand mod den. Git er det sædvanlige lager, men ikke et krav - OCI-artefakter i et registry opfylder de samme principper og bruges i stigende grad som transport.

Referenceimplementeringerne er Argo CD og Flux, begge graduerede CNCF-projekter. En controller i klyngen kloner eller poller repositoryet (eller modtager en webhook), renderer manifesterne - ren YAML, Kustomize-overlays eller Helm-charts - beregner forskellen til de levende objekter med server-side apply eller three-way merge og anvender forskellen. Med automatisk synkronisering og self-heal slået til rulles en manuel kubectl edit tilbage ved næste afstemning; pruning sletter objekter, der er forsvundet fra repositoryet. Rækkefølge håndteres med sync waves og hooks (Argo CD) eller dependsOn og helbredstjek (Flux). En typisk opbygning adskiller applikationernes kilde-repositories fra et miljø- eller "config"-repository; CI bygger og signerer et image og opretter derefter en pull request, der opdaterer image-digesten i config-repoet, og promovering mellem miljøer er i sig selv en gennemgået fletning.

Pull-modellen er sikkerhedsargumentet: CI behøver ikke længere cluster-admin-legitimationsoplysninger, fordi kun agenten i klyngen skriver til API-serveren, og revisionssporet for ændringer i produktion er repositoryets historik over commits og gennemgange. Bagsiden er, at repositoryet - og den, der kan flette til dets beskyttede grene - nu reelt styrer produktionen. Kontrollerne omfatter grenbeskyttelse med krævede gennemgange, verifikation af signerede commits (både Argo CD og Flux kan afvise usignerede eller ikke-betroede revisioner), service accounts med mindste privilegium per applikation frem for én controller med cluster-admin og begrænsning af, hvilke repositories og namespaces hver applikation må ramme. Hemmeligheder kan ikke committes i klartekst, så teams bruger Sealed Secrets eller SOPS-krypterede filer eller henviser til eksterne lagre via External Secrets Operator.

GitOps adskiller sig fra infrastructure as code i omfang og mekanisme: IaC beskriver ressourcer deklarativt, men anvendes ofte i en push-model af en pipeline, der kører terraform apply, så afvigelser først opdages ved næste plan, mens GitOps tilføjer løbende afstemning drevet af en agent. Typiske fejl er afstemningsløkker, der kæmper med andre controllere som autoskalerere om de samme felter, afvigelser skjult af ignore-regler og nedbrud, når Git-værten er utilgængelig - kørende workloads fortsætter, men ingen kan ændre dem ad den normale vej.