Bemærk. overs.: Efter en nylig udgivelse om pull and push-metoder i GitOps, så vi generelt interesse for denne model, men der var meget få russisksprogede publikationer om dette emne (der er simpelthen ingen på Habré). Derfor er vi glade for at kunne tilbyde din opmærksomhed en oversættelse af en anden artikel - dog for næsten et år siden! - fra Weaveworks, hvis leder opfandt udtrykket "GitOps." Teksten forklarer essensen af tilgangen og de vigtigste forskelle fra eksisterende.
For et år siden udgav vi . Dengang delte vi, hvordan Weaveworks-teamet lancerede en SaaS, der udelukkende var baseret på Kubernetes og udviklede et sæt præskriptive bedste praksisser til implementering, styring og overvågning i et cloud-native miljø.
Artiklen viste sig at være populær. Andre mennesker begyndte at tale om GitOps og begyndte at udgive nye værktøjer til , , , , og så videre. Dukkede op på vores hjemmeside publikationer og GitOps use cases. Men nogle mennesker har stadig spørgsmål. Hvordan adskiller modellen sig fra den traditionelle? og løbende levering ()? Er det nødvendigt at bruge Kubernetes?
Vi indså hurtigt, at der var behov for en ny beskrivelse, der tilbyder:
- En lang række eksempler og historier;
- Specifik definition af GitOps;
- Sammenligning med traditionel kontinuerlig levering.
I denne artikel har vi forsøgt at dække alle disse emner. Det giver en opdateret introduktion til GitOps og et udvikler- og CI/CD-perspektiv. Vi fokuserer primært på Kubernetes, selvom modellen kan generaliseres.
Mød GitOps
Forestil dig Alice. Hun driver Family Insurance, som tilbyder sundheds-, bil-, hjem- og rejseforsikringer til folk, der har for travlt til selv at finde ud af kontrakternes ins og outs. Hendes virksomhed startede som et sideprojekt, da Alice arbejdede i en bank som dataforsker. En dag indså hun, at hun kunne bruge avancerede computeralgoritmer til mere effektivt at analysere data og formulere forsikringspakker. Investorer finansierede projektet, og nu indbringer hendes virksomhed mere end 20 millioner dollars om året og vokser hurtigt. I øjeblikket beskæftiger den 180 medarbejdere i forskellige stillinger. Dette inkluderer et teknologiteam, der udvikler, vedligeholder hjemmesiden, databasen og analyserer kundebasen. Holdet på 60 personer ledes af Bob, virksomhedens tekniske direktør.
Bobs team implementerer produktionssystemer i skyen. Deres kerneapplikationer kører på GKE og drager fordel af Kubernetes på Google Cloud. Derudover bruger de forskellige data- og analyseværktøjer i deres arbejde.
Family Insurance satte sig ikke for at bruge containere, men blev fanget af Docker-begejstringen. Virksomheden opdagede hurtigt, at GKE gjorde det nemt at implementere klynger for at teste nye funktioner. Jenkins til CI og Quay blev tilføjet for at organisere containerregistret, scripts blev skrevet til Jenkins, der skubbede nye containere og konfigurationer til GKE.
Der er gået noget tid. Alice og Bob var skuffede over ydeevnen af deres valgte tilgang og dens indvirkning på virksomheden. Introduktionen af containere forbedrede ikke produktiviteten så meget, som holdet havde håbet. Nogle gange ville implementeringer gå i stykker, og det var uklart, om kodeændringer var skylden. Det viste sig også at være svært at spore konfigurationsændringer. Ofte var det nødvendigt at oprette en ny klynge og flytte applikationer til den, da dette var den nemmeste måde at fjerne det rod, som systemet var blevet til. Alice var bange for, at situationen ville blive værre, efterhånden som applikationen udviklede sig (derudover var et nyt projekt baseret på machine learning under opsejling). Bob havde automatiseret det meste af arbejdet og forstod ikke, hvorfor rørledningen stadig var ustabil, ikke skalerede godt og krævede manuel indgriben med jævne mellemrum?
Så lærte de om GitOps. Denne beslutning viste sig at være præcis, hvad de havde brug for for at komme videre.
Alice og Bob har hørt om Git, DevOps og infrastruktur som kode-workflows i årevis. Det unikke ved GitOps er, at det bringer et sæt af bedste praksis – både endegyldige og normative – til at implementere disse ideer i forbindelse med Kubernetes. Dette tema , herunder i .
Familieforsikring beslutter at implementere GitOps. Virksomheden har nu en automatiseret driftsmodel, der er kompatibel med Kubernetes og mejetærskere hastighed med stabilitetfordi de:
- fandt ud af, at holdets produktivitet blev fordoblet, uden at nogen gik amok;
- holdt op med at vise scripts. I stedet kan de nu fokusere på nye funktioner og forbedre ingeniørmetoder - for eksempel at introducere kanarie-udrulninger og forbedre testning;
- vi har forbedret implementeringsprocessen, så den sjældent går i stykker;
- fik mulighed for at gendanne implementeringer efter delvise fejl uden manuel indgriben;
- købt brugtоStørre tillid til leveringssystemer. Alice og Bob opdagede, at de kunne opdele holdet i mikroservice-teams, der arbejdede parallelt;
- kan foretage 30-50 ændringer i projektet hver dag gennem indsatsen fra hver gruppe og prøve nye teknikker;
- det er nemt at tiltrække nye udviklere til projektet, som har mulighed for at udrulle opdateringer til produktionen ved hjælp af pull-anmodninger inden for få timer;
- nemt bestå revision inden for rammerne af SOC2 (for serviceudbyderes overholdelse af krav til sikker datahåndtering; læs mere, f.eks. - ca. oversættelse).
Hvad skete der?
GitOps er to ting:
- Operationel model for Kubernetes og cloud native. Det giver et sæt bedste praksisser til implementering, styring og overvågning af containerklynger og applikationer. Elegant definition i formen fra :
- Vejen til at skabe et udviklercentreret applikationsadministrationsmiljø. Vi anvender Git-arbejdsgangen til både drift og udvikling. Bemærk venligst, at dette ikke kun handler om Git push, men om at organisere hele sættet af CI/CD og UI/UX værktøjer.
Et par ord om Git
Hvis du ikke er bekendt med versionskontrolsystemer og Git-baserede arbejdsgange, anbefaler vi stærkt at lære om dem. At arbejde med grene og pull-anmodninger kan virke som sort magi i starten, men fordelene er besværet værd. Her at begynde.
Sådan fungerer Kubernetes
I vores historie henvendte Alice og Bob sig til GitOps efter at have arbejdet med Kubernetes i et stykke tid. Faktisk er GitOps tæt knyttet til Kubernetes - det er en operationel model for infrastruktur og applikationer baseret på Kubernetes.
Hvad giver Kubernetes brugerne?
Her er nogle hovedfunktioner:
- I Kubernetes-modellen kan alt beskrives i deklarativ form.
- Kubernetes API-serveren tager denne erklæring som input og forsøger derefter løbende at bringe klyngen i den tilstand, der er beskrevet i erklæringen.
- Erklæringer er tilstrækkelige til at beskrive og administrere en bred vifte af arbejdsbelastninger - "applikationer".
- Som følge heraf opstår ændringer i applikationen og klyngen på grund af:
- ændringer i containerbilleder;
- ændringer i den deklarative specifikation;
- fejl i miljøet - for eksempel containernedbrud.
Kubernetes' store konvergensevner
Når en administrator foretager konfigurationsændringer, vil Kubernetes-orkestratoren anvende dem på klyngen, så længe dens tilstand er vil ikke komme tæt på den nye konfiguration. Denne model fungerer for enhver Kubernetes-ressource og kan udvides med Custom Resource Definitions (CRD'er). Derfor har Kubernetes-implementeringer følgende vidunderlige egenskaber:
- Automation: Kubernetes-opdateringer giver en mekanisme til at automatisere processen med at anvende ændringer elegant og rettidigt.
- Konvergens: Kubernetes vil fortsætte med at forsøge at opdatere, indtil det lykkes.
- Idempotens: Gentagne anvendelser af konvergens fører til det samme resultat.
- Determinisme: Når ressourcerne er tilstrækkelige, afhænger tilstanden af den opdaterede klynge kun af den ønskede tilstand.
Sådan fungerer GitOps
Vi har lært nok om Kubernetes til at forklare, hvordan GitOps fungerer.
Lad os vende tilbage til Family Insurances mikroserviceteams. Hvad plejer de at gøre? Se på listen nedenfor (hvis nogen af genstandene i den virker mærkelige eller ukendte, bedes du vente med at kritisere og blive hos os). Dette er blot eksempler på Jenkins-baserede arbejdsgange. Der er mange andre processer, når man arbejder med andre værktøjer.
Det vigtigste er, at vi ser, at hver opdatering slutter med ændringer af konfigurationsfilerne og Git-lagrene. Disse ændringer af Git får "GitOps-operatøren" til at opdatere klyngen:
1. Arbejdsproces: "Jenkins build - mestergren'.
Opgaveliste:
- Jenkins skubber mærkede billeder til Quay;
- Jenkins skubber config- og Helm-diagrammer til hovedlagerspanden;
- Cloud-funktionen kopierer konfigurationen og diagrammerne fra master storage bucket til master Git repository;
- GitOps-operatøren opdaterer klyngen.
2. Jenkins build - udgivelse eller hotfix-gren:
- Jenkins skubber umærkede billeder til Quay;
- Jenkins skubber config- og Helm-diagrammer til staging storage-bøtten;
- Cloud-funktionen kopierer konfigurationen og diagrammerne fra iscenesættelseslagringsbøtten til iscenesættelses Git-lageret;
- GitOps-operatøren opdaterer klyngen.
3. Jenkins build - udvikle eller feature gren:
- Jenkins skubber umærkede billeder til Quay;
- Jenkins skubber config- og Helm-diagrammer ind i udviklingslagringsbøtten;
- Skyfunktionen kopierer konfigurationen og diagrammerne fra develop storage bucket til develop Git repository;
- GitOps-operatøren opdaterer klyngen.
4. Tilføjelse af en ny klient:
- Manageren eller administratoren (LCM/ops) kalder Gradle for indledningsvis at implementere og konfigurere netværksbelastningsbalancere (NLB'er);
- LCM/ops begår en ny konfiguration for at forberede implementeringen til opdateringer;
- GitOps-operatøren opdaterer klyngen.
Kort beskrivelse af GitOps
- Beskriv den ønskede tilstand for hele systemet ved hjælp af deklarative specifikationer for hvert miljø (i vores historie definerer Bobs team hele systemkonfigurationen i Git).
- Git-lageret er den eneste kilde til sandhed vedrørende den ønskede tilstand af hele systemet.
- Alle ændringer til den ønskede tilstand foretages gennem commits i Git.
- Alle ønskede klyngeparametre er også observerbare i selve klyngen. På denne måde kan vi bestemme, om de falder sammen (konvergerer, Converge) eller afvige (divergere, afviger) ønskede og observerede tilstande.
- Hvis de ønskede og observerede tilstande er forskellige, så:
- Der er en konvergensmekanisme, der før eller siden automatisk synkroniserer målet og observerede tilstande. Inde i klyngen gør Kubernetes dette.
- Processen starter med det samme med en "forandringsbegået"-advarsel.
- Efter et konfigurerbart tidsrum kan der sendes en "diff"-advarsel, hvis tilstandene er forskellige.
- På denne måde forårsager alle commits i Git verificerbare og idempotente opdateringer til klyngen.
- Rollback er konvergens til en tidligere ønsket tilstand.
- Konvergensen er endelig. Dens forekomst er angivet ved:
- Ingen forskelsadvarsler i en vis periode.
- "konvergeret" advarsel (f.eks. webhook, Git-tilbageskrivningsbegivenhed).
Hvad er divergens?
Lad os gentage det igen: alle ønskede klyngeegenskaber skal kunne observeres i selve klyngen.
Nogle eksempler på divergens:
- Ændring i konfigurationsfil på grund af fletning af grene i Git.
- En ændring i konfigurationsfilen på grund af en Git-commit lavet af GUI-klienten.
- Flere ændringer til den ønskede tilstand på grund af PR i Git efterfulgt af opbygning af containerbilledet og konfigurationsændringer.
- En ændring i klyngens tilstand på grund af en fejl, ressourcekonflikt, der resulterer i "dårlig adfærd", eller blot tilfældig afvigelse fra den oprindelige tilstand.
Hvad er mekanismen for konvergens?
Et par eksempler:
- For containere og klynger leveres konvergensmekanismen af Kubernetes.
- Den samme mekanisme kan bruges til at administrere Kubernetes-baserede applikationer og designs (såsom Istio og Kubeflow).
- En mekanisme til styring af den operationelle interaktion mellem Kubernetes, billedarkiver og Git giver , som er en del .
- For basismaskiner skal konvergensmekanismen være deklarativ og autonom. Ud fra vores egen erfaring kan vi sige det tættest på denne definition, men kræver stadig menneskelig kontrol. I denne forstand udvider GitOps traditionen med infrastruktur som kode.
GitOps kombinerer Git med den fremragende konvergensmotor fra Kubernetes for at give en model til udnyttelse.
GitOps giver os mulighed for at sige: Kun de systemer, der kan beskrives og observeres, kan automatiseres og kontrolleres.
GitOps er beregnet til hele cloud native stakken (for eksempel Terraform osv.)
GitOps er ikke kun Kubernetes. Vi ønsker, at hele systemet skal drives deklarativt og bruge konvergens. Med hele systemet mener vi en samling af miljøer, der arbejder med Kubernetes - for eksempel "dev cluster 1", "produktion" osv. Hvert miljø inkluderer maskiner, klynger, applikationer samt grænseflader til eksterne tjenester, der leverer data, overvågning og osv.
Læg mærke til, hvor vigtig Terraform er for bootstrapping-problemet i dette tilfælde. Kubernetes skal installeres et sted, og ved at bruge Terraform kan vi anvende de samme GitOps-arbejdsgange for at skabe det kontrollag, der understøtter Kubernetes og applikationer. Dette er en nyttig bedste praksis.
Der er et stærkt fokus på at anvende GitOps-koncepter på lag oven på Kubernetes. I øjeblikket er der løsninger af GitOps-typen til Istio, Helm, Ksonnet, OpenFaaS og Kubeflow, samt for eksempel til Pulumi, som skaber et lag til udvikling af applikationer til cloud native.
Kubernetes CI/CD: Sammenligning af GitOps med andre tilgange
Som nævnt er GitOps to ting:
- Driftsmodellen for Kubernetes og cloud native beskrevet ovenfor.
- Vejen til et udviklercentreret applikationsadministrationsmiljø.
For mange er GitOps primært en arbejdsgang baseret på Git-push. Vi kan også lide ham. Men det er ikke alt: Lad os nu se på CI/CD-pipelines.
GitOps muliggør kontinuerlig implementering (CD) til Kubernetes
GitOps tilbyder en kontinuerlig implementeringsmekanisme, der eliminerer behovet for separate "implementeringsstyringssystemer." Kubernetes gør alt arbejdet for dig.
- Opdatering af applikationen kræver opdatering i Git. Dette er en transaktionsopdatering til den ønskede tilstand. "Deployment" udføres derefter i klyngen af Kubernetes selv baseret på den opdaterede beskrivelse.
- På grund af karakteren af, hvordan Kubernetes fungerer, er disse opdateringer konvergerende. Dette giver en mekanisme til kontinuerlig implementering, hvor alle opdateringer er atomare.
- Note: tilbyder en GitOps-operatør, der integrerer Git og Kubernetes og tillader CD at blive udført ved at afstemme den ønskede og aktuelle tilstand af klyngen.
Uden kubectl og scripts
Du bør undgå at bruge Kubectl til at opdatere din klynge, og især undgå at bruge scripts til at gruppere kubectl-kommandoer. I stedet kan en bruger med GitOps-pipelinen opdatere deres Kubernetes-klynge via Git.
Fordelene omfatter:
- Ret. En gruppe af opdateringer kan anvendes, konvergeres og til sidst valideres, hvilket bringer os tættere på målet om atomudbredelse. I modsætning hertil giver brug af scripts ikke nogen garanti for konvergens (mere om dette nedenfor).
- Безопасность. Kelsey Hightower: "Begræns adgangen til din Kubernetes-klynge til automatiseringsværktøjer og administratorer, der er ansvarlige for fejlretning eller vedligeholdelse af den." se også om sikkerhed og overholdelse af tekniske specifikationer, samt ved at stjæle legitimationsoplysninger fra et skødesløst skrevet Jenkins-manuskript.
- Brugererfaring. Kubectl afslører mekanikken i Kubernetes objektmodellen, som er ret kompleks. Ideelt set bør brugere interagere med systemet på et højere abstraktionsniveau. Her vil jeg igen henvise til Kelsey og anbefale at se .
Forskellen mellem CI og CD
GitOps forbedrer eksisterende CI/CD-modeller.
En moderne CI-server er et orkestreringsværktøj. Det er især et værktøj til at orkestrere CI-pipelines. Disse omfatter build, test, fletning til trunk osv. CI-servere automatiserer styringen af komplekse flertrinspipelines. En almindelig fristelse er at skrive et sæt Kubernetes-opdateringer og køre det som en del af en pipeline for at skubbe ændringer til klyngen. Det er faktisk, hvad mange eksperter gør. Dette er dog ikke optimalt, og her er hvorfor.
CI skal bruges til at skubbe opdateringer til stammen, og Kubernetes-klyngen skal ændre sig selv baseret på disse opdateringer for at administrere cd'en internt. Vi kalder det , i modsætning til CI push-modellen. CD er en del runtime orkestrering.
Hvorfor CI-servere ikke bør lave cd'er via direkte opdateringer i Kubernetes
Brug ikke en CI-server til at orkestrere direkte opdateringer til Kubernetes som et sæt CI-job. Det er det anti-mønster, vi taler om på din blog.
Lad os gå tilbage til Alice og Bob.
Hvilke problemer stod de over for? Bobs CI-server anvender ændringerne på klyngen, men hvis den går ned i processen, ved Bob ikke, hvilken tilstand klyngen er (eller burde være) i, eller hvordan den rettes. Det samme gælder i tilfælde af succes.
Lad os antage, at Bobs team byggede et nyt image og derefter patchede deres implementeringer for at implementere billedet (alt sammen fra CI-pipelinen).
Hvis billedet bygger normalt, men pipelinen fejler, bliver teamet nødt til at finde ud af:
- Er opdateringen rullet ud?
- Lancerer vi et nyt byggeri? Vil dette føre til unødvendige bivirkninger - med mulighed for at have to builds af det samme uforanderlige billede?
- Skal vi vente på den næste opdatering, før vi kører build?
- Hvad gik helt galt? Hvilke trin skal gentages (og hvilke er sikre at gentage)?
Etablering af en Git-baseret arbejdsgang garanterer ikke, at Bobs team ikke vil støde på disse problemer. De kan stadig lave en fejl med commit-push, tagget eller en anden parameter; denne tilgang er dog stadig meget tættere på en eksplicit alt-eller-intet tilgang.
For at opsummere, her er hvorfor CI-servere ikke bør håndtere CD:
- Opdateringsscripts er ikke altid deterministiske; Det er nemt at lave fejl i dem.
- CI-servere konvergerer ikke til den deklarative klyngemodel.
- Det er svært at garantere idempotens. Brugere skal forstå systemets dybe semantik.
- Det er sværere at komme sig efter en delvis fiasko.
Bemærk om Helm: Hvis du vil bruge Helm, anbefaler vi at kombinere det med en GitOps-operator som f.eks. . Dette vil bidrage til at sikre konvergens. Helm i sig selv er hverken deterministisk eller atomart.
GitOps som den bedste måde at implementere Continuous Delivery for Kubernetes
Alice og Bobs team implementerer GitOps og opdager, at det er blevet meget nemmere at arbejde med softwareprodukter, opretholde høj ydeevne og stabilitet. Lad os afslutte denne artikel med en illustration, der viser, hvordan deres nye tilgang ser ud. Husk, at vi mest taler om applikationer og tjenester, men GitOps kan bruges til at administrere en hel platform.
Driftsmodel for Kubernetes
Se på følgende diagram. Det præsenterer Git og containerbilledet som delte ressourcer for to orkestrerede livscyklusser:
- En kontinuerlig integrationspipeline, der læser og skriver filer til Git og kan opdatere et lager af containerbilleder.
- En Runtime GitOps-pipeline, der kombinerer implementering med administration og observerbarhed. Den læser og skriver filer til Git og kan downloade containerbilleder.
Hvad er de vigtigste resultater?
- Adskillelse af bekymringer: Bemærk venligst, at begge pipelines kun kan kommunikere ved at opdatere Git eller billedlageret. Med andre ord er der en firewall mellem CI og runtime-miljøet. Vi kalder det "uforanderlig firewall" (uforanderlig firewall), da alle lageropdateringer skaber nye versioner. For mere information om dette emne henvises til slides 72-87 .
- Du kan bruge enhver CI- og Git-server: GitOps fungerer med enhver komponent. Du kan fortsætte med at bruge dine foretrukne CI- og Git-servere, billedarkiver og testsuiter. Næsten alle andre Continuous Delivery-værktøjer på markedet kræver deres egen CI/Git-server eller billedlager. Dette kan blive en begrænsende faktor i udviklingen af cloud native. Med GitOps kan du bruge velkendte værktøjer.
- Events som integrationsværktøj: Så snart data i Git er opdateret, giver Weave Flux (eller Weave Cloud-operatøren) besked om runtime. Når Kubernetes accepterer et ændringssæt, opdateres Git. Dette giver en simpel integrationsmodel til at organisere arbejdsgange for GitOps, som vist nedenfor.
Konklusion
GitOps giver de stærke opdateringsgarantier, der kræves af ethvert moderne CI/CD-værktøj:
- automatisering;
- konvergens;
- idempotens;
- determinisme.
Dette er vigtigt, fordi det tilbyder en operationel model for cloud-native udviklere.
- Traditionelle værktøjer til styring og overvågning af systemer er forbundet med driftsteams, der opererer inden for en runbook (et sæt rutineprocedurer og operationer - ca. oversættelse), knyttet til en specifik implementering.
- I cloud native management er observationsværktøjer den bedste måde at måle resultaterne af implementeringer på, så udviklingsteamet kan reagere hurtigt.
Forestil dig mange klynger spredt over forskellige skyer og mange tjenester med deres egne teams og implementeringsplaner. GitOps tilbyder en skala-invariant model til at styre al denne overflod.
PS fra oversætteren
Læs også på vores blog:
- «";
- «";
- «'.
Kun registrerede brugere kan deltage i undersøgelsen. , Vær venlig.
Vidste du om GitOps, før disse to oversættelser dukkede op på Habré?
-
Ja, jeg vidste alt
-
Kun overfladisk
-
Nej
35 brugere stemte. 10 brugere undlod at stemme.
Kilde: www.habr.com