GitOps: Jämförelse mellan Pull och Push-metoder

Obs. övers.: Inom Kubernetes-samhället vinner en trend som kallas GitOps tydlig popularitet, vilket vi personligen har bevittnat, genom att besöka KubeCon Europe 2019. Denna term skapades relativt nyligen av chefen för Weaveworks – Alexis Richardson – och betyder tillämpningen av verktyg som utvecklare är vana vid (främst Git, vilket också ger namnet) för att lösa driftsättningsproblem. Specifikt handlar det om driftsättningen av Kubernetes genom att lagra dess konfigurationer i Git och automatiskt tillämpa ändringar i klustret. Om två tillvägagångssätt för denna driftsättning berättar Matthias Jg i denna artikel.

Förra året (egentligen skedde detta formellt i augusti 2017 – anm. övers.) introducerades en ny metod för driftsättning av applikationer i Kubernetes. Den kallas GitOps och grundar sig på en grundläggande uppfattning om att versionshantering av deployment genomförs i en säker miljö av Git-repositorier.

Huvudfördelarna med denna metod är följande:

1. Versionshantering av deployments och ändringshistorik. Tillståndet för hela klustret lagras i Git-repositoriet, och deployments uppdateras endast genom commits. Dessutom kan alla ändringar spåras via commit-historiken.
2. Återställningar med hjälp av vanliga Git-kommandon. En enkel git reset möjliggör att återställa ändringar i deployments; tidigare tillstånd finns alltid tillgängliga.
3. Färdigt åtkomstkontroll. Vanligtvis innehåller Git-systemet många konfidentiella uppgifter, så de flesta företag lägger stor vikt vid dess skydd. Därför sträcker sig detta skydd också till operationer med deployments.
4. Policies för driftsättningar. De flesta Git-system stöder från början policies för olika grenar – till exempel kan endast pull requests uppdatera master, och ändringar måste kontrolleras och godkännas av en annan teammedlem. Precis som med åtkomstkontroll tillämpas samma policies på uppdateringar av deployments.

Som ni ser har GitOps-metoden många fördelar. Under det senaste året har två tillvägagångssätt fått särskild popularitet. Det ena baseras på push, det andra – på pull. Innan vi diskuterar dem, låt oss först se hur typiska Kubernetes-deployments ser ut.

Metoder för driftsättning

Under de senaste åren har olika metoder och verktyg för driftsättningar blivit etablerade i Kubernetes:

1. Baserat på ursprungliga mallar Kubernetes/KustomizeDet här är det enklaste sättet att distribuera applikationer i Kubernetes. Utvecklaren skapar grundläggande YAML-filer och tillämpar dem. För att undvika att ständigt skriva om samma mallar, utvecklades Kustomize (som omvandlar Kubernetes-mallar till moduler). Obs. övers.: Kustomize har integrerats i kubectl med utgåvan av Kubernetes 1.14.
2. Helm Charts. Helm Charts möjliggör skapande av uppsättningar av mallar, init-containrar, sidecars, och så vidare, som tillämpas för distribution av applikationer med mer flexibla anpassningsmöjligheter än i mallbaserat tillvägagångssätt. Grundprincipen i denna metod är mallade YAML-filer. Helm fyller i dem med olika parametrar och skickar dem sedan till Tiller — klusterkomponenten som distribuerar dem i klustret och möjliggör uppdateringar och bakåtkopplingar. Det viktiga är att Helm i grunden bara infogar de nödvändiga värdena i mallarna och tillämpar dem på samma sätt som i det traditionella tillvägagångssättet. (mer om hur detta fungerar och hur man kan använda det, läs i vår artikel om Helm — anm. red.). Det finns en stor variation av färdiga Helm-chartar som täcker ett brett spektrum av uppgifter.
3. Alternativa verktyg. Det finns många alternativa verktyg. Gemensamt för dem alla är att de omvandlar vissa mallfiler till begripbara Kubernetes YAML-filer och tillämpar dem.

I vårt arbete använder vi ständigt Helm-charts för viktiga verktyg (eftersom mycket redan är klart, vilket förenklar livet) och "rena" Kubernetes YAML-filer för att distribuera egna applikationer.

Pull & Push

I ett av sina senaste blogginlägg presenterade jag verktyget Weave Flux, som gör det möjligt att commita mallar till Git-repo och uppdatera distributionen efter varje commit eller push av containern. Min erfarenhet visar att detta verktyg är ett av de viktigaste för att främja pull-ansatsen, så jag kommer ofta att hänvisa till det. Om du vill veta mer om hur du använder det, här är en länk till artikeln.

NB! Alla fördelar med att använda GitOps kvarstår för båda tillvägagångssätena.

Pull-baserat tillvägagångssätt

I grunden för pull-metoden ligger det faktum att alla ändringar tillämpas inifrån klustret. Inuti klustret finns en operator som regelbundet kontrollerar de relaterade Git-repositorierna och Docker-registret. Om det sker några ändringar uppdateras klustrets tillstånd inifrån. Det anses vanligtvis att en sådan process är ganska säker, eftersom inga externa klienter har administratörsrättigheter till klustret.

Fördelar:

1. Ingen extern klient har rättigheter att göra ändringar i klustret, alla uppdateringar tillämpas inifrån.
2. Vissa verktyg gör det också möjligt att synkronisera uppdateringar av Helm-diagram och knyta dem till klustret.
3. Docker-registret kan skannas efter nya versioner. Om en ny bild dyker upp, uppdateras Git-repositoriet och distributionen till den nya versionen.
4. Pull-verktyg kan distribueras över olika namnrymder med olika Git-repositorier och åtkomsträttigheter. Detta gör det möjligt att tillämpa en fleranvändarmodell. Till exempel kan team A använda namnrymd A, team B namnrymd B, och teamet som hanterar infrastrukturen kan använda den globala namnrymden.
5. I allmänhet är verktygen ganska lätta.
6. I kombination med verktyg som operatorn Bitnami Sealed Secrets, kan hemligheter lagras krypterat i Git-repositoriet och hämtas inuti klustret.
7. Det saknas kopplingar till CD-pipelines, eftersom distributionerna sker inuti klustret.

Nackdelar:

1. Att hantera hemligheter för distributioner från Helm-diagram är svårare än vanliga, eftersom de först måste genereras som till exempel sealed secrets, sedan avkrypteras av den interna operatören och först därefter blir de tillgängliga för pull-verktyget. Efter det kan man köra en release i Helm med värden i redan distribuerade hemligheter. Det enklaste sättet är att skapa en hemlighet med alla Helm-värden som används för distributionen, avkryptera den och göra en commit i Git.
2. När du använder pull-metoden är du bunden till verktyg som arbetar med pull. Detta begränsar möjligheten att anpassa deploymentsprocessen i klustret. Till exempel kompliceras arbetet med Kustomize av det faktum att det måste utföras innan de slutgiltiga mallarna går till Git. Jag säger inte att det är omöjligt att använda separata verktyg, men de är svårare att integrera i deploymentsprocessen.

Push-baserad metod

I push-metoden initierar ett externt system (vanligtvis CD-pipelines) deployment i klustret efter en commit till Git-repositoriet eller vid framgångsrik slutförande av föregående CI-pipeline. I denna metod har systemet åtkomst till klustret.

Fördelar:

1. Säkerheten bestäms av Git-repositoriet och byggpipen.
2. Det är enklare att distribuera Helm-charts, det finns stöd för Helm-plugins.
3. Det är lättare att hantera hemligheter, eftersom hemligheter kan tillämpas i pipelines och också lagras i Git i krypterad form (beroende på användarens preferenser).
4. Ingen bindning till ett specifikt verktyg, eftersom alla typer av verktyg kan användas.
5. Versionsuppdateringar av containrar kan initieras av byggpipen.

Nackdelar:

1. Uppgifter för åtkomst till klustret finns inom byggsystemet.
2. Det är fortfarande enklare att uppdatera containrarna i deployments med pull-processen.
3. Stark beroende av CD-systemet, eftersom de pipelines vi behöver kanske ursprungligen är skrivna för Gitlab Runners, och sedan bestämmer teamet sig för att byta till Azure DevOps eller Jenkins… och det blir nödvändigt att migrera en stor mängd byggpipelines.

Sammanfattning: Push eller Pull?

Som vanligt har varje metod sina fördelar och nackdelar. Vissa uppgifter är lättare att genomföra med en metod och svårare med en annan. Jag började med att göra distributioner manuellt, men efter att ha snubblat över några artiklar om Weave Flux beslutade jag att implementera GitOps-processer för alla projekt. För grundläggande mallar var det enkelt, men sedan började jag stöta på svårigheter med Helm-diagram. Vid den tiden erbjöd Weave Flux bara en tidig version av Helm Chart Operator, men även nu är vissa uppgifter svårare på grund av behovet av att manuellt skapa hemligheter och tillämpa dem. Man kan säga att pull-metoden är mycket säkrare, eftersom klustrets autentiseringsuppgifter är otillgängliga utanför det, vilket ökar säkerheten så mycket att det motiverar den extra ansträngningen.

Efter att ha funderat lite kom jag till en oväntad insikt, att det inte är så. När det gäller komponenter som kräver maximal säkerhet, så finns hemlagringssystem och CI/CD-system samt Git-repositorier på den listan. Informationen där är ganska sårbar och behöver maximal skydd. Dessutom, om någon tar sig in i ditt Git-repository och kan push:a kod dit, kan de distribuera allt de vill (oavsett om det är en pull- eller push-metod), och infiltrera kluster-systemen. Därför är de mest skyddskrävande komponenterna Git-repository och CI/CD-system, inte klustrets autentiseringsuppgifter. Om du har välkonfigurerade säkerhetspolicies och åtgärder för sådana system, och klustrets autentiseringsuppgifter hämtas i pipelines endast som hemligheter, kan den extra säkerheten av pull-metoden visa sig vara mindre värdefull än först antaget.

Så, om pull-metoden är mer arbetskrävande och inte ger några säkerhetsvinster, är det inte irrationellt att bara använda push-metoden? Men någon kan hävda att i push-metoden är du alltför beroende av CI/CD-systemet och att det kanske är bättre att inte göra så, så att det i framtiden blir lättare att genomföra migrationer.

Enligt min åsikt, som alltid, bör man använda det som passar bäst för den specifika situationen eller kombinera. Personligen använder jag båda tillvägagångssätten: Weave Flux för deployment baserat på pull, vilket huvudsakligen involverar våra egna tjänster, och push-metoden med Helm och tillägg som förenklar tillämpningen av Helm-charts till klustret och gör det möjligt att enkelt skapa hemligheter. Jag tror att det aldrig kommer att finnas en enhetlig lösning som passar alla fall, eftersom det alltid finns så många nyanser som beror på den specifika användningsvarianten. Samtidigt rekommenderar jag starkt GitOps – det underlättar livet och ökar säkerheten avsevärt.

Jag hoppas att min erfarenhet inom detta ämne hjälper dig att avgöra vilken metod som passar bäst för din typ av deployments, och jag skulle gärna vilja höra din åsikt.

P.S. Notering från översättaren

En nackdel med pull-modellen är att det är svårt att lägga de renderade manifesten i Git, men det finns ingen nackdel i att CD-pipelinen i pull-modellen lever separat från rollout och i princip blir en pipeline av typen Continuous Apply. Därför kommer det att krävas ännu mer ansträngning för att samla status från alla deployments och ge tillgång till loggar/status, helst kopplat till CD-systemet.

I detta avseende tillåter push-modellen att vi ger vissa garantier för utrullning, eftersom livslängden för pipelinen kan göras lika med livslängden för utrullningen.

Vi har testat båda modellerna och kommit fram till samma slutsatser som artikelns författare:

1. Pull-modellen passar oss för att organisera uppdatering av systemkomponenter på ett stort antal kluster (se. artikeln om addon-operator).
2. Push-modellen baserad på GitLab CI passar bra för utrullning av applikationer med hjälp av Helm-charts. Samtidigt följs utrullningen av deployments inom ramen för pipeline genom verktyget werf. För övrigt, i samband med detta projekt hörde vi konstant "GitOps" när vi diskuterade aktuella problem för DevOps-ingenjörer vid vår monter på KubeCon Europe'19.

P.P.S. från översättaren

Läs även i vår blogg:

• «Kubernetes tips & tricks: översättning av resurser som arbetar i klustret under Helm 2»;
• «Vi presenterar biblioteket kubedog för att övervaka Kubernetes-resurser»;
• «Utökar och kompletterar Kubernetes (översikt och videoföreläsning)»;
• «Tips för att skapa anpassade arbetsflöden i GitLab CI».

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

Använder du GitOps?

• Ja, pull-metoden

• Ja, push

• Ja, pull + push

• Ja, något annat

• Ingen

30 användare har röstat. 10 användare har avstått.

Källa: habr.com