{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"platform/gitops","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/gitops/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/gitops/"},"term":{"en":"GitOps","da":"GitOps"},"aka":{"en":[],"da":[]},"domain":["platform"],"cluster":"delivery","layer":"delivery","status":"current","era":2017,"summary":{"en":"Running systems so that files under version control hold the only true description, and software keeps the live setup matching them.","da":"At drive systemer, så filer under versionsstyring er den eneste gyldige beskrivelse, og software hele tiden retter driften ind efter dem."},"body":{"formal":{"en":"An operating model where the wanted state of a system is written as files under version control, a change is made only by changing those files, and an agent inside the system keeps pulling the files and correcting any difference it finds.","da":"En driftsmodel, hvor et systems ønskede tilstand skrives som filer under versionsstyring, ændringer kun sker ved at ændre filerne, og en agent inde i systemet løbende henter filerne og retter enhver forskel, den finder."},"plain":{"en":"Like a shop where the price list on the wall is the rule; if someone changes a price tag on the shelf, staff put it back to match the wall.","da":"Som en butik, hvor prislisten på væggen er reglen; hvis nogen ændrer et prismærke på hylden, sætter personalet det tilbage, så det passer med væggen."},"inPractice":{"en":"Before flu vaccine booking opens, an engineer in a region's IT department asks for two more copies of the booking service by editing a file; once it is approved, the system starts them on its own within minutes.","da":"Før der åbnes for booking af influenzavaccine, beder en driftsmedarbejder i regionens IT-afdeling om to ekstra kopier af bookingtjenesten ved at rette en fil; når ændringen er godkendt, starter systemet selv kopierne inden for få minutter."},"whyItMatters":{"en":"Every change passes through review and leaves a trail, people need less direct access to live systems, and hand-made changes are undone automatically instead of lingering unseen.","da":"Hver ændring går gennem en gennemgang og efterlader et spor, folk har mindre brug for direkte adgang til driften, og håndlavede ændringer rulles automatisk tilbage i stedet for at ligge ubemærket hen."}},"deepDive":{"en":"The term was coined in 2017 by Alexis Richardson of Weaveworks, whose Flux tool first implemented it for Kubernetes. The CNCF OpenGitOps project later distilled it into four principles (v1.0.0): the system's desired state is expressed declaratively; it is stored in a way that is versioned and immutable, with a complete history; software agents pull the desired state automatically from that source; and those agents continuously reconcile the actual state towards it. Git is the usual store but not strictly required - OCI artefacts in a registry satisfy the same principles and are increasingly used as the transport.\n\nThe reference implementations are Argo CD and Flux, both graduated CNCF projects. An in-cluster controller clones or polls the repository (or receives a webhook), renders the manifests - plain YAML, Kustomize overlays or Helm charts - computes a diff against live objects using server-side apply or three-way merge, and applies the difference. With automated sync and self-heal enabled, a manual kubectl edit is reverted on the next reconciliation; pruning deletes objects that have disappeared from the repository. Ordering is handled with sync waves and hooks (Argo CD) or dependsOn and health checks (Flux). A typical layout separates application source repositories from an environment or \"config\" repository; CI builds and signs an image, then opens a pull request that bumps the image digest in the config repo, and promotion between environments is itself a reviewed merge.\n\nThe pull model is the security argument: CI no longer needs cluster-admin credentials, because only the in-cluster agent writes to the API server, and the audit trail of production changes is the repository's commit and review history. The trade-off is that the repository, and whoever can merge to its protected branches, now effectively controls production. Controls include branch protection with required reviews, verification of signed commits (both Argo CD and Flux can refuse unsigned or untrusted revisions), least-privilege service accounts per application rather than one cluster-admin controller, and restricting which repositories and namespaces each application may target. Secrets cannot be committed in plaintext, so teams use Sealed Secrets or SOPS-encrypted files, or reference external stores through the External Secrets Operator.\n\nGitOps differs from infrastructure as code in scope and mechanism: IaC describes resources declaratively but is often applied in a push model by a pipeline running terraform apply, with drift detected only at the next plan, whereas GitOps adds continuous, agent-driven reconciliation. Failure modes include reconciliation loops fighting other controllers such as autoscalers over the same fields, drift hidden by ignore rules, and outages when the Git host is unavailable - running workloads continue, but nobody can change them through the normal path.","da":"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.\n\nReferenceimplementeringerne 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.\n\nPull-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.\n\nGitOps 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."},"edges":[{"type":"requires","to":"platform/infrastructure-as-code","confidence":"high","strength":"normal"},{"type":"requires","to":"platform/version-control","confidence":"high","strength":"normal"},{"type":"used-with","to":"platform/kubernetes","confidence":"high","strength":"normal"}],"depth":2,"sources":[{"title":"OpenGitOps Principles v1.0.0","url":"https://opengitops.dev/","tier":"reference","publisher":"CNCF OpenGitOps"},{"title":"NIST SP 800-204D - Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines","url":"https://csrc.nist.gov/pubs/sp/800/204/d/final","tier":"standard","publisher":"NIST"}],"draft":true}