🥇Hva er egentlig GitOps?

Obs. overs.: Etter den nylige publikasjonen av materialet om pull- og push-metodene i GitOps, har vi sett interesse for denne modellen som helhet, men det er svært få publikasjoner om dette på russisk (de finnes rett og slett ikke på Habr). Derfor er vi glade for å tilby dere oversettelsen av en annen artikkel – selv om den er nesten ett år gammel! – fra selskapet Weaveworks, som er kjent for å ha funnet opp termen «GitOps». I teksten forklares kjernen i tilnærmingen og de viktigste forskjellene fra allerede eksisterende.

For ett år siden publiserte vi en introduksjon til GitOps. Den gang fortalte vi hvordan Weaveworks-teamet lanserte en SaaS fullstendig basert på Kubernetes, og utviklet et sett med foreskrivende beste praksiser for distribusjon, styring og overvåking i et cloud native-miljø.

Artikkelen viste seg å være populær. Andre begynte å snakke om GitOps og publiserte nye verktøy for git push, utvikling, av hemmeligheter, funksjoner, kontinuerlig integrasjon osv. På nettstedet vårt dukket det opp et stort antall publikasjoner og bruksområder for GitOps. Men noen mennesker hadde fortsatt spørsmål. Hva skiller modellen fra tradisjonell infrastructure as code og kontinuerlig levering (continuous delivery)? Er det nødvendig å bruke Kubernetes?

Snart innså vi at et nytt beskrivende dokument var nødvendig, som tilbød:

Et stort antall eksempler og historier;
En konkret definisjon av GitOps;
Sammenligning med tradisjonell kontinuerlig levering.

I denne artikkelen har vi prøvd å dekke alle disse temaene. Du vil finne en oppdatert introduksjon til GitOps og et perspektiv på det fra utviklerne og CI/CD. Vi fokuserer hovedsakelig på Kubernetes, selv om modellen kan generaliseres.

Møt: GitOps

Tenk deg Alice. Hun driver selskapet Family Insurance, som tilbyr helse-, bil-, eiendom- og reiseforsikring til folk som er for opptatt til å håndtere detaljene i kontraktene selv. Forretningen hennes begynte som et sideprosjekt da Alice jobbet i banken som data scientist. En dag innså hun at hun kunne bruke avanserte datamaskinalgoritmer for mer effektiv datanalyse og tilpasning av forsikringspakker. Investorer finansierte prosjektet, og nå genererer selskapet hennes over 20 millioner dollar årlig og vokser raskt. Per nå arbeider 180 personer i ulike stillinger i selskapet. Blant dem er det et teknologiteam som driver utviklingen, vedlikeholdet av nettstedet, databasen, og analyserer kundegrunnlaget. Teamet på 60 personer ledes av Bob – selskapets tekniske direktør.

Bobs team distribuerer produksjonssystemer i skyen. Deres hovedapplikasjoner kjører på GKE, og drar nytte av Kubernetes i Google Cloud. I tillegg benytter de seg av ulike verktøy for databehandling og analyse.

Family Insurance hadde ikke planer om å bruke containere, men ble smittet av entusiasmen rundt Docker. Snart oppdaget selskapets spesialister at GKE gjør det enkelt og uanstrengt å distribuere klynger for testing av nye funksjoner. Jenkins ble lagt til for CI og Quay for organisering av containerregister, og det ble skrevet skript for Jenkins som push'let nye containere og konfigurasjoner til GKE.

Det har gått en stund. Alice og Bob ble skuffet over ytelsen til den valgte tilnærmingen og dens innvirkning på virksomheten. Implementeringen av containere økte ikke ytelsen så mye som teamet hadde håpet. Noen ganger krasjet deployeringene, og det var uklart om endringer i koden var årsaken. Det viste seg også å være vanskelig å spore endringer i konfigurasjonene. Ofte måtte de opprette en ny klynge og flytte applikasjonene dit, siden det var enklest å rydde opp i rotet systemet hadde blitt. Alice fryktet at situasjonen ville bli verre ettersom applikasjonen utviklet seg (dessuten var det et nytt prosjekt om maskinlæring på gang). Bob hadde automatisert mesteparten av arbeidet og forsto ikke hvorfor pipeline fortsatt var ustabil, hadde dårlig skalerbarhet og av og til krevde manuell inngripen.

Så lærte de om GitOps. Denne løsningen viste seg å være akkurat det de trengte for å bevege seg trygt fremover.

Alice og Bob hadde hørt om Git-baserte arbeidsprosesser, DevOps og infrastruktur som kode i flere år. Det unike med GitOps er at det bringer inn en rekke beste praksiser - kategoriske og normative - for implementering av disse ideene i konteksten av Kubernetes. Dette temaet har blitt tatt opp flere ganger, inkludert i Weaveworks bloggen.

Family Insurance bestemmer seg for å implementere GitOps. Nå har selskapet en automatisert driftsmodell som er kompatibel med Kubernetes og kombinerer hastighet med stabilitet, ettersom de:

har oppdaget at teamets produktivitet har doblet seg, og ingen går fra vettet;
har sluttet å vedlikeholde skriptene. I stedet kan de nå fokusere på nye funksjoner og forbedre ingeniørmetodene - for eksempel implementere kanarifugler og forbedre testing;
har forbedret distribusjonsprosessen - nå krasjer den sjelden;
har fått muligheten til å gjenopprette deployeringer etter delvise feil uten manuell inngripen;
har fåttomstørre tillit til leveringssystemene. Alice og Bob oppdaget at de kunne dele teamet opp i grupper som jobbet med mikrotjenester parallelt;
kan nå gjøre 30-50 endringer i prosjektet hver dag takket være innsatsen fra hver gruppe og prøve ut nye teknikker;
enkelt å tiltrekke seg nye utviklere til prosjektet, som har muligheten til å rulle ut oppdateringer til produksjon via pull-forespørsel allerede etter noen timer;
lett å bestå revisjon i henhold til SOC2 (for å oppfylle kravene til tjenesteleverandører for sikker datastyring; les mer for eksempel her – obs. overs.).

Hva skjedde?

GitOps - dette er to ting:

En driftsmodell for Kubernetes og cloud native. Den gir et sett med beste praksiser for distribusjon, styring og overvåking av containere og applikasjoner. En elegant definisjon i form av ett lysbilde fra Luis Faceira:
Veien til å skape et utviklerorientert miljø for applikasjonsstyring. Vi bruker arbeidsflyten Git både til drift og utvikling. Merk at dette ikke bare handler om Git push, men om organisering av hele settet med CI/CD og UI/UX-verktøy.

Noen ord om Git

Hvis du ikke er kjent med versjonskontrollsystemer og Git-basert arbeidsflyt, anbefaler vi på det sterkeste å sette deg inn i dem. I starten kan det virke som svart magi med grener og pull-forespørsel, men fordelene er verdt innsatsen. Her god artikkel er for å begynne.

Hvordan fungerer Kubernetes

I vår historie henvendte Alice og Bob seg til GitOps, etter å ha jobbet en stund med Kubernetes. Faktisk er GitOps nært knyttet til Kubernetes - det er en driftsmodell for infrastruktur og applikasjoner basert på Kubernetes.

Hva gir Kubernetes brukerne?

Her er noen av de viktigste funksjonene:

I Kubernetes-modellen kan alt beskrives i deklarativ form.
Kubernetes API-server aksepterer slike erklæringer som innspill og prøver deretter kontinuerlig å bringe klyngen i den tilstanden som er beskrevet i erklæringen.
Erklæringene er tilstrekkelige for å beskrive og håndtere et bredt spekter av arbeidsbelastninger - "applikasjoner".
Som et resultat skjer endringer i applikasjonen og klyngen på grunn av:
- endringer i containerbilder;
- endringer i den deklarative spesifikasjonen;
- feil i miljøet - for eksempel containerkrasj.

Kubernetes sin fantastiske evne til konvergens

Når en administrator gjør endringer i konfigurasjonen, vil Kubernetes-orkestratoren anvende dem på klyngen inntil tilstanden nærmer seg den nye konfigurasjonenDenne modellen fungerer for enhver Kubernetes-ressurs og kan utvides med Custom Resource Definitions (CRDs). Derfor har Kubernetes-deployments følgende fantastiske egenskaper:

Automatisering: Kubernetes-oppdateringer gir en mekanisme for å automatisere prosessen med å implementere endringer på en korrekt og tidsriktig måte.
Konvergens: Kubernetes vil fortsette å forsøke oppdateringer til det lykkes.
Idempotens: Gjentatte anvendelser av konvergens gir det samme resultatet.
Determinisme: Når ressursene er tilstrekkelige, avhenger tilstanden til den oppdaterte klyngen kun av den ønskede tilstanden.

Hvordan GitOps fungerer

Vi har lært nok om Kubernetes til å forklare prinsippene bak GitOps.

La oss se tilbake på Family Insurance-teamene og hva de vanligvis jobber med. Se listen nedenfor (hvis noen punkter virker merkelige eller ukjente, vennligst vent med kritikk og bli med oss). Dette er bare eksempler på arbeidsflyter basert på Jenkins. Det finnes mange andre prosesser som involverer forskjellige verktøy.

Hovedpoenget er at vi ser at hver oppdatering ender med endringer i konfigurasjonsfiler og Git-repositories. Disse endringene i Git får "GitOps-operatøren" til å oppdatere klyngen:

1. Arbeidsflyt: "Jenkins-bygge – master-grenen».
Oppgaveliste:

Jenkins sender taggede bilder til Quay;
Jenkins sender konfigurasjon og Helm-diagrammer til master-lagringsbu
En skyfunksjon kopierer konfigurasjonen og diagrammene fra master-lagringsbøtta til Git-repositoriet master;
GitOps-operatøren oppdaterer klyngen.

2. Jenkins-bygge – release- eller hotfix-grenen:

Jenkins sender u-taggede bilder til Quay;
Jenkins sender konfigurasjon og Helm-diagrammer til staging-lagringsbøtta;
En skyfunksjon kopierer konfigurasjonen og diagrammene fra staging-lagringsbøtta til Git-repositoriet staging;
GitOps-operatøren oppdaterer klyngen.

3. Jenkins-bygge – develop- eller feature-grenen:

Jenkins sender u-taggede bilder til Quay;
Jenkins sender konfigurasjon og Helm-diagrammer til develop-lagringsbøtta;
En skyfunksjon kopierer konfigurasjonen og diagrammene fra develop-lagringsbøtta til Git-repositoriet develop;
GitOps-operatøren oppdaterer klyngen.

4. Legg til ny klient:

Manager eller administrator (LCM/ops) kaller Gradle for den første distribusjonen og konfigurerer nettverkslastbalanserere (NLB);
LCM/ops committer ny konfigurasjon for å forberede distribusjonen for oppdateringer;
GitOps-operatøren oppdaterer klyngen.

Kort beskrivelse av GitOps

Beskriv ønsket tilstand for hele systemet ved hjelp av deklarative spesifikasjoner for hvert miljø (i vår historie definerer Bobs team hele systemkonfigurasjonen i Git).
- Git-repositoriet er den eneste sannhetskilden for ønsket tilstand for hele systemet.
- Alle endringer til ønsket tilstand gjøres ved å commite til Git.
- Alle ønskede parametere for klyngen er også observerbare i selve klyngen. Dermed kan vi avgjøre om de ønskede og observerte tilstandene er like (konvergerer, converge) eller forskjellige (divergerer, diverge) tilstandene.
Hvis den ønskede og observerte tilstanden er forskjellige, så:
- Det finnes en konvergensmekanisme som tidlig eller sent automatisk synchroniserer den målrettede og observerte tilstanden. Inne i klyngen håndteres dette av Kubernetes.
- Prosessen startes umiddelbart med varslingen "change committed".
- Etter en viss konfigurerbar tidsperiode kan det sendes et varsel "diff" dersom tilstandene er forskjellige.
Dermed medfører alle commits i Git verifiserbare og idempotente oppdateringer i klyngen.
- Rull tilbake — det er en konvergens til en tidligere ønsket tilstand.
Konvergensen er endelig. Dens oppnåelse bekreftes av:
- Ingen varsler "diff" i løpet av en viss tidsperiode.
- Varsel "converged" (for eksempel webhook, Git writeback-hendelse).

Hva er divergens?

La oss gjenta det: alle ønskede egenskaper ved klyngen må være observerbare i selve klyngen..

Noen eksempler på divergens:

Endring i konfigurasjonsfilen på grunn av sammenslåing av grener i Git.
Endring i konfigurasjonsfilen på grunn av et commit i Git utført av en GUI-klient.
Flere endringer i ønsket tilstand på grunn av PR i Git etterfulgt av bygging av containerbilde og endringer i konfigurasjonen.
Endring av klyngets tilstand på grunn av feil, ressurskonflikter som fører til "dårlig oppførsel", eller bare tilfeldig avvik fra originaltilstanden.

Hva er en konvergensmekanisme?

Noen eksempler:

For containere og klynger gir konvergensmekanismen Kubernetes.
Den samme mekanismen kan brukes til å administrere applikasjoner og konstruksjoner basert på Kubernetes (for eksempel Istio og Kubeflow).
En mekanisme for å styre arbeidsinteraksjonen mellom Kubernetes, bilderepositorier og Git gir GitOps-operatøren Weave Flux, som er en del av Weave Cloud.
For grunnleggende maskiner må konvergensmekanismen være deklarativ og autonom. Etter vår erfaring kan vi si at Terraform er nærmest denne definisjonen, men krever likevel menneskelig kontroll. I denne forstand utvider GitOps tradisjonene til Infrastructure as Code.

GitOps kombinerer Git med den utmerkede konvergensmekanismen til Kubernetes, og tilbyr en modell for drift.

GitOps lar oss hevde: bare de systemene som kan beskrives og overvåkes, kan automatiseres og kontrolleres.

GitOps er ment for hele cloud native-stakken (for eksempel Terraform osv.)

GitOps er ikke bare Kubernetes. Vi ønsker at hele systemet skal styres deklarativt og bruke konvergens. Med hele systemet mener vi et sett med miljøer som jobber med Kubernetes — for eksempel «dev cluster 1», «produksjon» osv. Hvert miljø inkluderer maskiner, klynger, applikasjoner, samt grensesnitt for eksterne tjenester som tilbyr data, overvåking osv.

Legg merke til hvor viktig Terraform er for bootstrapping-problemet i dette tilfellet. Kubernetes må være utplassert et sted, og bruk av Terraform betyr at vi kan bruke de samme GitOps-arbeidsflytene for å opprette det styrende laget som ligger til grunn for Kubernetes og applikasjonene. Dette er en nyttig beste praksis.

Det legges stor vekt på å anvende GitOps-konsepter på lag over Kubernetes. Det finnes nå GitOps-løsninger for Istio, Helm, Ksonnet, OpenFaaS og Kubeflow, samt for eksempel Pulumi, som skaper et lag for utvikling av applikasjoner for cloud native.

Kubernetes CI/CD: sammenligning av GitOps med andre tilnærminger

Som nevnt er GitOps to ting:

En driftsmodell for Kubernetes og cloud native, beskrevet ovenfor.
Veien til å organisere et utviklingsorientert miljø for applikasjonsadministrasjon.

For mange er GitOps først og fremst en arbeidsflyt basert på Git pushes. Det liker vi også. Men dette er ikke alt: La oss nå se på CI/CD-pipeliner.

GitOps muliggjør kontinuerlig distribusjon (CD) under Kubernetes

GitOps tilbyr en mekanisme for kontinuerlig distribusjon som eliminerer behovet for separate «distribusjonstyringssystemer». Alt arbeidet utføres for deg av Kubernetes.

Applikasjonsoppdateringen krever en oppdatering i Git. Dette er en transaksjonsoppdatering til ønsket tilstand. «Rull ut» skjer deretter innen klyngen av Kubernetes basert på den oppdaterte beskrivelsen.
På grunn av spesifikken i Kubernetes fungerer disse oppdateringene konvergerende. Dette sikrer en mekanisme for kontinuerlig distribusjon, hvor alle oppdateringer er atomære.
Merk: Weave Cloud tilbyr en GitOps-operator som integrerer Git og Kubernetes og gjør det mulig å utføre CD ved å balansere ønsket og nåværende tilstand av klyngen.

Uten kubectl og skript

Bør man unngå å bruke Kubectl for å oppdatere klyngen, spesielt skript for å gruppere kubectl-kommandoer. I stedet kan brukeren oppdatere sin Kubernetes-klynge via Git ved hjelp av en GitOps-pipeline.

Fordelene inkluderer:

Korrektheten. En gruppe oppdateringer kan anvendes, konvergeres og til slutt valideres, som bringer oss nærmere målet om atomær distribusjon. I motsetning til det gir bruken av skript ingen garantier for konvergens (mer om dette nedenfor).
Tryggleik. Siterer Kelsey Hightower: «Begrens tilgangen til Kubernetes-klyngen for automatiseringsverktøy og administratorer som er ansvarlige for debugging eller opprettholdelse av drift.» Se også mitt innlegg om sikkerhet og overholdelse av tekniske spesifikasjoner, samt artikkelen om hacking av Homebrew ved å stjele legitimasjon fra en uaktsomt skrevet Jenkins-skript.
Brukeropplevelse. Kubectl avdekker mekanikken i Kubernetes' objektmodell, som er ganske kompleks. Ideelt sett bør brukere interagere med systemet på et høyere nivå av abstraksjon. Her igjen vil jeg referere til Kelsey og anbefale å se på dette sammendraget.

Forskjellen mellom CI og CD

GitOps forbedrer eksisterende CI/CD-modeller.

Moderne CI-servere fungerer som orkestreringsverktøy. Spesielt er det et verktøy for orkestrering av CI-pipelines. Disse inkluderer build, test, merge til trunk osv. CI-servere automatiserer håndtering av komplekse flerstegs-pipelines. Et vanlig fristende valg er å lage et skript for en rekke Kubernetes-oppdateringer og kjøre det som et element i pipelinen for å push'e endringer til klyngen. Mange spesialister gjør faktisk dette. Likevel er det suboptimalt, og her er hvorfor.

CI bør brukes til å oppdatere trunk, og Kubernetes-klyngen skal endre seg basert på disse oppdateringene for å håndtere CD «internt». Vi kaller dette et pull-modell for CD, i motsetning til CI push-modellen. CD er en del av runtime-orchestrasjon.

Hvorfor CI-servere ikke skal utføre CD gjennom direkte oppdateringer til Kubernetes

Ikke bruk CI-servere til å orkestrere direkte oppdateringer til Kubernetes som et sett med CI-oppgaver. Dette er et antipattern, som vi allerede har diskutert på bloggen vår.

La oss gå tilbake til Alice og Bob.

Hvilke problemer møtte de? Bobs CI-server anvender endringer til klyngen, men hvis den feiler under prosessen, vet ikke Bob hvilken tilstand klyngen er i (eller bør være i) og hvordan han kan fikse det. Det samme gjelder ved suksess.

La oss anta at Bobs team bygget et nytt bilde og deretter oppdaterte deploymentene sine for å distribuere bildet (alt dette fra CI-pipeline).

Hvis bildet bygges korrekt, men pipeline feiler, må teamet finne ut:

Ble oppdateringen distribuert?
Kjører vi en ny bygg? Vil dette føre til unødvendige bivirkninger — med mulighet for å få to bygg av samme uendrede bilde?
Bør vi vente på den neste oppdateringen før vi kjører en bygg?
Hva gikk egentlig galt? Hvilke trinn må gjentas (og hvilke kan trygt gjentas)?

Å organisere en Git-basert arbeidsflyt garanterer ikke at Bobs team ikke vil møte disse problemene. De kan fortsatt gjøre feil med committing av pushes, med tagging eller en annen parameter; imidlertid er denne tilnærmingen fortsatt mye nærmere en eksplisit all-eller-ingenting.

Oppsummert, her er grunnen til at CI-servere ikke skal håndtere CD:

Oppdateringsskripter er ikke alltid deterministiske; det er lett å gjøre feil med dem.
CI-servere konvergerer ikke til en deklarativ klynge-modell.
Det er vanskelig å garantere idempotens. Brukere må forstå den dype semantikken i systemet.
Det er mer komplisert å gjenopprette etter en delvis feil.

Merk om Helm: hvis du ønsker å bruke Helm, anbefaler vi å kombinere det med en GitOps-operator som Flux-Helm. Dette vil bidra til å sikre konvergens. Helm alene er verken deterministisk eller atomisk.

GitOps som den beste måten å implementere Continuous Delivery for Kubernetes

Alice og Bob implementerer GitOps og oppdager at det har blitt mye lettere å jobbe med programvareprodukter, samtidig som de opprettholder høy ytelse og stabilitet. La oss avslutte denne artikkelen med illustrasjoner som viser hvordan deres nye tilnærming ser ut. Merk at vi stort sett snakker om applikasjoner og tjenester, men GitOps kan brukes til å administrere hele plattformen.

Driftsmodell for Kubernetes

Se på det følgende diagrammet. Det representerer Git og container image-lager som felles ressurser for to orkestrerte livssykluser:

Pipelinen for kontinuerlig integrasjon som leser og skriver filer til Git og kan oppdatere lagret for containerbilder.
Runtime GitOps-pipelinen, som kombinerer distribusjon med administrasjon og overvåking. Den leser og skriver filer til Git og kan laste opp containerbilder.

Hva er de viktigste konklusjonene?

Deling av problemer: Merk at begge pipeliner kan utveksle data ved kun å oppdatere Git eller containerbildelageret. Med andre ord, det finnes en brannmur mellom CI og runtime-miljøet. Vi kaller det 'immutability firewall' (immutability firewall), fordi alle oppdateringer av lagre skaper nye versjoner. For mer informasjon om emnet, se lysbildene 72-87. denne presentasjonen.
Du kan bruke hvilken som helst CI- og Git-server: GitOps fungerer med alle komponenter. Du kan fortsette å bruke dine foretrukne CI- og Git-servere, containerbildelagre og testsett. Nesten alle andre verktøy for Continuous Delivery på markedet krever sin egen CI/Git-server eller image-lager. Dette kan bli en begrensende faktor for utviklingen av cloud native. Med GitOps kan du bruke de verktøyene du allerede er vant til.
Hendelser som integrasjonsverktøy: Så snart data i Git oppdateres, varsler Weave Flux (eller Weave Cloud-operatøren) om dette til runtime. Hver gang Kubernetes mottar et sett med endringer, oppdateres Git. Dette gir en enkel integrasjonsmodell for å organisere arbeidsflyter for GitOps, som vist nedenfor.

Konklusjon

GitOps gir sterke garantier for oppdateringene som er nødvendige for ethvert moderne CI/CD-verktøy:

automatisering;
konvergering;
idempotens;
determinisme.

Dette er viktig, fordi det tilbyr en driftsmodell for utviklere innen cloud native.

Tradisjonelle verktøy for systemadministrasjon og overvåking er knyttet til driftsteam som jobber innenfor et runbook. (sett med rutineprosedyrer og operasjoner — anm. oversetter.), knyttet til et spesifikt deployment.
I administrasjonen av cloud native-systemer er overvåkingsverktøy det beste middelet for å evaluere resultatene av deployeringene, slik at utviklerteamet raskt kan reagere på dem.

Tenk deg mange klynger spredt over forskjellige skyer og mange tjenester med sine egne team og deployeringsplaner. GitOps tilbyr en skalerbar og invariant modell for å administrere all denne overfloden.