Vad är GitOps?

Obs. övers.: Efter den senaste publiceringen av material om pull- och push-metoder i GitOps har vi sett ett intresse för denna modell generellt, men det fanns mycket få publikationer om detta på ryska (det finns helt enkelt inga på Habr). Därför är vi glada att erbjuda er översättningen av en annan artikel - även om den har nästan ett år på nacken! - från företaget Weaveworks, vars chef myntade termen "GitOps". Texten förklarar kärnan i tillvägagångssättet och de viktiga skillnaderna från befintliga modeller.

För ett år sedan publicerade vi en introduktion till GitOps. Då berättade vi hur teamet på Weaveworks lanserade en SaaS helt baserad på Kubernetes och utvecklade en uppsättning föreskrivande bästa praxis för distribution, hantering och övervakning i en cloud native-miljö.

Artikeln blev populär. Andra började prata om GitOps, publicera nya verktyg för git push, utveckling, hemligheter, funktioner, kontinuerlig integration och så vidare. På vår webbplats dök det upp stort antal publikationer och användningsfall för GitOps. Men vissa människor hade fortfarande frågor. Hur skiljer sig modellen från traditionell infrastructure as code och kontinuerlig leverans (continuous delivery)? Måste man använda Kubernetes?

Snart insåg vi att det behövdes en ny beskrivning som erbjuder:

1. Ett stort antal exempel och historier;
2. En konkret definition av GitOps;
3. En jämförelse med traditionell continuous delivery.

I denna artikel har vi försökt att täcka alla dessa ämnen. I den kommer du att hitta en uppdaterad introduktion till GitOps och en synvinkel från utvecklare och CI/CD. Vi fokuserar främst på Kubernetes, även om modellen kan generaliseras.

Låt oss presentera: GitOps

Föreställ dig Alice. Hon driver företaget Family Insurance, som erbjuder försäkringspolicer för hälsa, bilar, fastigheter och reseförsäkring till personer som är för upptagna för att navigera i kontraktens detaljer själva. Hennes verksamhet började som ett sidoprojekt när Alice arbetade på en bank som data scientist. En dag insåg hon att hon kunde använda avancerade datoralgoritmer för att effektivare analysera data och skapa försäkringspaket. Investerare finansierade projektet, och nu genererar hennes företag över 20 miljoner dollar om året och växer snabbt. För närvarande arbetar 180 personer i hennes företag på olika positioner. Bland dem finns ett teknisk team som ansvarar för utveckling, underhåll av webbplatsen, databasen och analys av kundbasen. Teamet på 60 personer leds av Bob - företagets tekniska direktör.

Bobs team implementerar produktionssystem i molnet. Deras huvudsakliga applikationer körs på GKE, vilket utnyttjar Kubernetes för Google Cloud. Dessutom använder de olika verktyg för datahantering och analys i sitt arbete.

Family Insurance hade inte tänkt att använda containrar, men blev smittade av entusiasmen för Docker. Snart upptäckte företagets specialister att GKE gör det enkelt och sömlöst att distribuera kluster för test av nya funktioner. Jenkins lades till för CI och Quay för att organisera en containerregister, och skript skrevs för Jenkins som pushade nya containrar och konfigurationer till GKE.

En tid har gått. Alice och Bob blev besvikna över prestandan hos den valda metoden och dess påverkan på affärerna. Implementeringen av containrar hade inte ökat prestandan så mycket som teamet hade hoppats. Ibland kraschade deploymentar, och det var oklart om kodändringar låg bakom. Det blev också svårt att spåra ändringar i konfigurationerna. De tvingades ofta skapa en ny kluster och flytta appar dit, eftersom det var det enklaste sättet att rensa upp den röra som systemet hade blivit. Alice fruktade att situationen skulle försämras i takt med att applikationen utvecklades (dessutom var ett nytt projekt baserat på maskininlärning på väg att starta). Bob hade automatiserat en stor del av arbetet och förstod inte varför pipelinen fortfarande var instabil, hade dålig skalbarhet och ibland krävde manuellt ingripande.

Sedan fick de höra talas om GitOps. Denna lösning visade sig vara precis vad de behövde för att röra sig framåt med självförtroende.

Alice och Bob hade i flera år hört talas om arbetsflöden baserade på Git, DevOps och infrastructure as code. Det unika med GitOps är att det inför en rad bästa metoder - kategoriska och normativa - för att implementera dessa idéer i kontexten av Kubernetes. Ämnet har tagits upp flera gånger, inklusive i Weaveworks blog.

Family Insurance beslutar att implementera GitOps. Nu har företaget en automatiserad driftsmodell som är kompatibel med Kubernetes och förenar hastighet med stabilitet, eftersom de:

• upptäckte att teamets produktivitet fördubblades utan att någon blev galen;
• slutade hantera skript. Istället kan de nu fokusera på nya funktioner och förbättra ingenjörsmetoder - till exempel implementera canary deployments och förbättra testningen;
• förbättrade deploymentsprocessen - den kraschar nu sällan;
• fick möjlighet att återställa deploymentar efter delvisa misslyckanden utan manuellt ingripande;
• fick större trygghet i leveranssystemen. Alice och Bob upptäckte att de kunde dela teamet i grupper som arbetade med mikrotjänster parallellt;bästa resultatet (subjektiv åsikt).kan göra 30-50 ändringar i projektet varje dag genom varje grupp och prova nya tekniker.
• kan göra 30-50 ändringar i projektet varje dag med hjälp av varje grupp och prova nya tekniker;
• det är lätt att attrahera nya utvecklare till projektet, som har möjlighet att rulla ut uppdateringar i produktionen via pull requests redan inom några timmar;
• genomgår lätt en granskning inom ramverket för SOC2 (för att säkerställa att tjänsteleverantörer uppfyller kraven för säker datastyrning; läs mer, till exempel, här — anm. red.).

Vad hände?

GitOps är två saker:

1. En driftsättningsmodell för Kubernetes och cloud native. Den erbjuder en uppsättning bästa praxis för driftsättning, hantering och övervakning av kluster och applikationer som är paketerade i containrar. En elegant definition i form av en enda slide från Luis Faceira:
2. Vägen till att skapa en utvecklarorienterad miljö för applikationshantering. Vi tillämpar Git-arbetsflödet både för drift och utveckling. Observera att det inte bara handlar om Git push, utan om att organisera hela uppsättningen av CI/CD och UI/UX-verktyg.

Ett par ord om Git

Om du inte är bekant med versionsstyrningssystem och Git-baserade arbetsflöden, rekommenderar vi starkt att du studerar dem. Inledningsvis kan det verka som svart magi att arbeta med grenar och pull requests, men fördelarna är värda den ansträngning som krävs. Här är bra artikel för att börja.

Hur Kubernetes fungerar

I vår berättelse vänder sig Alice och Bob till GitOps efter att ha arbetat ett tag med Kubernetes. Faktum är att GitOps är nära kopplat till Kubernetes — det är en driftsättningsmodell för infrastruktur och applikationer som är baserade på Kubernetes.

Vad ger Kubernetes användare?

Här är några av de grundläggande funktionerna:

1. I Kubernetes-modellen kan allt beskrivas i deklarativ form.
2. Kubernetes API-server tar emot sådana deklarationer som indata och försöker kontinuerligt att få klustret att matcha det tillstånd som beskrivs i deklarationen.
3. Deklarationer är tillräckliga för att beskriva och hantera ett brett spektrum av arbetsbelastningar — "applikationer".
4. Som ett resultat sker förändringar i applikationen och klustret på grund av:
   • ändringar i containerbilder;
   • ändringar i den deklarativa specifikationen;
   • fel i miljön — till exempel, kraschade containrar.

Kubernetes utmärkta konvergensegenskaper

När en administratör gör ändringar i konfigurationen kommer Kubernetes-orkestratorn att tillämpa dem på klustret tills dess tillstånd nära nya konfigurationen. Den här modellen fungerar för alla Kubernetes-resurser och kan utökas med Custom Resource Definitions (CRDs). Därför har Kubernetes-distributioner följande fantastiska egenskaper:

• Automatisering: Kubernetes-uppdateringar tillhandahåller en mekanism för att automatisera processen för att tillämpa ändringar på ett korrekt och tidsenligt sätt.
• Konvergens: Kubernetes kommer att fortsätta försöka uppdateringar tills det lyckas.
• Idempotens: upprepade tillämpningar av konvergens ger samma resultat.
• Determinism: med tillräckliga resurser beror tillståndet för den 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 principerna bakom GitOps.

Låt oss återvända till Family Insurance-team som arbetar med mikrotjänster. Vad brukar de vanligtvis syssla med? Titta på listan nedan (om några punkter verkar märkliga eller okända — var vänlig vänta med kritiken och stanna kvar hos oss). Detta är bara exempel på arbetsflöden baserade på Jenkins. Det finns också många andra processer när man arbetar med andra verktyg.

Det viktigaste är att vi ser att varje uppdatering slutar med förändringar i konfigurationsfiler och Git-repositorier. Dessa förändringar i Git leder till att 'GitOps-operatören' uppdaterar klustret:

1. Arbetsflöde: 'Jenkins-bygge — master-gren».
Att göra-lista:

• Jenkins push'ar taggade bilder till Quay;
• Jenkins push'ar konfig och Helm-diagram till master-lagringsbunken;
• Molnfunktionen kopierar konfig och diagram från master-lagringsbunken till Git-repositoriet master;
• GitOps-operatören uppdaterar klustret.

2. Jenkins-bygge — release- eller hotfix-gren:

• Jenkins push'ar otaggade bilder till Quay;
• Jenkins push'ar konfig och Helm-diagram till staging-lagringsbunken;
• Molnfunktionen kopierar konfig och diagram från staging-lagringsbunken till Git-repositoriet staging;
• GitOps-operatören uppdaterar klustret.

3. Jenkins-bygge — develop- eller feature-gren:

• Jenkins push'ar otaggade bilder till Quay;
• Jenkins push'ar konfig och Helm-diagram till develop-lagringsbunken;
• Molnfunktionen kopierar konfig och diagram från develop-lagringsbunken till Git-repositoriet develop;
• GitOps-operatören uppdaterar klustret.

4. Lägg till en ny klient:

• Managern eller administratören (LCM/ops) anropar Gradle för den initiala distributionen och konfigurationen av nätverkslastbalanserare (NLB);
• LCM/ops committar ny konfig för att förbereda distributionen för uppdateringar;
• GitOps-operatören uppdaterar klustret.

Kort beskrivning av GitOps

1. Beskriv det önskade tillståndet för hela systemet med hjälp av deklarativa specifikationer för varje miljö (i vår historia definierar Bob-teamet hela systemkonfigurationen i Git).
   • Git-repositoriet är den enda sanningskällan när det gäller det önskade tillståndet för hela systemet.
   • Alla ändringar till det önskade tillståndet görs genom commits i Git.
   • Alla önskade parametrar för klustret är också observerbara i klustret självt. På så sätt kan vi avgöra om (konvergerar, — körning av den testade playbooken,) eller om de skiljer sig (divergerar, diverge) det önskade och observerade tillståndet.
2. Om det önskade och observerade tillståndet skiljer sig åt då:
   • Det finns en konvergensmekanism som förr eller senare automatiskt synkroniserar det målade och observerade tillståndet. Inom klustret hanteras detta av Kubernetes.
   • Processen startar omedelbart med meddelandet "change committed".
   • Efter en viss konfigurerbar tidsperiod kan ett meddelande "diff" skickas om tillstånden skiljer sig åt.
3. Således orsakar alla commits i Git verifierbara och idempotenta uppdateringar i klustret.
   • Rollback är en konvergens till ett tidigare önskat tillstånd.
4. Konvergens är slutgiltig. Tecken på att den har inträffat inkluderar:
   • Ingen "diff"-meddelanden under en viss tidsperiod.
   • Ett "converged"-meddelande (t.ex. webhook, Git writeback-händelse).

Vad är divergens?

Vi upprepar: alla önskade egenskaper för klustret måste vara observerbara i klustret självt..

Några exempel på divergens:

• Ändringar i konfigurationsfilen på grund av sammanslagning av grenar i Git.
• Ändring i konfigurationsfilen på grund av en commit i Git som gjorts av en GUI-klient.
• Flera ändringar i önskat tillstånd på grund av PR i Git följt av byggande av containerbild och ändringar i konfigurationen.
• Ändring av klustrets tillstånd på grund av ett fel, resurskonflikt som leder till "dåligt beteende", eller helt enkelt en slumpmässig avvikelse från det ursprungliga tillståndet.

Vad är en konvergensmekanism?

Några exempel:

• För containrar och kluster tillhandahåller konvergensmekanismen Kubernetes.
• Samma mekanism kan användas för att hantera applikationer och konstruktioner baserade på Kubernetes (t.ex. Istio och Kubeflow).
• En mekanism för att hantera arbetssamarbetet mellan Kubernetes, bildförråd och Git ger GitOps-operatören Weave Flux, som är en del av Weave Cloud.
• För grundmaskiner måste konvergensmekanismen vara deklarativ och autonom. Utifrån vår erfarenhet kan vi säga att Terraform den ligger närmast denna definition, men kräver ändå mänsklig kontroll. I detta avseende utvidgar GitOps traditionerna kring Infrastructure as Code.

GitOps kombinerar Git med den utmärkta konvergensmekanismen i Kubernetes och erbjuder en modell för drift.

GitOps tillåter oss att påstå: bara de system som kan beskrivas och observeras är föremål för automatisering och kontroll.

GitOps är avsett för hela cloud native-stacken (t.ex. Terraform osv.)

GitOps handlar inte bara om Kubernetes. Vi vill att hela systemet ska styras deklarativt och använda konvergens. Med hela systemet menar vi en uppsättning miljöer som arbetar med Kubernetes – till exempel 'dev cluster 1', 'produktion' osv. I varje miljö ingår maskiner, kluster, applikationer samt gränssnitt för externa tjänster som tillhandahåller data, övervakning etc.

Observera hur viktigt Terraform är för problematiken kring bootstrapping. Kubernetes måste vara distribuerat någonstans, och användningen av Terraform innebär att vi kan tillämpa samma arbetsflöden GitOps för att skapa det styrskikt som ligger till grund för Kubernetes och applikationerna. Det är en användbar bästa praxis.

Stort fokus läggs på tillämpningen av GitOps-koncepten på lagren över Kubernetes. För närvarande finns det GitOps-lösningar för Istio, Helm, Ksonnet, OpenFaaS och Kubeflow, samt t.ex. för Pulumi, som skapar ett lager för utveckling av applikationer under cloud native.

Kubernetes CI/CD: Jämförelse mellan GitOps och andra metoder

Som nämnts är GitOps två saker:

1. En driftsmodell för Kubernetes och cloud native, som beskrivits ovan.
2. Vägen till att organisera en utvecklarorienterad miljö för att hantera applikationer.

För många är GitOps först och främst en arbetsprocess baserad på Git pushar. Vi gillar det också. Men det är inte allt: låt oss nu titta på CI/CD-pipelines.

GitOps säkerställer kontinuerlig distribution (CD) för Kubernetes.

GitOps erbjuder en mekanism för kontinuerlig distribution, vilket eliminerar behovet av separata 'distributionshanteringssystem'. Allt arbete görs av Kubernetes.

• Uppdatering av applikationen kräver en uppdatering i Git. Detta är en transaktionell uppdatering till det önskade tillståndet. "Distribution" utförs sedan inom klustret av Kubernetes baserat på den uppdaterade beskrivningen.
• På grund av Kubernetes specifika arbetsmetod är dessa uppdateringar konvergerande. Detta säkerställer en mekanism för kontinuerlig distribution där alla uppdateringar är atomära.
• Anmärkning: Weave Cloud erbjuder en GitOps-operator som integrerar Git och Kubernetes och möjliggör CD genom att samordna det önskade och aktuella tillståndet för klustret.

Utan kubectl och skript

Det är bäst att undvika att använda kubectl för att uppdatera klustret, särskilt skript för att gruppera kubectl-kommandon. Istället kan användaren uppdatera sitt Kubernetes-kluster via Git med hjälp av en GitOps-pipeline.

Fördelarna inkluderar:

1. Korrekthet. En grupp uppdateringar kan tillämpas, konvergera och slutligen valideras, vilket för oss närmare målet med atomär distribution. Å andra sidan ger användning av skript inga garantier för konvergens (mer om detta nedan).
2. Säkerhet. Citerar Kelsey Hightower: "Begränsa åtkomsten till Kubernetes-klustret till automatiseringsverktyg och administratörer vars uppgift är att underhålla eller felsöka det." Se också min publikations om säkerhet och efterlevnad av tekniska krav samt artikeln om Homebrew-hack genom att stjäla inloggningsuppgifter från ett slarvigt skrivet Jenkins-skript.
3. Användarupplevelse. Kubectl blottar mekaniken i Kubernetes objektmodell, vilken är ganska komplex. Idealiskt sett bör användare interagera med systemet på en högre abstraktionsnivå. Här återknyter jag till Kelsey och rekommenderar att titta på denna sammanfattning.

Skillnaden mellan CI och CD

GitOps förbättrar befintliga CI/CD-modeller.

Moderna CI-servrar är verktyg för orkestrering. Specifikt är det ett verktyg för att orkestrera CI-pipelines. De inkluderar bygg, testning, sammanslagning till huvudgrenen etc. CI-servrar automatiserar hanteringen av komplexa flerstegs-pipelines. En vanlig frestelse är att skapa ett skript för en uppsättning Kubernetes-uppdateringar och köra det som en del av pipelinen för att trycka förändringar till klustret. Verkligen gör många specialister så. Men detta är suboptimalt, och här är varför.

CI bör användas för att göra uppdateringar i trunk, och Kubernetes-klustret bör ändra sig baserat på dessa uppdateringar för att hantera CD "internt". Vi kallar detta en pull-modell för CD, till skillnad från CI push-modellen. CD är en del av runtime-orchestration.

Varför CI-servrar inte bör utföra CD genom direkta uppdateringar i Kubernetes

Använd inte CI-servern för att orkestrera direkta uppdateringar i Kubernetes som ett set av CI-jobb. Det är ett anti-mönster som vi redan har diskuterat i vår blogg.

Låt oss återvända till Alice och Bob.

Vilka problem stötte de på? Bobs CI-server tillämpar ändringar på klustret, men om den kraschar under processen kommer Bob inte att veta vilket tillstånd klustret är i (eller ska vara i) och hur det ska fixas. Detsamma gäller om det går bra.

Anta att Bobs team byggde en ny bild och sedan patchade sina deployment för att distribuera bilden (allt detta från CI-pipelinen).

Om bilden byggs korrekt men pipelinen kraschar måste teamet ta reda på:

• Distribuerades uppdateringen?
• Kör vi en ny byggnad? Kommer detta att leda till oönskade bieffekter - med risken att få två byggnader av samma oförändrade bild?
• Ska vi vänta på nästa uppdatering innan vi kör byggnaden?
• Vad gick egentligen fel? Vilka steg behöver upprepas (och vilka kan upprepas säkert)?

Att organisera en Git-baserad arbetsprocess garanterar inte att Bobs team inte upplever dessa problem. De kan fortfarande göra misstag med push av commit, med taggen eller något annat parameter; men denna metod är ändå mycket närmare en tydlig all-eller-inget.

Sammanfattningsvis, här är varför CI-servrar inte bör syssla med CD:

• Uppdateringsskripten är inte alltid deterministiska; det är lätt att göra misstag.
• CI-servrar konvergerar inte till en deklarativ modell av klustret.
• 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 efter en partiell fel.

Obs om Helm: om du vill använda Helm rekommenderar vi att kombinera det med en GitOps-operator, som Flux-Helm. Detta hjälper till att säkerställa konvergens. Helm i sig är varken deterministiskt eller atomärt.

GitOps som det bästa sättet att genomföra Continuous Delivery för Kubernetes

Alices och Bobs team implementerar GitOps och upptäcker att det blivit mycket enklare att arbeta med programvaruprodukter, upprätthålla hög prestanda och stabilitet. Låt oss avsluta denna artikel med illustrationer som visar hur deras nya tillvägagångssätt ser ut. Observera att vi främst pratar om applikationer och tjänster, men GitOps kan användas för att hantera hela plattformen.

Driftsmodell för Kubernetes

Titta på diagrammet nedan. Det representerar Git och en containerbilds lagring som gemensamma resurser för två orkestrerade livscykler:

• En pipeline för kontinuerlig integration som läser och skriver filer till Git och kan uppdatera containerbildens repository.
• En Runtime GitOps-pipeline som kombinerar distribution med hantering och övervakning. Den läser och skriver filer till Git och kan ladda upp containerbilder.

Vad är de viktigaste slutsatserna?

1. Åtskillnad av problem: Observera att båda pipelinerna kan utbyta data genom att bara uppdatera Git eller bildrepositoryt. Med andra ord, det finns en brandvägg mellan CI och runtime-miljön. Vi kallar det "immutathetsbrandväggen" (immutability firewall), eftersom alla uppdateringar av repositoryn skapar nya versioner. För mer information om detta ämne, vänligen se sidorna 72-87. denna presentation..
2. Valfri CI- och Git-server kan användas: GitOps fungerar med alla komponenter. Du kan fortsätta använda dina favorit CI- och Git-servrar, bildrepositories och testuppsättningar. Nästan alla andra verktyg för Continuous Delivery på marknaden kräver en egen CI-/Git-server eller bildrepository. Detta kan bli en begränsning i utvecklingen av cloud native. I fallet GitOps kan du använda välbekanta verktyg.
3. Händelser som integrationsverktyg: När data i Git uppdateras, meddelar Weave Flux (eller Weave Cloud-operatören) runtime om detta. Varje gång Kubernetes tar emot en uppsättning ändringar, uppdateras Git. Detta ger en enkel integrationsmodell för att organisera arbetsflöden för GitOps, som visas nedan.

Slutsats

GitOps ger viktiga garantier för uppdateringar som varje modern CI/CD-verktyg behöver:

• automatisering;
• konvergens;
• idempotens;
• determinism.

Det är viktigt eftersom det erbjuder en driftsmodell för utvecklare inom cloud native.

• Traditionella verktyg för systemhantering och övervakning är kopplade till driftteam som arbetar inom ramen för runbook. (ett set av rutinprocedurer och operationer — anm. övers.), kopplad till en specifik deployment.
• Inom hantering av cloud native-system är övervakningsverktygen det bästa sättet att utvärdera resultatet av deployment, så att utvecklarteamet kan reagera snabbt.

Föreställ dig många kluster spridda över olika moln och många tjänster med sina egna team och deploymentplaner. GitOps erbjuder en skalenlig och oförändrad modell för att hantera denna överflöd.

P.S. från översättaren

Läs även i vår blogg:

• «GitOps: Jämförelse mellan Pull och Push-metoder»;
• «Vi presenterar biblioteket kubedog för att övervaka Kubernetes-resurser»;
• «Utökar och kompletterar Kubernetes (översikt och videoföreläsning)».

Endast registrerade användare kan delta i omröstningen. Logga in, tack.

Visste du om GitOps innan dessa två översättningar på Habré?

• Ja, jag visste det.

• Bara ytligt.

• Ingen

35 användare röstade. 10 användare avstod.

Källa: habr.com