Forbindelsen mellem GitOps og Kubernetes

Dette blogindlæg omhandler et begreb, der er noget af det nyeste indenfor både udvikling og drift af applikationer: GitOps. Indlægget gør dig klogere på, hvad GitOps er, hvilke muligheder det rummer, samt hvordan det kan alignes med Kubernetes.

Hvad er GitOps?

GitOps er en proces, der gør brug af Git til drift og håndtering af cloud native applikationer. Når man arbejder efter gitOps-principperne, er Git at betragte som "single source of truth" i forhold til systemets tilstand. Det leder naturligt videre til spørgsmålet: Hvad er så systemet? Med gitOps er det faktisk muligt at bruge Git til provisionering af hele applikationens infrastruktur, og altså ikke kun til applikationen selv. Dvs. at man med såkaldt deklarativ infrastruktur - eller "infrastructure as code" kan anvende Git som single source of truth til hele applikationsmiljøet.

GitOps og CI/CD: Hvad er forbindelsen?

GitOps og CI/CD (continuous integration/continuous delivery eller deployment) hører sammen. En lille opfrisker: CI/CD gør det muligt for udviklere løbende at udvikle og deploye applikationer. Ofte sker dette via et Git repository (dog kan der være andre repositories). I løbet af deployment-/leveringsfasen ”skubbes” den containerbaserede applikation til Kubernetes til deployment. Driften af GitOps styrker CI/CD-modellen ved at anvende en controller i Kubernetes til at holde øje med det ønskede state (Git) og sammenholde dette med det faktiske state (Kubernetes). Hvis der er forskel på de to, anvendes en pull-metode til at bringe Kubernetes-clusteret til den ønskede tilstand.

Men hvad sker der, hvis nogen ændrer noget, der kører i Kubernetes clusteret? Vores mål er jo at anvende Git som den primære source of truth i form af et deklarativt deployment værktøj og gøre brug af øvrige værktøjer til at underrette os i tilfælde af uoverensstemmelser. Ved at bruge værktøjer, der kan identificere forskelle mellem den løbende og den erklærede tilstand, korrigerer Kubernetes til den erklærede driftstilstand.

Note: Løbende integrering og deployment er komplimentære, men også separate processer.  Da CI og CD-processer sker i forskellige grupper, kan processen variere fra virksomhed til virksomhed.

Screenshot 2020-03-11 at 11.09.41

Hvorfor GitOps?

Først og fremmest er GitOps vejen frem for de organisationer, der ønsker automatisering af hele applikationsmiljøet, fra netværk over virtuelle miljøer til selve applikationen. Afhængigt af, hvordan jeres virksomheds CI/CD pipeline ser ud, kan store dele af den stadigt være "håndholdt". Med GitOps er det muligt at automatisere både integration og deployment samtidigt med at der opnås fuld kontrol over versionering.

Desuden får man med Git en god audit-log med i købet, hvilket giver store fordele i forhold til revision og debugging.

 

Mere inspiration

 
Selve begrebet GitOps er opfundet af Alexis Richardson fra Weavework for et par år siden. Hans pointe var at alt der kræves for at genskabe et setup inklusive infrastrukture, platform og applikationer skal være i git, deraf terminologien gitOps. 
 
Netics samarbejdspartnere fra Rancher Labs har skrevet et blogindlæg om GitOps, hvor de går lidt mere i dybden med værktøjet Flux, der er værktøjet du kan anvende i Kubernetes, for at enable GitOps. Flux er open source, og administreres i regi af CNCF.
 
https://rancher.com/blog/2020/gitops-kubernetes-connection
 
Værktøjet Flux kan findes på Github her: https://github.com/fluxcd/flux
 
Kontakt gerne Netic, hvis du vil vide mere om GitOps, og hvordan din virksomhed kan anvende gitOps til automatisering af jeres CI/CD pipeline.
 
 
Del indhold