Notera. transl.: Efter en nyligen publicerad publikation om pull and push-metoder i GitOps såg vi intresse för denna modell i allmänhet, men det fanns väldigt få ryskspråkiga publikationer om detta ämne (det finns helt enkelt inga på Habré). Därför är vi glada att kunna erbjuda er uppmärksamhet en översättning av en annan artikel - om än för nästan ett år sedan! - från Weaveworks, vars chef myntade termen "GitOps." Texten förklarar kärnan i tillvägagångssättet och viktiga skillnader från befintliga.
För ett år sedan publicerade vi . Då delade vi hur Weaveworks-teamet lanserade en SaaS helt baserad på Kubernetes och utvecklade en uppsättning föreskrivande bästa praxis för att distribuera, hantera och övervaka i en molnbaserad miljö.
Artikeln visade sig vara populär. Andra människor började prata om GitOps och började publicera nya verktyg för , , , , och så vidare. Dök upp på vår hemsida publikationer och GitOps användningsfall. Men vissa har fortfarande frågor. Hur skiljer sig modellen från den traditionella? och kontinuerlig leverans ()? Är det nödvändigt att använda Kubernetes?
Vi insåg snart att det behövdes en ny beskrivning med:
- Ett stort antal exempel och berättelser;
- Specifik definition av GitOps;
- Jämförelse med traditionell kontinuerlig leverans.
I den här artikeln har vi försökt täcka alla dessa ämnen. Det ger en uppdaterad introduktion till GitOps och ett utvecklar- och CI/CD-perspektiv. Vi fokuserar i första hand på Kubernetes, även om modellen kan generaliseras.
Möt GitOps
Föreställ dig Alice. Hon driver Family Insurance, som erbjuder hälso-, bil-, hem- och reseförsäkringar till människor som är för upptagna för att själva ta reda på detaljerna i kontrakten. Hennes verksamhet började som ett sidoprojekt när Alice arbetade på en bank som datavetare. En dag insåg hon att hon kunde använda avancerade datoralgoritmer för att mer effektivt analysera data och formulera försäkringspaket. Investerare finansierade projektet och nu drar hennes företag in mer än 20 miljoner dollar om året och växer snabbt. För närvarande sysselsätter företaget 180 personer i olika befattningar. Detta inkluderar ett teknikteam som utvecklar, underhåller webbplatsen, databasen och analyserar kundbasen. Teamet på 60 personer leds av Bob, företagets tekniska direktör.
Bobs team distribuerar produktionssystem i molnet. Deras kärnapplikationer körs på GKE och drar fördel av Kubernetes på Google Cloud. Dessutom använder de olika data- och analysverktyg i sitt arbete.
Family Insurance tänkte inte använda containrar, utan fastnade i Docker-entusiasmen. Företaget upptäckte snart att GKE gjorde det enkelt att distribuera kluster för att testa nya funktioner. Jenkins för CI och Quay lades till för att organisera behållarregistret, skript skrevs för Jenkins som skickade nya behållare och konfigurationer till GKE.
Det har gått en tid. Alice och Bob var besvikna över resultatet av deras valda tillvägagångssätt och dess inverkan på verksamheten. Införandet av containrar förbättrade inte produktiviteten så mycket som teamet hade hoppats. Ibland gick distributioner sönder, och det var oklart om kodändringar var skyldiga. Det visade sig också vara svårt att spåra konfigurationsändringar. Ofta var det nödvändigt att skapa ett nytt kluster och flytta applikationer till det, eftersom detta var det enklaste sättet att eliminera den röra som systemet hade blivit. Alice var rädd att situationen skulle förvärras i takt med att applikationen utvecklades (dessutom var ett nytt projekt baserat på maskininlärning på gång). Bob hade automatiserat det mesta av arbetet och förstod inte varför pipelinen fortfarande var instabil, inte skalade bra och krävde manuellt ingripande med jämna mellanrum?
Sedan lärde de sig om GitOps. Detta beslut visade sig vara precis vad de behövde för att med tillförsikt gå vidare.
Alice och Bob har hört talas om Git, DevOps och infrastruktur som kodarbetsflöden i flera år. Det som är unikt med GitOps är att det ger en uppsättning bästa praxis – både definitiva och normativa – för att implementera dessa idéer i Kubernetes-sammanhang. Detta tema , inklusive i .
Familjeförsäkring beslutar att implementera GitOps. Företaget har nu en automatiserad driftmodell som är kompatibel med Kubernetes och skördetröskor hastighet med stabiliteteftersom de:
- upptäckte att teamets produktivitet fördubblades utan att någon blev galen;
- slutade visa skript. Istället kan de nu fokusera på nya funktioner och förbättra tekniska metoder - till exempel införa kanariefågelutrullningar och förbättra tester;
- vi har förbättrat distributionsprocessen så att den sällan går sönder;
- fick möjligheten att återställa driftsättningar efter partiella fel utan manuellt ingripande;
- köpt begagnatоStörre förtroende för leveranssystem. Alice och Bob upptäckte att de kunde dela upp teamet i mikroserviceteam som arbetar parallellt;
- kan göra 30-50 förändringar i projektet varje dag genom insatser från varje grupp och prova nya tekniker;
- det är lätt att locka nya utvecklare till projektet, som har möjlighet att rulla ut uppdateringar till produktionen med hjälp av pull-förfrågningar inom några timmar;
- klarar enkelt revision inom ramen för SOC2 (för tjänsteleverantörers överensstämmelse med krav på säker datahantering; läs mer, t.ex. - cirka. översätt.).
Vad hände?
GitOps är två saker:
- Verksamhetsmodell för Kubernetes och molnbaserad. Den tillhandahåller en uppsättning bästa praxis för att distribuera, hantera och övervaka containeriserade kluster och applikationer. Elegant definition i formen från :
- Vägen till att skapa en utvecklarcentrerad applikationshanteringsmiljö. Vi tillämpar Git-arbetsflödet för både drift och utveckling. Observera att det här inte bara handlar om Git push, utan om att organisera hela uppsättningen CI/CD och UI/UX-verktyg.
Några ord om Git
Om du inte är bekant med versionskontrollsystem och Git-baserat arbetsflöde rekommenderar vi starkt att du lär dig om dem. Att arbeta med grenar och pull-förfrågningar kan till en början verka som svart magi, men fördelarna är värda ansträngningen. Här att börja.
Hur Kubernetes fungerar
I vår berättelse vände sig Alice och Bob till GitOps efter att ha arbetat med Kubernetes ett tag. Faktum är att GitOps är nära besläktat med Kubernetes - det är en operativ modell för infrastruktur och applikationer baserade på Kubernetes.
Vad ger Kubernetes användare?
Här är några huvudfunktioner:
- I Kubernetes-modellen kan allt beskrivas i deklarativ form.
- Kubernetes API-server tar denna deklaration som indata och försöker sedan kontinuerligt föra klustret till det tillstånd som beskrivs i deklarationen.
- Deklarationer är tillräckliga för att beskriva och hantera en mängd olika arbetsbelastningar – "applikationer".
- Som ett resultat uppstår ändringar i applikationen och klustret på grund av:
- förändringar i behållarbilder;
- ändringar av den deklarativa specifikationen;
- fel i miljön - till exempel containerkraschar.
Kubernetes stora konvergensförmåga
När en administratör gör konfigurationsändringar kommer Kubernetes orkestrator att tillämpa dem på klustret så länge dess tillstånd är kommer inte i närheten av den nya konfigurationen. Den här modellen fungerar för alla Kubernetes-resurser och kan utökas med Custom Resource Definitions (CRD:er). Därför har Kubernetes-distributioner följande underbara egenskaper:
- Automation: Kubernetes-uppdateringar tillhandahåller en mekanism för att automatisera processen att tillämpa ändringar elegant och i rätt tid.
- Konvergens: Kubernetes kommer att fortsätta att försöka uppdateringar tills de lyckas.
- Idempotens: Upprepade tillämpningar av konvergens leder till samma resultat.
- Determinism: När resurserna är tillräckliga beror tillståndet för det uppdaterade klustret endast på det önskade tillståndet.
Hur GitOps fungerar
Vi har lärt oss tillräckligt om Kubernetes för att förklara hur GitOps fungerar.
Låt oss återvända till Family Insurances mikroserviceteam. Vad brukar de behöva göra? Titta på listan nedan (om något i den verkar konstigt eller obekant, vänligen vänta med att kritisera och stanna hos oss). Det här är bara exempel på Jenkins-baserade arbetsflöden. Det finns många andra processer när man arbetar med andra verktyg.
Huvudsaken är att vi ser att varje uppdatering slutar med ändringar av konfigurationsfilerna och Git-förråden. Dessa ändringar av Git gör att "GitOps-operatören" uppdaterar klustret:
1.Arbetsprocess: "Jenkins build - master gren".
Uppgiftslista:
- Jenkins skickar taggade bilder till Quay;
- Jenkins skjuter konfigurations- och roderdiagram till huvudlagringshinken;
- Molnfunktionen kopierar konfigurationen och diagrammen från huvudlagringsbucket till master Git-förvaret;
- GitOps-operatören uppdaterar klustret.
2. Jenkins build - release eller hotfix-gren:
- Jenkins skjuter otaggade bilder till Quay;
- Jenkins skjuter konfigurations- och Helm-diagram till lagringshinken för iscensättning;
- Molnfunktionen kopierar konfigurationen och diagrammen från iscensättningslagringsbucket till iscensättnings Git-förvaret;
- GitOps-operatören uppdaterar klustret.
3. Jenkins bygg - utveckla eller presentera gren:
- Jenkins skjuter otaggade bilder till Quay;
- Jenkins skjuter in config- och Helm-diagram i utvecklingslagringshinken;
- Molnfunktionen kopierar konfigurationen och diagrammen från develop storage bucket till develop Git repository;
- GitOps-operatören uppdaterar klustret.
4. Lägger till en ny klient:
- Chefen eller administratören (LCM/ops) anropar Gradle för att initialt distribuera och konfigurera nätverksbelastningsbalanserare (NLBs);
- LCM/ops begår en ny konfiguration för att förbereda distributionen för uppdateringar;
- GitOps-operatören uppdaterar klustret.
Kort beskrivning av GitOps
- Beskriv det önskade tillståndet för hela systemet med deklarativa specifikationer för varje miljö (i vår berättelse definierar Bobs team hela systemkonfigurationen i Git).
- Git-förvaret är den enda källan till sanning om det önskade tillståndet för hela systemet.
- Alla ändringar av det önskade tillståndet görs genom commits i Git.
- Alla önskade klusterparametrar är också observerbara i själva klustret. På detta sätt kan vi avgöra om de sammanfaller (konvergerar, konvergerar) eller avvika (divergera, avvika) önskade och observerade tillstånd.
- Om de önskade och observerade tillstånden skiljer sig, då:
- Det finns en konvergensmekanism som förr eller senare automatiskt synkroniserar målet och observerade tillstånd. Inuti klustret gör Kubernetes detta.
- Processen startar omedelbart med en "förändring committed"-varning.
- Efter en viss konfigurerbar tidsperiod kan en "diff"-varning skickas om tillstånden är olika.
- På så sätt orsakar alla commits i Git verifierbara och idempotenta uppdateringar till klustret.
- Återställning är konvergens till ett tidigare önskat tillstånd.
- Konvergensen är slutgiltig. Dess förekomst indikeras av:
- Inga diff-varningar under en viss tidsperiod.
- "konvergerad" varning (t.ex. webhook, Git-återskrivningshändelse).
Vad är divergens?
Låt oss upprepa det igen: alla önskade klusteregenskaper måste kunna observeras i själva klustret.
Några exempel på divergens:
- Ändring i konfigurationsfilen på grund av sammanslagna grenar i Git.
- En förändring i konfigurationsfilen på grund av en Git-commit gjord av GUI-klienten.
- Flera ändringar av det önskade tillståndet på grund av PR i Git följt av att bygga behållarbilden och konfigurationsändringar.
- En förändring i klustrets tillstånd på grund av ett fel, resurskonflikt som resulterar i "dåligt beteende", eller helt enkelt slumpmässig avvikelse från det ursprungliga tillståndet.
Vad är mekanismen för konvergens?
Några exempel:
- För behållare och kluster tillhandahålls konvergensmekanismen av Kubernetes.
- Samma mekanism kan användas för att hantera Kubernetes-baserade applikationer och design (som Istio och Kubeflow).
- En mekanism för att hantera den operativa interaktionen mellan Kubernetes, bildarkiv och Git tillhandahåller , som är en del .
- För basmaskiner måste konvergensmekanismen vara deklarativ och autonom. Av egen erfarenhet kan vi säga det närmast denna definition, men kräver fortfarande mänsklig kontroll. I denna mening utökar GitOps traditionen av infrastruktur som kod.
GitOps kombinerar Git med den utmärkta konvergensmotorn från Kubernetes för att tillhandahålla en modell för exploatering.
GitOps låter oss säga: Endast de system som kan beskrivas och observeras kan automatiseras och kontrolleras.
GitOps är avsedd för hela den inbyggda molnstacken (till exempel Terraform, etc.)
GitOps är inte bara Kubernetes. Vi vill att hela systemet ska drivas deklarativt och använda konvergens. Med hela systemet menar vi en samling av miljöer som arbetar med Kubernetes - till exempel "dev cluster 1", "produktion" etc. Varje miljö inkluderar maskiner, kluster, applikationer, samt gränssnitt för externa tjänster som tillhandahåller data, övervakning och etc.
Lägg märke till hur viktig Terraform är för bootstrapping-problemet i det här fallet. Kubernetes måste distribueras någonstans, och genom att använda Terraform kan vi tillämpa samma GitOps-arbetsflöden för att skapa kontrollskiktet som ligger till grund för Kubernetes och applikationer. Detta är en användbar bästa praxis.
Det finns ett starkt fokus på att tillämpa GitOps-koncept på lager ovanpå Kubernetes. För tillfället finns det lösningar av GitOps-typ för Istio, Helm, Ksonnet, OpenFaaS och Kubeflow, samt till exempel för Pulumi, som skapar ett lager för att utveckla applikationer för cloud native.
Kubernetes CI/CD: jämför GitOps med andra metoder
Som sagt är GitOps två saker:
- Driftsmodellen för Kubernetes och molninbyggd som beskrivs ovan.
- Vägen till en utvecklarcentrerad applikationshanteringsmiljö.
För många är GitOps i första hand ett arbetsflöde baserat på Git-push. Vi gillar honom också. Men det är inte allt: låt oss nu titta på CI/CD-pipelines.
GitOps möjliggör kontinuerlig distribution (CD) för Kubernetes
GitOps erbjuder en kontinuerlig distributionsmekanism som eliminerar behovet av separata "deployment management system." Kubernetes gör allt arbete åt dig.
- Uppdatering av applikationen kräver uppdatering i Git. Detta är en transaktionsuppdatering till önskat tillstånd. "Deployment" görs sedan inom klustret av Kubernetes själv baserat på den uppdaterade beskrivningen.
- På grund av hur Kubernetes fungerar är dessa uppdateringar konvergenta. Detta tillhandahåller en mekanism för kontinuerlig distribution där alla uppdateringar är atomära.
- Notera: erbjuder en GitOps-operatör som integrerar Git och Kubernetes och tillåter CD att utföras genom att stämma av önskat och aktuellt tillstånd för klustret.
Utan kubectl och skript
Du bör undvika att använda Kubectl för att uppdatera ditt kluster, och särskilt undvika att använda skript för att gruppera kubectl-kommandon. Istället, med GitOps pipeline, kan en användare uppdatera sitt Kubernetes-kluster via Git.
Förmånerna inkluderar:
- Höger. En grupp uppdateringar kan tillämpas, konvergeras och slutligen valideras, vilket för oss närmare målet med atomär utbyggnad. Däremot ger användning av skript ingen garanti för konvergens (mer om detta nedan).
- Безопасность. Kelsey Hightower: "Begränsa åtkomsten till ditt Kubernetes-kluster till automationsverktyg och administratörer som är ansvariga för att felsöka eller underhålla det." se även om säkerhet och överensstämmelse med tekniska specifikationer, samt genom att stjäla referenser från ett slarvigt skrivet Jenkins-manus.
- Användarupplevelse. Kubectl avslöjar mekaniken i Kubernetes-objektmodellen, som är ganska komplex. Helst bör användare interagera med systemet på en högre abstraktionsnivå. Här kommer jag återigen att referera till Kelsey och rekommendera att titta .
Skillnaden mellan CI och CD
GitOps förbättrar befintliga CI/CD-modeller.
En modern CI-server är ett orkestreringsverktyg. I synnerhet är det ett verktyg för orkestrering av CI-pipelines. Dessa inkluderar bygga, testa, sammanfoga till trunk, etc. CI-servrar automatiserar hanteringen av komplexa flerstegspipelines. En vanlig frestelse är att skripta en uppsättning Kubernetes-uppdateringar och köra den som en del av en pipeline för att driva ändringar i klustret. Det är faktiskt vad många experter gör. Detta är dock inte optimalt, och här är varför.
CI bör användas för att skicka uppdateringar till trunk, och Kubernetes-klustret bör ändra sig själv baserat på dessa uppdateringar för att hantera CD:n internt. Vi kallar det , till skillnad från CI push-modellen. CD är en del runtime orkestrering.
Varför CI-servrar inte bör göra CD-skivor via direkta uppdateringar i Kubernetes
Använd inte en CI-server för att orkestrera direkta uppdateringar av Kubernetes som en uppsättning CI-jobb. Det här är antimönstret vi pratar om på din blogg.
Låt oss gå tillbaka till Alice och Bob.
Vilka problem stod de inför? Bobs CI-server tillämpar ändringarna på klustret, men om det kraschar under processen kommer Bob inte att veta vilket tillstånd klustret är (eller bör vara) i eller hur man fixar det. Detsamma gäller vid framgång.
Låt oss anta att Bobs team byggde en ny avbildning och sedan korrigerade sina distributioner för att distribuera bilden (alla från CI-pipeline).
Om bilden byggs normalt, men pipelinen misslyckas, måste teamet ta reda på:
- Har uppdateringen rullat ut?
- Lanserar vi ett nytt bygge? Kommer detta att leda till onödiga biverkningar - med möjligheten att ha två builds av samma oföränderliga bild?
- Ska vi vänta på nästa uppdatering innan vi kör bygget?
- Exakt vad gick fel? Vilka steg måste upprepas (och vilka är säkra att upprepa)?
Att etablera ett Git-baserat arbetsflöde garanterar inte att Bobs team inte kommer att stöta på dessa problem. De kan fortfarande göra ett misstag med commit-pushen, taggen eller någon annan parameter; detta tillvägagångssätt är dock fortfarande mycket närmare en explicit allt-eller-inget-strategi.
För att sammanfatta, här är varför CI-servrar inte bör hantera CD:
- Uppdateringsskript är inte alltid deterministiska; Det är lätt att göra fel i dem.
- CI-servrar konvergerar inte till den deklarativa klustermodellen.
- Det är svårt att garantera idempotens. Användare måste förstå den djupa semantiken i systemet.
- Det är svårare att återhämta sig från ett partiellt misslyckande.
Anmärkning om Helm: Om du vill använda Helm rekommenderar vi att du kombinerar det med en GitOps-operatör som t.ex. . Detta kommer att bidra till att säkerställa konvergens. Helm i sig är varken deterministiskt eller atomärt.
GitOps som det bästa sättet att implementera kontinuerlig leverans för Kubernetes
Alice och Bobs team implementerar GitOps och upptäcker att det har blivit mycket lättare att arbeta med mjukvaruprodukter, bibehålla hög prestanda och stabilitet. Låt oss avsluta den här artikeln med en illustration som visar hur deras nya tillvägagångssätt ser ut. Tänk på att vi mest pratar om applikationer och tjänster, men GitOps kan användas för att hantera en hel plattform.
Driftsmodell för Kubernetes
Titta på följande diagram. Den presenterar Git och behållarbildförrådet som delade resurser för två orkestrerade livscykler:
- En kontinuerlig integrationspipeline som läser och skriver filer till Git och kan uppdatera ett arkiv med behållarbilder.
- En Runtime GitOps-pipeline som kombinerar driftsättning med hantering och observerbarhet. Den läser och skriver filer till Git och kan ladda ner behållarbilder.
Vilka är de viktigaste resultaten?
- Dela upp problemen: Observera att båda pipelines endast kan kommunicera genom att uppdatera Git eller bildarkivet. Det finns med andra ord en brandvägg mellan CI och runtime-miljön. Vi kallar det "oföränderlighetsbrandväggen" (oföränderlighet brandvägg), eftersom alla förvarsuppdateringar skapar nya versioner. För mer information om detta ämne, se bild 72-87 .
- Du kan använda vilken CI- och Git-server som helst: GitOps fungerar med vilken komponent som helst. Du kan fortsätta att använda dina favorit-CI- och Git-servrar, bildarkiv och testsviter. Nästan alla andra Continuous Delivery-verktyg på marknaden kräver sin egen CI/Git-server eller bildarkiv. Detta kan bli en begränsande faktor i utvecklingen av cloud native. Med GitOps kan du använda välbekanta verktyg.
- Evenemang som ett integrationsverktyg: Så snart data i Git uppdateras, meddelar Weave Flux (eller Weave Cloud-operatören) körtid. Närhelst Kubernetes accepterar en ändringsuppsättning uppdateras Git. Detta ger en enkel integrationsmodell för att organisera arbetsflöden för GitOps, som visas nedan.
Slutsats
GitOps ger de starka uppdateringsgarantier som krävs av alla moderna CI/CD-verktyg:
- automatisering;
- konvergens;
- idempotens;
- determinism.
Detta är viktigt eftersom det erbjuder en operativ modell för molnbaserade utvecklare.
- Traditionella verktyg för att hantera och övervaka system är associerade med operationsteam som arbetar inom en runbook (en uppsättning rutinprocedurer och operationer - ca. översättning), knuten till en specifik distribution.
- I molnbaserad hantering är observerbarhetsverktyg det bästa sättet att mäta resultaten av implementeringar så att utvecklingsteamet kan reagera snabbt.
Föreställ dig många kluster utspridda över olika moln och många tjänster med sina egna team och distributionsplaner. GitOps erbjuder en skalinvariant modell för att hantera allt detta överflöd.
PS från översättaren
Läs även på vår blogg:
- «";
- «";
- «".
Endast registrerade användare kan delta i undersökningen. , Snälla du.
Visste du om GitOps innan dessa två översättningar dök upp på Habré?
-
Ja, jag visste allt
-
Endast ytligt
-
Ingen
35 användare röstade. 10 användare avstod från att rösta.
Källa: will.com