Hur fungerar GitOps?

GitOps fungerar genom att deklarativ konfiguration för infrastruktur och applikationer lagras i ett Git-repo som enda sanningskälla. En controller i klustret jämför kontinuerligt repots innehåll med faktisk drift och reconcilerar avvikelser automatiskt. Alla ändringar sker via pull request, vilket gör driften granskbar, reproducerbar och enkel att rulla tillbaka.

Definition

GitOps är en operativ modell som bygger på fyra principer: deklarativ konfiguration, versionshanterad sanning, automatiserad leverans och kontinuerlig reconciliation. Modellen formaliserades av Weaveworks 2017 och underhålls i dag av OpenGitOps-arbetsgruppen i CNCF. Den passar särskilt väl för Kubernetes men kan tillämpas på alla system som har en deklarativ API.

Skillnaden mot klassisk CI/CD är att utrullning inte längre push:as från pipelinen in i klustret. I stället pull:ar en controller, exempelvis Argo CD eller Flux, det önskade tillståndet från Git och tillämpar det. Det ger en tydlig separation mellan att bygga artefakter och att driftsätta dem.

Komponenter och flöde

Ett typiskt flöde ser ut så här: utvecklare öppnar en pull request mot manifest-repot, CI validerar manifesten, en granskare godkänner och mergar. Inom sekunder upptäcker controllern ändringen, jämför mot klustertillståndet och tillämpar diffen. Hela händelsen är loggad i Git-historiken och i controllerns events.

Fördelar och begränsningar

Fördelar inkluderar fullständig spårbarhet av vem som gjort vad och när, enkel rollback genom att backa en commit, samma flöde för infrastruktur och applikationer, samt minskad behörighetsspridning eftersom controllern är det enda som skriver till klustret. Det förenklar också compliance-rapportering, då varje ändring har en granskningsbar trail i Git.

Begränsningar finns. När antalet kluster och miljöer ökar tenderar antalet repon att växa snabbt, vilket kräver en genomtänkt repo-strategi. Hemlighetshantering blir mer komplex, eftersom rena Kubernetes-secrets inte ska ligga i klartext i Git. Lösningar som SOPS, Sealed Secrets eller externa vault-integrationer behövs. Reconciliation utan tydliga policyer kan dessutom orsaka oavsiktliga ändringar i miljöer som manuellt patchats.

Bästa praxis

Separera applikationskod från manifest-repot. Det gör det möjligt att uppdatera enbart driftsättningskonfiguration utan att trigga onödiga byggen. Använd miljöer som överlag, inte som branches, eftersom branches lätt driver ifrån varandra över tid.

Inför policy-as-code med Gatekeeper eller Kyverno så att inga manifest kommer in i klustret som bryter mot organisationens regler, exempelvis att containers inte får köras som root eller att image-taggar inte får vara latest. Skydda manifest-repot med branch protection, signerade commits och obligatoriska granskningar för att förhindra obehöriga ändringar.

Mät reconciliation-latens och drift-detektering. Om controllern tar lång tid på sig att upptäcka avvikelser eller om manuella ändringar i klustret skrivs över oväntat, behöver ni se över både repo-struktur och larm.

Så hjälper Opsio

Opsio bygger GitOps-plattformar baserade på Argo CD eller Flux, integrerade med er befintliga CI och er identitetsleverantör. Vi hjälper er välja repo-strategi, hantera hemligheter säkert och rulla ut policy-as-code. Läs mer om våra DevOps-tjänster, hanterad molndrift, eller kontakta oss för en GitOps-workshop.

Vanliga frågor

Måste vi använda Kubernetes för GitOps?

Nej, men modellen passar bäst för system med deklarativ API. Det finns GitOps-implementationer för Terraform, Crossplane och även för moln-resurser via Atlantis. Värdet är dock störst i Kubernetes-miljöer där reconciliation-mönstret redan är inbyggt.

Hur skiljer sig pull-baserad GitOps från traditionell push-baserad CD?

I push-modellen har CI-pipelinen autentiseringsuppgifter till klustret och skickar manifest dit. I pull-modellen har klustret en controller som hämtar från Git, och CI behöver aldrig direkt klusteråtkomst. Det minskar attackytan och gör det enklare att hantera flera kluster.

Hur hanterar vi hemligheter i Git?

Använd verktyg som SOPS med åldersbaserad eller KMS-baserad kryptering, Sealed Secrets från Bitnami, eller en extern vault som hämtas vid reconciliation via External Secrets Operator. Klartextsecrets ska aldrig committas, även till privata repon.

Fungerar GitOps med flera moln?

Ja. Argo CD och Flux kan hantera kluster i AWS, Azure, GCP och on-prem från en central instans, eller från flera instanser per region. Repo-strukturen behöver dock planeras så att miljöskillnader hanteras via overlays och inte via duplicerade manifest.

Vad är skillnaden mellan Argo CD och Flux?

Båda är CNCF-graduerade och uppfyller OpenGitOps-principerna. Argo CD har ett rikt UI och starkt stöd för multi-cluster och progressive delivery via Argo Rollouts. Flux är mer modulärt, lättare att integrera i automatiserade flöden och har starkt stöd för Helm och Kustomize. Valet beror på teamets preferens och befintlig verktygskedja.