Bem. overs.: Efter den seneste offentliggørelse om pull- og push-metoder i GitOps har vi set en interesse for denne model generelt, men der har vist sig at være meget få russisktalende publikationer om emnet (der er simpelthen ingen på Habr). Derfor er vi glade for at kunne tilbyde en oversættelse af en anden artikel - selvom den er næsten et år gammel! - fra Weaveworks, hvis leder opfandt termen 'GitOps'. Teksten forklarer essensen af tilgangen og de væsentlige forskelle fra allerede eksisterende.
For et år siden offentliggjorde vi . Dengang fortalte vi, hvordan Weaveworks-teamet lancerede en SaaS, der er helt baseret på Kubernetes, og udviklede et sæt best practices for implementering, styring og overvågning i en cloud native-miljø.
Artiklen blev populær. Andre begyndte at tale om GitOps og publicere nye værktøjer til , , , , osv. På vores site dukkede der op publikationer og brugsscenarier for GitOps. Men nogle mennesker havde stadig spørgsmål. Hvordan adskiller modellen sig fra traditionel og kontinuerlig levering ()? Er det nødvendigt at bruge Kubernetes?
Snart indså vi, at der var behov for en ny beskrivelse, der tilbyder:
- Et stort antal eksempler og historier;
- En konkret definition af GitOps;
- Sammenligning med traditionel continuous delivery.
I denne artikel har vi forsøgt at dække alle disse emner. Du vil finde en opdateret introduktion til GitOps og et perspektiv fra udviklere og CI/CD. Vi fokuserer primært på Kubernetes, selvom modellen helt sikkert kan generaliseres.
Mød GitOps
Forestil dig Alice. Hun driver virksomheden Family Insurance, der tilbyder sundhedsforsikringer, bilforsikringer, ejendomsvurderinger og rejseforsikring til folk, der er for travle til selv at forstå kontraktens nuancer. Hendes forretning begyndte som et sideprojekt, da Alice arbejdede i banken som data scientist. En dag indså hun, at hun kunne bruge avancerede computeralgoritmer til mere effektivt at analysere data og sammensætte forsikringspakker. Investorer finansierede projektet, og nu genererer hendes virksomhed over 20 millioner dollars om året og vokser hastigt. I øjeblikket har hun 180 medarbejdere i forskellige stillinger. Blandt dem er et teknologiteam, der arbejder med udvikling, vedligeholdelse af hjemmesiden, databaser og analyse af kundedata. Teamet på 60 personer ledes af Bob - virksomhedens tekniske direktør.
Bobs team implementerer produktionssystemer i skyen. Deres primære applikationer kører på GKE, hvor de drager fordel af Kubernetes i Google Cloud. Derudover bruger de forskellige værktøjer til datahåndtering og analyse i deres arbejde.
Family Insurance havde ikke tænkt sig at bruge containere, men blev grebet af entusiasmen omkring Docker. Kort tid efter opdagede virksomhedens specialister, at GKE gør det nemt og enkelt at implementere klynger til test af nye funktioner. Jenkins blev tilføjet til CI, og Quay blev brugt til at organisere containerregistret, og der blev skrevet scripts til Jenkins, som push’ede nye containere og konfigurationer til GKE.
Der er gået noget tid. Alice og Bob blev skuffede over ydeevnen fra den valgte tilgang og dens indvirkning på virksomheden. Implementeringen af containere havde ikke forbedret ydeevnen så meget, som teamet havde håbet. Nogle gange svigtede deployment'ene, og det var uklart, om det var kodeændringerne, der var skyld i det. Det viste sig også at være svært at holde styr på ændringer i konfigurationerne. Ofte var de nødt til at oprette et nyt cluster og flytte applikationer dertil, da det var den nemmeste måde at rydde op i det rod, systemet var blevet til. Alice var bange for, at situationen ville forværres, efterhånden som applikationen udviklede sig (derudover var der en ny maskinlæringsprojektside under udvikling). Bob havde automatiseret en stor del af arbejdet og forstod ikke, hvorfor pipeline'en stadig var ustabil, skalerede dårligt og til tider krævede manuel indgriben.
Derefter hørte de om GitOps. Denne løsning viste sig at være præcis det, de havde brug for for at kunne komme videre med sikkerhed.
Alice og Bob havde i flere år hørt om arbejdsgange baseret på Git, DevOps og infrastruktur som kode. Det unikke ved GitOps er, at det bringer en række bedste praksisser - kategoriske og normative - til implementeringen af disse ideer i konteksten af Kubernetes. Dette emne , herunder i .
Family Insurance beslutter sig for at implementere GitOps. Nu har virksomheden en automatiseret driftsmodel, der er kompatibel med Kubernetes og kombinerer hastighed med stabilitet, idet de:
- har opdaget, at teamets produktivitet er fordoblet, og ingen bliver skør af det;
- er stoppet med at vedligeholde scripts. I stedet kan de nu fokusere på nye funktioner og forbedre ingeniørmetoderne - for eksempel ved at implementere kanariefugle-udrulninger og forbedre testningen;
- har forbedret deploymentsprocessen - nu svigter den sjældent;
- har fået muligheden for at gendanne deployments efter delvise fejlslag uden manuel indgriben;
- har fået større sikkerhed i leveringssystemer. Alice og Bob opdagede, at de kunne dele teamet op i grupper, der arbejder med mikrotjenester parallelt;fleste afde kan foretage 30-50 ændringer i projektet hver dag gennem hver gruppe og afprøve nye teknikker;
- могут вносить по 30-50 изменений в проект каждый день усилиями каждой группы и пробовать новые техники;
- let nemt tiltrække nye udviklere til projektet, som kan rulle opdateringer ud til produktionen ved hjælp af pull request'er allerede efter et par timer;
- let kan bestå revisioner i forbindelse med SOC2 (i forhold til, at tjenesteudbydere lever op til kravene om sikker datastyring; læs mere for eksempel, — red. anm.).
Hvad skete der?
GitOps er to ting:
- En driftsmodel for Kubernetes og cloud native. Den giver et sæt bedste praksisser for implementering, administration og overvågning af containeriserede klynger og applikationer. En elegant definition på fra :
- Vejen til at skabe et udviklingsorienteret miljø til administrationsformål. Vi anvender Git workflow både til drift og udvikling. Vær opmærksom på, at det ikke blot handler om Git push, men om at organisere hele sæt af CI/CD og UI/UX værktøjer.
Et par ord om Git
Hvis du ikke er bekendt med versionskontrolsystemer og Git-baserede workflows, anbefaler vi stærkt at lære dem at kende. I begyndelsen kan arbejde med grene og pull request'er virke som mørk magi, men fordelene er indsatsen værd. Her er til at starte med.
Hvordan fungerer Kubernetes
I vores historie henvendte Alice og Bob sig til GitOps, efter at de har arbejdet med Kubernetes i et stykke tid. Faktisk er GitOps nært relateret til Kubernetes - det er en driftsmodel for infrastruktur og applikationer baseret på Kubernetes.
Hvad giver Kubernetes brugerne?
Her er nogle af de vigtigste funktioner:
- I Kubernetes-modellen kan alt beskrives i deklarativ form.
- Kubernetes API-serveren accepterer denne deklaration som input og forsøger konstant at bringe klyngen i den tilstand, der er beskrevet i deklarationen.
- Deklarationerne er tilstrækkelige til at beskrive og administrere et stort udvalg af arbejdsbelastninger - "applikationer".
- Som et resultat sker ændringer i applikationen og klyngen på grund af:
- ændringer i containerbilleder;
- ændringer i den deklarative specifikation;
- fejl i miljøet - for eksempel nedbrud af containere.
Kubernetes' fantastiske evner til konvergensen
Når en administrator foretager ændringer i konfigurationen, vil Kubernetes-orchestratoren anvende dem på klyngen, indtil dens tilstand nærmer sig den nye konfiguration. Denne model fungerer for enhver Kubernetes-ressource og kan udvides ved hjælp af Custom Resource Definitions (CRDs). Derfor har Kubernetes-implementeringer følgende fantastiske egenskaber:
- Automatisering: Kubernetes-opdateringer giver en mekanisme til at automatisere ændringsanvendelsesprocessen korrekt og rettidigt.
- Konvergens: Kubernetes vil fortsætte med at forsøge opdateringer indtil succes.
- Idempotens: gentagne anvendelser af konvergensen fører til det samme resultat.
- Determinisme: med tilstrækkelige ressourcer afhænger den opdaterede clusters tilstand kun af den ønskede tilstand.
Hvordan GitOps fungerer
Vi har lært nok om Kubernetes til at forklare GitOps-principperne.
Lad os vende tilbage til Family Insurance-teams, der arbejder med mikrotjenester. Hvad skal de typisk håndtere? Se på listen nedenfor (hvis nogle punkter virker mærkelige eller ukendte — vær venlig at udsætte kritikken og hænge på). Dette er blot eksempler på arbejdsprocesser baseret på Jenkins. Der findes mange andre processer, når man arbejder med andre værktøjer.
Det vigtigste er, at vi ser, at hver opdatering ender med ændringer i konfigurationsfiler og Git-repositories. Disse ændringer i Git får 'GitOps-operatoren' til at opdatere clusteren:
1. Arbejdsproces: 'Jenkins build — master grenen».
Opgaveliste:
- Jenkins uploader taggede billeder til Quay;
- Jenkins uploader konfig og Helm-diagrammer til master-lagerets bucket;
- En cloud-funktion kopierer konfig og diagrammer fra master-lagerets bucket til Git-repositoryet master;
- GitOps-operatoren opdaterer clusteren.
2. Jenkins build — release- eller hotfix-grenen:
- Jenkins uploader ikke-taggete billeder til Quay;
- Jenkins uploader konfig og Helm-diagrammer til staging-lagerets bucket;
- En cloud-funktion kopierer konfig og diagrammer fra staging-lagerets bucket til Git-repositoryet staging;
- GitOps-operatoren opdaterer clusteren.
3. Jenkins build — develop- eller feature-grenen:
- Jenkins uploader ikke-taggete billeder til Quay;
- Jenkins uploader konfig og Helm-diagrammer til develop-lagerets bucket;
- En cloud-funktion kopierer konfig og diagrammer fra develop-lagerets bucket til Git-repositoryet develop;
- GitOps-operatoren opdaterer clusteren.
4. Tilføjelse af en ny klient:
- En manager eller administrator (LCM/ops) kalder Gradle for den indledende implementering og opsætning af netværksbelastningsafbalancere (NLB);
- LCM/ops committer ny konfig for at forberede implementeringen til opdateringer;
- GitOps-operatoren opdaterer clusteren.
Kort beskrivelse af GitOps
- Beskriv den ønskede tilstand af hele systemet ved at bruge deklarative specifikationer for hvert miljø (i vores historie definerer Bobs team hele systemkonfigurationen i Git).
- Git-repositoriet er den eneste sandhedskilde vedrørende den ønskede tilstand af hele systemet.
- Alle ændringer til den ønskede tilstand foretages gennem commits i Git.
- Alle ønskede parametre for klyngen er også observerbare i selve klyngen. Således kan vi bestemme, om de ønskede og observerede tilstande konvergerer, converge) eller divergerer, diverge) fra hinanden.
- Hvis de ønskede og observerede tilstande adskiller sig, så:
- Der findes en konvergeringsmekanisme, som før eller siden automatisk synkroniserer mål- og observerede tilstande. Inden for klyngen håndteres dette af Kubernetes.
- Processen starter straks med notifikationen «change committed».
- Efter et justerbart tidsinterval kan der sendes en notifikation «diff», hvis tilstandene adskiller sig.
- Således udløser alle commits i Git verificerbare og idempotente opdateringer i klyngen.
- Rollback er en konvergering til en tidligere ønsket tilstand.
- Konvergeringen er endelig. Tegnene på dens indtræden er:
- Ingen «diff» notifikationer i en bestemt tidsperiode.
- En «converged» notifikation (f.eks. webhook, Git writeback-hændelse).
Hvad er divergens?
Lad os gentage: alle ønskede egenskaber for klyngen skal være observerbare i selve klyngen..
Nogle eksempler på divergens:
- Ændring af konfigurationsfilen på grund af sammensmeltning af grene i Git.
- Ændring af konfigurationsfilen på grund af et commit i Git lavet af en GUI-klient.
- Flere ændringer i den ønskede tilstand på grund af PR i Git efterfulgt af bygning af et containerbillede og ændringer i konfigurationsfilen.
- Ændring af klyngens tilstand på grund af fejl, ressourcekonflikter, der fører til 'dårlig opførsel', eller blot en tilfældig afvigelse fra den oprindelige tilstand.
Hvad er konvergeringsmekanismen?
Nogle eksempler:
- For containere og klynger leverer konvergeringsmekanismen Kubernetes.
- Den samme mekanisme kan bruges til at styre applikationer og strukturer baseret på Kubernetes (f.eks. Istio og Kubeflow).
- En mekanisme til at styre arbejdsmiljøet mellem Kubernetes, billed-depot og Git leverer , som er en del af .
- For grundlæggende maskiner skal konvergensmekanismen være deklarativ og autonom. Af erfaring kan vi sige, at nærmer sig denne definition, men stadig kræver menneskelig kontrol. I denne forstand udvider GitOps traditionerne fra Infrastructure as Code.
GitOps kombinerer Git med den fremragende konvergensmekanisme i Kubernetes og tilbyder en model for drift.
GitOps giver os mulighed for at sige: kun de systemer, der kan beskrives og overvåges, er underlagt automatisering og kontrol.
GitOps er designet til hele cloud native-stakken (f.eks. Terraform osv.)
GitOps handler ikke kun om Kubernetes. Vi ønsker, at hele systemet skal styres deklarativt og bruge konvergens. Med hele systemet refererer vi til samlingen af miljøer, der arbejder med Kubernetes — for eksempel "dev cluster 1", "production" osv. Hvert miljø inkluderer maskiner, klynger, applikationer samt grænseflader til eksterne tjenester, der leverer data, overvågning osv.
Bemærk, hvor vigtigt Terraform er for bootstrapping-problematikken i dette tilfælde. Kubernetes skal være implementeret et eller andet sted, og brugen af Terraform betyder, at vi kan anvende de samme GitOps-arbejdsgange til at oprette det styrende lag, der ligger til grund for Kubernetes og applikationerne. Dette er en nyttig bedste praksis.
Der lægges stor vægt på anvendelse af GitOps-koncepter til lag over Kubernetes. Ind til videre findes der GitOps-løsninger for Istio, Helm, Ksonnet, OpenFaaS og Kubeflow, samt f.eks. 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:
- En driftmodel for Kubernetes og cloud native, som beskrevet ovenfor.
- Vejen til at organisere et udviklerfokuseret miljø til applikationsstyring.
For mange er GitOps først og fremmest en arbejdsproces baseret på Git-push. Vi kan også lide det. Men det er ikke alt: lad os nu se på CI/CD-pipelines.
GitOps sikrer kontinuerlig implementering (CD) under Kubernetes
GitOps tilbyder en mekanisme til kontinuerlig implementering, der fjerner behovet for separate "deploymentsstyringssystemer". Alt arbejdet udføres af Kubernetes.
- Opdatering af applikationen kræver en opdatering i Git. Dette er en transaktionel opdatering til den ønskede tilstand. 'Udrulningen' udføres derefter inden for klyngen af Kubernetes selv baseret på den opdaterede beskrivelse.
- På grund af den specifikke måde, Kubernetes arbejder på, er disse opdateringer konvergerende. Dette sikrer en mekanisme for kontinuerlig udrulning, hvor alle opdateringer er atomare.
- Bemærk: tilbyder en GitOps-operator, der integrerer Git og Kubernetes og muliggør CD ved at afstemme den ønskede og den aktuelle tilstand i klyngen.
Uden kubectl og scripts
Det er bedst at undgå brugen af Kubectl til at opdatere klyngen, især scripts til at gruppere kubectl-kommandoer. I stedet kan brugeren ved hjælp af en GitOps-pipeline opdatere sin Kubernetes-klynge gennem Git.
Fordelene inkluderer:
- Korrekthed. En gruppe opdateringer kan anvendes, konvergeres og endelig valideres, hvilket bringer os tættere på målet om atomar udrulning. I modsætning hertil giver brugen af scripts ingen garantier for konvergens (mere om dette nedenfor).
- Sikkerhed. Kelsey Hightower: 'Begræns adgangen til Kubernetes-klyngen til automatiseringsværktøjer og administratorer, der har til opgave at debugge eller vedligeholde den.' Se også om sikkerhed og overholdelse af tekniske krav, samt ved at stjæle legitimationsoplysninger fra et sjusket lavet Jenkins-script.
- Brugeroplevelse. Kubectl afslører mekanikken i Kubernetes' objektmodel, som er ganske kompleks. Ideelt set skal brugerne interagere med systemet på et højere abstraktionsniveau. Her vil jeg igen referere til Kelsey og anbefale at se .
Forskellen mellem CI og CD
GitOps forbedrer eksisterende CI/CD-modeller.
Moderne CI-servere fungerer som værktøjer til orkestrering. Specifikt er det værktøjer til orkestrering af CI-pipelines. De omfatter build, test, merge til trunk osv. CI-servere automatiserer administrationen af komplekse flertrins-pipelines. Der er en almindelig fristelse til at oprette et script til en række Kubernetes-opdateringer og udføre det som en del af pipeline til at push'e ændringer til klyngen. Faktisk gør mange fagfolk dette. Men det er ikke optimalt, og her er hvorfor.
CI bør bruges til at opdatere trunk, mens Kubernetes-klusteret skal ændre sig baseret på disse opdateringer for at styre CD "internt". Vi kalder dette , i modsætning til CI push-modellen. CD er en del af runtime-orkestrering.
Hvorfor CI-servere ikke bør udføre CD gennem direkte opdateringer i Kubernetes
Brug ikke CI-serveren til at orkestrere direkte opdateringer i Kubernetes som et sæt CI-opgaver. Dette er et antipattern, vi diskuterer i vores blog.
Lad os vende tilbage til Alice og Bob.
Hvilke problemer stod de overfor? Bobs CI-server anvender ændringerne til klustret, men hvis den fejler undervejs, ved Bob ikke, hvilken tilstand klustret er i (eller burde være i), eller hvordan man retter det. Det samme gælder i tilfælde af succes.
Lad os antage, at Bobs team har bygget et nyt billede og derefter patched deres deployment'er for at implementere billedet (alt dette fra CI-pipelinen).
Hvis billedet bygges korrekt, men pipelinen fejler, må teamet finde ud af:
- Blev opdateringen implementeret?
- Kører vi en ny bygning? Vil det medføre unødvendige bivirkninger — med muligheden for at få to bygninger af det samme uændrede billede?
- Skal vi vente på den næste opdatering, før vi kører bygningen?
- Hvad gik helt galt? Hvilke trin skal gentages (og hvilke kan gentages sikkert)?
At organisere en Git-baseret arbejdsmetode garanterer ikke, at Bobs team ikke vil støde på disse problemer. De kan stadig lave fejl med push af committet, med tagget eller en hvilken som helst anden parameter; dog er denne tilgang stadig meget tættere på et eksplicit alt-eller-intet.
Sammenfattende, her er hvorfor CI-servere ikke skal håndtere CD:
- Opdateringsscripts er ikke altid deterministiske; det er let at lave fejl i dem.
- CI-servere konvergerer ikke til en deklarativ model for klustret.
- Det er vanskeligt at garantere idempotens. Brugerne skal forstå den dybe semantik i systemet.
- Det er sværere at gennemføre en gendannelse efter en delvis fejl.
Bemærkning om Helm: Hvis du ønsker at bruge Helm, anbefaler vi at kombinere den med en GitOps-operator som . Dette vil hjælpe med at sikre konvergens. Helm alene er hverken deterministisk eller atomisk.
GitOps som den bedste metode til at gennemføre Continuous Delivery for Kubernetes
Alice og Bobs team implementerer GitOps og opdager, at det er blevet meget lettere at arbejde med softwareprodukter og opretholde høj ydeevne og stabilitet. Lad os afslutte denne artikel med illustrationer, der viser, hvordan deres nye tilgang ser ud. Bemærk, at vi hovedsageligt taler om applikationer og tjenester, men GitOps kan bruges til at administrere hele platformen.
Driftsmodel for Kubernetes
Se på følgende diagram. Det repræsenterer Git og containerbilledeopbevaring som fælles ressourcer for to orkestrerede livscyklusser:
- En pipeline til kontinuerlig integration, der læser og skriver filer til Git og kan opdatere containerbilledrepoet.
- Runtime GitOps pipeline, der kombinerer deployment med administration og overvågning. Den læser og skriver filer til Git og kan uploade containerbilleder.
Hvad er de vigtigste konklusioner?
- Opdeling af problemer: Bemærk, at begge pipelines kan udveksle data, alene ved at opdatere Git eller billedrepoet. Med andre ord er der en firewall mellem CI og runtime-miljøet. Vi kalder det 'immutability firewall' (immutability firewall), da alle opdateringer af repositorier skaber nye versioner. For yderligere information om emnet henvises til slides 72-87. .
- Enhver CI- og Git-server kan bruges: GitOps fungerer med enhver komponent. Du kan fortsætte med at bruge dine foretrukne CI- og Git-servere, billedeopbevaringer og testpakker. Næsten alle andre værktøjer til Continuous Delivery på markedet kræver deres egen CI/Git-server eller billedeopbevaring. Dette kan blive en begrænsende faktor i udviklingen af cloud native. I tilfældet med GitOps kan du bruge de værktøjer, du allerede kender.
- Begivenheder som integrationsværktøj: Så snart data opdateres i Git, underretter Weave Flux (eller Weave Cloud operator) runtime om dette. Hver gang Kubernetes accepterer et sæt ændringer, opdateres Git. Dette sikrer en enkel integrationsmodel til at organisere workflows for GitOps, som vist nedenfor.
Konklusion
GitOps giver væsentlige garantier for opdateringen, som ethvert moderne CI/CD-værktøj har brug for:
- automatisering;
- konvergens;
- idempotens;
- determinisme.
Dette er vigtigt, da det tilbyder en driftsmodel for udviklere inden for cloud native.
- Traditionelle værktøjer til administration og overvågning af systemer er forbundet med driftsgrupper, der arbejder inden for rammerne af et runbook. (sæt af rutineprocedurer og operationer — bemærkning fra oversætteren.), knyttet til et specifikt deployment.
- I administrationen af cloud native-systemer er overvågningsværktøjet den bedste måde at vurdere resultaterne af deployments, så udviklingsteamet kan reagere hurtigt på dem.
Forestil dig mange klynger spredt over forskellige skyer og mange tjenester med deres egne teams og deployment-planer. GitOps tilbyder en skalerbar invariant model til at styre alt dette overflod.
P.S. fra oversætteren
Læs også på vores blog:
- «»;
- «»;
- «».
Kun registrerede brugere kan deltage i undersøgelsen. , please.
Vidste du om GitOps før disse to oversættelser på Habr?
Ja, jeg vidste det.
Kun overfladisk.
Nej
35 brugere har stemt. 10 brugere har hverken stemt for eller imod.
Kilde: habr.com
