Merk. overs.: Etter en nylig utgivelse om pull and push-metoder i GitOps, vi så interesse for denne modellen generelt, men det var svært få russiskspråklige publikasjoner om dette emnet (det er rett og slett ingen på Habré). Derfor er vi glade for å tilby din oppmerksomhet en oversettelse av en annen artikkel - om enn for nesten et år siden! - fra Weaveworks, hvor lederen laget begrepet "GitOps." Teksten forklarer essensen av tilnærmingen og viktige forskjeller fra eksisterende.
For et år siden publiserte vi . Den gang delte vi hvordan Weaveworks-teamet lanserte en SaaS fullstendig basert på Kubernetes og utviklet et sett med foreskrivende beste praksis for distribusjon, administrering og overvåking i et skybasert miljø.
Artikkelen viste seg å være populær. Andre begynte å snakke om GitOps og begynte å publisere nye verktøy for , , , , og så videre. Dukket opp på nettsiden vår publikasjoner og GitOps-brukstilfeller. Men noen har fortsatt spørsmål. Hvordan skiller modellen seg fra den tradisjonelle? og kontinuerlig levering ()? Er det nødvendig å bruke Kubernetes?
Vi skjønte snart at en ny beskrivelse var nødvendig, som tilbyr:
- Et stort antall eksempler og historier;
- Spesifikk definisjon av GitOps;
- Sammenligning med tradisjonell kontinuerlig levering.
I denne artikkelen har vi forsøkt å dekke alle disse emnene. Den gir en oppdatert introduksjon til GitOps og et utvikler- og CI/CD-perspektiv. Vi fokuserer først og fremst på Kubernetes, selv om modellen kan generaliseres.
Møt GitOps
Tenk deg Alice. Hun driver Family Insurance, som tilbyr helse-, bil-, hjem- og reiseforsikringer til folk som er for travle til å finne ut av kontrakter selv. Virksomheten hennes startet som et sideprosjekt da Alice jobbet i en bank som dataforsker. En dag skjønte hun at hun kunne bruke avanserte dataalgoritmer til mer effektivt å analysere data og formulere forsikringspakker. Investorer finansierte prosjektet, og nå bringer selskapet hennes inn mer enn 20 millioner dollar i året og vokser raskt. For tiden sysselsetter det 180 personer i ulike stillinger. Dette inkluderer et teknologiteam som utvikler, vedlikeholder nettsiden, databasen og analyserer kundebasen. Teamet på 60 personer ledes av Bob, selskapets tekniske direktør.
Bobs team distribuerer produksjonssystemer i skyen. Kjerneapplikasjonene deres kjører på GKE, og drar fordel av Kubernetes på Google Cloud. I tillegg bruker de ulike data- og analyseverktøy i arbeidet.
Family Insurance hadde ikke tenkt å bruke containere, men ble fanget av Docker-entusiasmen. Selskapet oppdaget snart at GKE gjorde det enkelt å distribuere klynger for å teste nye funksjoner. Jenkins for CI og Quay ble lagt til for å organisere containerregisteret, skript ble skrevet for Jenkins som presset nye containere og konfigurasjoner til GKE.
Det har gått litt tid. Alice og Bob var skuffet over ytelsen til deres valgte tilnærming og dens innvirkning på virksomheten. Innføringen av containere forbedret ikke produktiviteten så mye som teamet hadde håpet. Noen ganger ville distribusjoner gå i stykker, og det var uklart om kodeendringer hadde skylden. Det viste seg også å være vanskelig å spore konfigurasjonsendringer. Ofte var det nødvendig å opprette en ny klynge og flytte applikasjoner til den, siden dette var den enkleste måten å eliminere rotet som systemet hadde blitt. Alice var redd for at situasjonen skulle bli verre etter hvert som applikasjonen utviklet seg (i tillegg kom et nytt prosjekt basert på maskinlæring). Bob hadde automatisert det meste av arbeidet og forsto ikke hvorfor rørledningen fortsatt var ustabil, ikke skalert godt og krevde manuell intervensjon med jevne mellomrom?
Så lærte de om GitOps. Denne avgjørelsen viste seg å være akkurat det de trengte for å komme seg videre.
Alice og Bob har hørt om Git, DevOps og infrastruktur som kodearbeidsflyter i årevis. Det som er unikt med GitOps er at det gir et sett med beste praksis – både definitive og normative – for å implementere disse ideene i Kubernetes-sammenheng. Dette temaet , inkludert i .
Familieforsikring bestemmer seg for å implementere GitOps. Selskapet har nå en automatisert driftsmodell som er kompatibel med Kubernetes og skurtreskere fart med stabilitetfordi de:
- fant ut at teamets produktivitet doblet seg uten at noen ble gale;
- sluttet å levere skript. I stedet kan de nå fokusere på nye funksjoner og forbedre ingeniørmetoder – for eksempel introdusere kanarieutrullinger og forbedre testing;
- vi har forbedret distribusjonsprosessen slik at den sjelden går i stykker;
- fikk muligheten til å gjenopprette distribusjoner etter delvise feil uten manuell intervensjon;
- kjøpt bruktоStørre tillit til leveringssystemer. Alice og Bob oppdaget at de kunne dele opp teamet i mikroserviceteam som jobber parallelt;
- kan gjøre 30-50 endringer i prosjektet hver dag gjennom innsatsen fra hver gruppe og prøve nye teknikker;
- det er lett å tiltrekke seg nye utviklere til prosjektet, som har muligheten til å rulle ut oppdateringer til produksjonen ved hjelp av pull-forespørsler innen få timer;
- enkelt bestå revisjon innenfor rammen av SOC2 (for overholdelse av tjenesteleverandører med krav til sikker datahåndtering; les mer, for eksempel, — ca. oversett.).
Hva skjedde?
GitOps er to ting:
- Driftsmodell for Kubernetes og cloud native. Den gir et sett med beste praksis for distribusjon, administrasjon og overvåking av containeriserte klynger og applikasjoner. Elegant definisjon i formen fra :
- Veien til å skape et utviklersentrisk applikasjonsadministrasjonsmiljø. Vi bruker Git-arbeidsflyten til både drift og utvikling. Vær oppmerksom på at dette ikke bare handler om Git push, men om å organisere hele settet med CI/CD og UI/UX-verktøy.
Noen få ord om Git
Hvis du ikke er kjent med versjonskontrollsystemer og Git-basert arbeidsflyt, anbefaler vi på det sterkeste å lære om dem. Å jobbe med grener og pull-forespørsler kan virke som svart magi i begynnelsen, men fordelene er verdt innsatsen. Her å starte.
Hvordan Kubernetes fungerer
I historien vår henvendte Alice og Bob seg til GitOps etter å ha jobbet med Kubernetes en stund. Faktisk er GitOps nært knyttet til Kubernetes - det er en operasjonell modell for infrastruktur og applikasjoner basert på Kubernetes.
Hva gir Kubernetes brukere?
Her er noen hovedfunksjoner:
- I Kubernetes-modellen kan alt beskrives i deklarativ form.
- Kubernetes API-serveren tar denne erklæringen som input og forsøker deretter kontinuerlig å bringe klyngen til tilstanden beskrevet i erklæringen.
- Erklæringer er tilstrekkelige til å beskrive og administrere et bredt spekter av arbeidsbelastninger – «applikasjoner».
- Som et resultat oppstår endringer i applikasjonen og klyngen på grunn av:
- endringer i beholderbilder;
- endringer i den deklarative spesifikasjonen;
- feil i miljøet - for eksempel containerkrasj.
Kubernetes' store konvergensegenskaper
Når en administrator gjør konfigurasjonsendringer, vil Kubernetes-orkestratoren bruke dem på klyngen så lenge statusen er vil ikke komme i nærheten av den nye konfigurasjonen. Denne modellen fungerer for alle Kubernetes-ressurser og kan utvides med Custom Resource Definitions (CRD-er). Derfor har Kubernetes-distribusjoner følgende fantastiske egenskaper:
- Automatisering: Kubernetes-oppdateringer gir en mekanisme for å automatisere prosessen med å ta i bruk endringer elegant og i tide.
- Konvergens: Kubernetes vil fortsette å forsøke oppdateringer til de er vellykket.
- Idempotens: Gjentatte applikasjoner av konvergens fører til samme resultat.
- Determinisme: Når ressursene er tilstrekkelige, avhenger tilstanden til den oppdaterte klyngen bare av ønsket tilstand.
Hvordan GitOps fungerer
Vi har lært nok om Kubernetes til å forklare hvordan GitOps fungerer.
La oss gå tilbake til Family Insurances mikroserviceteam. Hva pleier de å gjøre? Se på listen nedenfor (hvis noen elementer i den virker merkelige eller ukjente, vennligst hold ut med å kritisere og bli hos oss). Dette er bare eksempler på Jenkins-baserte arbeidsflyter. Det er mange andre prosesser når man jobber med andre verktøy.
Hovedsaken er at vi ser at hver oppdatering avsluttes med endringer i konfigurasjonsfilene og Git-repositoriene. Disse endringene i Git får "GitOps-operatøren" til å oppdatere klyngen:
1. Arbeidsprosess: "Jenkins bygge - mestergren'.
Liste over gjøremål:
- Jenkins skyver taggede bilder til Quay;
- Jenkins skyver konfigurasjons- og rordiagrammer til hovedlagringsbøtten;
- Skyfunksjonen kopierer konfigurasjonen og diagrammene fra hovedlagringsbøtten til master Git-depotet;
- GitOps-operatøren oppdaterer klyngen.
2. Jenkins build - utgivelse eller hurtigreparasjonsgren:
- Jenkins skyver umerkede bilder til Quay;
- Jenkins skyver konfigurasjons- og Helm-diagrammer til oppbevaringsbøtten;
- Skyfunksjonen kopierer konfigurasjonen og diagrammene fra iscenesettelsen lagringsbøtte til iscenesettelsen Git repository;
- GitOps-operatøren oppdaterer klyngen.
3. Jenkins bygge - utvikle eller funksjon gren:
- Jenkins skyver umerkede bilder til Quay;
- Jenkins skyver config- og Helm-diagrammer inn i utviklingslagringsbøtten;
- Skyfunksjonen kopierer konfigurasjonen og diagrammene fra utviklingslagringsbøtten til develop Git-depotet;
- GitOps-operatøren oppdaterer klyngen.
4. Legger til en ny klient:
- Lederen eller administratoren (LCM/ops) kaller Gradle for å innledningsvis distribuere og konfigurere nettverksbelastningsbalansere (NLBs);
- LCM/ops forplikter en ny konfigurasjon for å forberede distribusjonen for oppdateringer;
- GitOps-operatøren oppdaterer klyngen.
Kort beskrivelse av GitOps
- Beskriv ønsket tilstand for hele systemet ved å bruke deklarative spesifikasjoner for hvert miljø (i historien vår definerer Bobs team hele systemkonfigurasjonen i Git).
- Git-depotet er den eneste kilden til sannhet angående ønsket tilstand for hele systemet.
- Alle endringer i ønsket tilstand gjøres gjennom commits i Git.
- Alle ønskede klyngeparametere er også observerbare i selve klyngen. På denne måten kan vi bestemme om de sammenfaller (konvergerer, konvergerer) eller avvike (diverge, divergere) ønskede og observerte tilstander.
- Hvis de ønskede og observerte tilstandene er forskjellige, så:
- Det er en konvergensmekanisme som før eller siden automatisk synkroniserer målet og observerte tilstander. Inne i klyngen gjør Kubernetes dette.
- Prosessen starter umiddelbart med et varsel om "forpliktet endring".
- Etter en viss konfigurerbar tidsperiode kan et "diff"-varsel sendes hvis tilstandene er forskjellige.
- På denne måten forårsaker alle forpliktelser i Git verifiserbare og idempotente oppdateringer til klyngen.
- Tilbakerulling er konvergens til en tidligere ønsket tilstand.
- Konvergensen er endelig. Dens forekomst er indikert med:
- Ingen diff-varsler i en viss tidsperiode.
- "konvergert" varsel (f.eks. webhook, Git-tilbakeskrivningshendelse).
Hva er divergens?
La oss gjenta igjen: alle ønskede klyngeegenskaper må kunne observeres i selve klyngen.
Noen eksempler på divergens:
- Endring i konfigurasjonsfil på grunn av sammenslåing av grener i Git.
- En endring i konfigurasjonsfilen på grunn av en Git-commit utført av GUI-klienten.
- Flere endringer til ønsket tilstand på grunn av PR i Git etterfulgt av å bygge beholderbildet og konfigurasjonsendringer.
- En endring i tilstanden til klyngen på grunn av en feil, ressurskonflikt som resulterer i "dårlig oppførsel", eller ganske enkelt tilfeldig avvik fra den opprinnelige tilstanden.
Hva er mekanismen for konvergens?
Noen få eksempler:
- For containere og klynger er konvergensmekanismen levert av Kubernetes.
- Den samme mekanismen kan brukes til å administrere Kubernetes-baserte applikasjoner og design (som Istio og Kubeflow).
- En mekanisme for å administrere den operasjonelle interaksjonen mellom Kubernetes, bildelager og Git gir , som er en del .
- For basismaskiner må konvergensmekanismen være deklarativ og autonom. Fra egen erfaring kan vi si det nærmest denne definisjonen, men krever fortsatt menneskelig kontroll. I denne forstand utvider GitOps tradisjonen med Infrastructure as Code.
GitOps kombinerer Git med den utmerkede konvergensmotoren til Kubernetes for å gi en modell for utnyttelse.
GitOps lar oss si: Bare de systemene som kan beskrives og observeres kan automatiseres og kontrolleres.
GitOps er ment for hele skyen native stabelen (for eksempel Terraform, etc.)
GitOps er ikke bare Kubernetes. Vi ønsker at hele systemet skal drives deklarativt og bruke konvergens. Med hele systemet mener vi en samling av miljøer som arbeider med Kubernetes - for eksempel "dev cluster 1", "produksjon" osv. Hvert miljø inkluderer maskiner, klynger, applikasjoner, samt grensesnitt for eksterne tjenester som gir data, overvåking og etc.
Legg merke til hvor viktig Terraform er for bootstrapping-problemet i dette tilfellet. Kubernetes må distribueres et sted, og ved å bruke Terraform kan vi bruke de samme GitOps-arbeidsflytene for å lage kontrolllaget som underbygger Kubernetes og applikasjoner. Dette er en nyttig beste praksis.
Det er et sterkt fokus på å bruke GitOps-konsepter på lag på toppen av Kubernetes. For øyeblikket finnes det løsninger av typen GitOps for Istio, Helm, Ksonnet, OpenFaaS og Kubeflow, samt for eksempel for Pulumi, som lager et lag for utvikling av applikasjoner for cloud native.
Kubernetes CI/CD: sammenligne GitOps med andre tilnærminger
Som nevnt er GitOps to ting:
- Driftsmodellen for Kubernetes og cloud native beskrevet ovenfor.
- Veien til et utviklersentrisk applikasjonsadministrasjonsmiljø.
For mange er GitOps først og fremst en arbeidsflyt basert på Git-push. Vi liker ham også. Men det er ikke alt: la oss nå se på CI/CD-rørledninger.
GitOps muliggjør kontinuerlig distribusjon (CD) for Kubernetes
GitOps tilbyr en kontinuerlig distribusjonsmekanisme som eliminerer behovet for separate «distribusjonsstyringssystemer». Kubernetes gjør alt arbeidet for deg.
- Oppdatering av applikasjonen krever oppdatering i Git. Dette er en transaksjonsoppdatering til ønsket tilstand. "Deployment" gjøres deretter innenfor klyngen av Kubernetes selv basert på den oppdaterte beskrivelsen.
- På grunn av hvordan Kubernetes fungerer, er disse oppdateringene konvergerende. Dette gir en mekanisme for kontinuerlig distribusjon der alle oppdateringer er atomære.
- Merk: tilbyr en GitOps-operatør som integrerer Git og Kubernetes og lar CD utføres ved å avstemme ønsket og gjeldende tilstand til klyngen.
Uten kubectl og skript
Du bør unngå å bruke Kubectl til å oppdatere klyngen din, og spesielt unngå å bruke skript for å gruppere kubectl-kommandoer. I stedet, med GitOps-pipeline, kan en bruker oppdatere Kubernetes-klyngen sin via Git.
Fordelene inkluderer:
- Ikke sant. En gruppe oppdateringer kan brukes, konvergeres og til slutt valideres, noe som bringer oss nærmere målet om atomdistribusjon. I motsetning til dette gir ikke bruk av skript noen garanti for konvergens (mer om dette nedenfor).
- Безопасность. Kelsey Hightower: "Begrens tilgangen til Kubernetes-klyngen til automatiseringsverktøy og administratorer som er ansvarlige for å feilsøke eller vedlikeholde den." se også om sikkerhet og overholdelse av tekniske spesifikasjoner, samt ved å stjele legitimasjon fra et uforsiktig skrevet Jenkins-manus.
- Brukererfaring. Kubectl avslører mekanikken til Kubernetes-objektmodellen, som er ganske komplisert. Ideelt sett bør brukere samhandle med systemet på et høyere abstraksjonsnivå. Her vil jeg igjen referere til Kelsey og anbefale å se .
Forskjellen mellom CI og CD
GitOps forbedrer eksisterende CI/CD-modeller.
En moderne CI-server er et orkestreringsverktøy. Spesielt er det et verktøy for å orkestrere CI-rørledninger. Disse inkluderer bygging, test, sammenslåing til trunk osv. CI-servere automatiserer administrasjonen av komplekse flertrinns rørledninger. En vanlig fristelse er å skrive et sett med Kubernetes-oppdateringer og kjøre det som en del av en pipeline for å pushe endringer i klyngen. Dette er faktisk hva mange eksperter gjør. Dette er imidlertid ikke optimalt, og her er hvorfor.
CI bør brukes til å pushe oppdateringer til trunk, og Kubernetes-klyngen bør endre seg selv basert på disse oppdateringene for å administrere CDen internt. Vi kaller det , i motsetning til CI push-modellen. CD er en del runtime orkestrering.
Hvorfor CI-servere ikke bør lage CDer via direkte oppdateringer i Kubernetes
Ikke bruk en CI-server til å organisere direkte oppdateringer til Kubernetes som et sett med CI-jobber. Dette er anti-mønsteret vi snakker om på bloggen din.
La oss gå tilbake til Alice og Bob.
Hvilke problemer møtte de? Bobs CI-server bruker endringene på klyngen, men hvis den krasjer i prosessen, vil ikke Bob vite hvilken tilstand klyngen er (eller skal være) i eller hvordan den skal fikses. Det samme gjelder i tilfelle suksess.
La oss anta at Bobs team bygde et nytt bilde og deretter lappet distribusjonene sine for å distribuere bildet (alt fra CI-rørledningen).
Hvis bildet bygges normalt, men rørledningen mislykkes, må teamet finne ut:
- Har oppdateringen rullet ut?
- Lanserer vi et nytt bygg? Vil dette føre til unødvendige bivirkninger - med mulighet for å ha to bygg av samme uforanderlige bilde?
- Bør vi vente på neste oppdatering før vi kjører bygget?
- Hva gikk egentlig galt? Hvilke trinn må gjentas (og hvilke er trygge å gjenta)?
Etablering av en Git-basert arbeidsflyt garanterer ikke at Bobs team ikke vil støte på disse problemene. De kan fortsatt gjøre en feil med commit push, taggen eller en annen parameter; denne tilnærmingen er imidlertid fortsatt mye nærmere en eksplisitt alt-eller-ingenting-tilnærming.
For å oppsummere, her er hvorfor CI-servere ikke skal håndtere CD:
- Oppdateringsskript er ikke alltid deterministiske; Det er lett å gjøre feil i dem.
- CI-servere konvergerer ikke til den deklarative klyngemodellen.
- Det er vanskelig å garantere idempotens. Brukere må forstå den dype semantikken i systemet.
- Det er vanskeligere å komme seg etter en delvis feil.
Merknad om Helm: Hvis du vil bruke Helm, anbefaler vi å kombinere den med en GitOps-operatør som f.eks. . Dette vil bidra til å sikre konvergens. Helm i seg selv er verken deterministisk eller atomær.
GitOps som den beste måten å implementere kontinuerlig levering for Kubernetes
Alice og Bobs team implementerer GitOps og oppdager at det har blitt mye enklere å jobbe med programvareprodukter, opprettholde høy ytelse og stabilitet. La oss avslutte denne artikkelen med en illustrasjon som viser hvordan deres nye tilnærming ser ut. Husk at vi stort sett snakker om applikasjoner og tjenester, men GitOps kan brukes til å administrere en hel plattform.
Driftsmodell for Kubernetes
Se på følgende diagram. Den presenterer Git og beholderbildelageret som delte ressurser for to orkestrerte livssykluser:
- En kontinuerlig integrasjonspipeline som leser og skriver filer til Git og kan oppdatere et lager av containerbilder.
- En Runtime GitOps-pipeline som kombinerer distribusjon med administrasjon og observerbarhet. Den leser og skriver filer til Git og kan laste ned containerbilder.
Hva er hovedfunnene?
- Separasjon av bekymringer: Vær oppmerksom på at begge rørledningene kun kan kommunisere ved å oppdatere Git eller bildelageret. Det er med andre ord en brannmur mellom CI og runtime-miljøet. Vi kaller det "uforanderlig brannmur" (uforanderlig brannmur), siden alle depotoppdateringer oppretter nye versjoner. For mer informasjon om dette emnet, se lysbilde 72-87 .
- Du kan bruke hvilken som helst CI- og Git-server: GitOps fungerer med hvilken som helst komponent. Du kan fortsette å bruke dine favoritt CI- og Git-servere, bildelagre og testsuiter. Nesten alle andre Continuous Delivery-verktøy på markedet krever sin egen CI/Git-server eller bildelager. Dette kan bli en begrensende faktor i utviklingen av cloud native. Med GitOps kan du bruke kjente verktøy.
- Arrangementer som integreringsverktøy: Så snart data i Git er oppdatert, varsler Weave Flux (eller Weave Cloud-operatøren) kjøretid. Når Kubernetes godtar et endringssett, oppdateres Git. Dette gir en enkel integreringsmodell for organisering av arbeidsflyter for GitOps, som vist nedenfor.
Konklusjon
GitOps gir de sterke oppdateringsgarantiene som kreves av ethvert moderne CI/CD-verktøy:
- automasjon;
- konvergens;
- idempotens;
- determinisme.
Dette er viktig fordi det tilbyr en operasjonsmodell for cloud-native utviklere.
- Tradisjonelle verktøy for å administrere og overvåke systemer er knyttet til driftsteam som opererer innenfor en runbook (et sett med rutinemessige prosedyrer og operasjoner - ca. overs.), knyttet til en spesifikk distribusjon.
- I skybasert administrasjon er observasjonsverktøy den beste måten å måle resultatene av distribusjoner på, slik at utviklingsteamet kan reagere raskt.
Se for deg mange klynger spredt over forskjellige skyer og mange tjenester med egne team og distribusjonsplaner. GitOps tilbyr en skala-invariant modell for å administrere all denne overfloden.
PS fra oversetter
Les også på bloggen vår:
- «";
- «";
- «'.
Kun registrerte brukere kan delta i undersøkelsen. , vær så snill.
Visste du om GitOps før disse to oversettelsene dukket opp på Habré?
-
Ja, jeg visste alt
-
Bare overfladisk
-
Ikke
35 brukere stemte. 10 brukere avsto.
Kilde: www.habr.com