GitOps: Sammenligning av Pull- og Push-metoder

Merk. overs.: I Kubernetes-fellesskapet vinner en trend kalt GitOps åpenbar popularitet, som vi personlig har sett, besøker KubeCon Europe 2019. Denne termen var relativt fersk oppfunnet av sjefen for Weaveworks - Alexis Richardson - og betyr bruk av verktøy kjent for utviklere (primært Git, derav navnet) for å løse driftsproblemer. Spesielt snakker vi om driften av Kubernetes ved å lagre konfigurasjonene i Git og automatisk rulle ut endringer i klyngen. Matthias Jg snakker om to tilnærminger til denne utrullingen i denne artikkelen.

Det siste året (faktisk skjedde dette formelt i august 2017 - ca. overs.) Det er en ny tilnærming til å distribuere applikasjoner i Kubernetes. Det kalles GitOps, og det er basert på den grunnleggende ideen om at distribusjonsversjoner spores i det sikre miljøet til et Git-depot.

De viktigste fordelene med denne tilnærmingen er som følger::

1. Distribusjonsversjon og endringshistorikk. Tilstanden til hele klyngen lagres i et Git-depot, og distribusjoner oppdateres kun gjennom commits. I tillegg kan alle endringer spores ved hjelp av commit-historikken.
2. Tilbakeføringer ved hjelp av kjente Git-kommandoer. Enkel git reset lar deg tilbakestille endringer i distribusjoner; tidligere tilstander er alltid tilgjengelige.
3. Klar tilgangskontroll. Vanligvis inneholder et Git-system mye sensitiv data, så de fleste selskaper legger spesielt vekt på å beskytte dem. Følgelig gjelder denne beskyttelsen også for operasjoner med utplasseringer.
4. Retningslinjer for distribusjoner. De fleste Git-systemer støtter gren-for-gren-policyer – for eksempel kan bare pull-forespørsler oppdatere master, og endringer må gjennomgås og aksepteres av et annet teammedlem. Som med tilgangskontroll gjelder de samme retningslinjene for distribusjonsoppdateringer.

Som du kan se, er det mange fordeler med GitOps-metoden. I løpet av det siste året har to tilnærminger vunnet særlig popularitet. Den ene er push-basert, den andre er pull-basert. Før vi ser på dem, la oss først se på hvordan typiske Kubernetes-distribusjoner ser ut.

Implementeringsmetoder

De siste årene har ulike metoder og verktøy for distribusjon blitt etablert i Kubernetes:

1. Basert på opprinnelige Kubernetes/Kustomize-maler. Dette er den enkleste måten å distribuere applikasjoner på Kubernetes. Utvikleren lager de grunnleggende YAML-filene og bruker dem. For å bli kvitt å hele tiden omskrive de samme malene, ble Kustomize utviklet (det gjør Kubernetes-maler om til moduler). Merk. overs.: Kustomize har blitt integrert i kubectl med utgivelse av Kubernetes 1.14.
2. Hjelmdiagrammer. Rordiagrammer lar deg lage sett med maler, init-beholdere, sidevogner, etc., som brukes til å distribuere applikasjoner med mer fleksible tilpasningsalternativer enn i en malbasert tilnærming. Denne metoden er basert på malte YAML-filer. Helm fyller dem med ulike parametere og sender dem deretter til Tiller, en klyngekomponent som distribuerer dem til klyngen og tillater oppdateringer og tilbakeføringer. Det viktige er at Helm egentlig bare setter inn de ønskede verdiene i malene og deretter bruker dem på samme måte som det gjøres i den tradisjonelle tilnærmingen (les mer om hvordan det hele fungerer og hvordan du kan bruke det i vår artikkel av Helm — ca. oversett.). Det finnes et bredt utvalg av ferdiglagde Helm-diagrammer som dekker et bredt spekter av oppgaver.
3. Alternative verktøy. Det finnes mange alternative verktøy. Felles for dem alle er at de gjør noen malfiler til Kubernetes-lesbare YAML-filer og deretter bruker dem.

I vårt arbeid bruker vi hele tiden Helm-diagrammer for viktige verktøy (siden de har mange ting allerede klare, noe som gjør livet mye enklere) og "rene" Kubernetes YAML-filer for å distribuere våre egne applikasjoner.

Trekk og skyv

I et av mine siste blogginnlegg introduserte jeg verktøyet Vev Flux, som lar deg commitere maler til Git-depotet og oppdatere distribusjonen etter hver commit eller push av beholderen. Min erfaring viser at dette verktøyet er et av de viktigste i å fremme pull-tilnærmingen, så jeg vil ofte referere til det. Hvis du vil vite mer om hvordan du bruker det, her lenke til artikkelen.

NB! Alle fordelene ved å bruke GitOps forblir de samme for begge tilnærmingene.

Pullbasert tilnærming

Pull-tilnærmingen er basert på det faktum at alle endringer blir brukt fra klyngen. Det er en operatør inne i klyngen som regelmessig sjekker de tilknyttede Git- og Docker Registry-repositoriene. Hvis det skjer endringer i dem, oppdateres klyngens tilstand internt. Denne prosessen anses generelt for å være svært sikker, siden ingen ekstern klient har tilgang til klyngeadministratorrettigheter.

Pros:

1. Ingen ekstern klient har rettigheter til å gjøre endringer i klyngen; alle oppdateringer rulles ut innenfra.
2. Noen verktøy lar deg også synkronisere Helm-kartoppdateringer og koble dem til klyngen.
3. Docker Registry kan skannes for nye versjoner. Hvis et nytt bilde er tilgjengelig, oppdateres Git-depotet og distribusjonen til den nye versjonen.
4. Pull-verktøy kan distribueres på tvers av forskjellige navneområder med forskjellige Git-repositorier og tillatelser. Takket være dette kan en multitenant-modell brukes. For eksempel kan team A bruke navneområde A, team B kan bruke navneområde B, og infrastrukturteamet kan bruke global plass.
5. Som regel er verktøyene veldig lette.
6. Kombinert med verktøy som operatør Bitnami forseglede hemmeligheter, kan hemmeligheter lagres kryptert i et Git-depot og hentes i klyngen.
7. Det er ingen tilkobling til CD-rørledninger siden distribusjoner skjer innenfor klyngen.

Cons:

1. Å administrere distribusjonshemmeligheter fra Helm-diagrammer er vanskeligere enn vanlige, siden de først må genereres i form av for eksempel forseglede hemmeligheter, deretter dekrypteres av en intern operatør, og først etter det blir de tilgjengelige for pull-verktøyet. Deretter kan du kjøre utgivelsen i Helm med verdiene i de allerede utplasserte hemmelighetene. Den enkleste måten er å lage en hemmelighet med alle Helm-verdiene som brukes for distribusjon, dekryptere den og forplikte den til Git.
2. Når du tar en trekktilnærming, blir du bundet til trekkverktøy. Dette begrenser muligheten til å tilpasse distribusjonsprosessen i en klynge. For eksempel er Kustomize komplisert av det faktum at det må kjøres før de endelige malene blir forpliktet til Git. Jeg sier ikke at du ikke kan bruke frittstående verktøy, men de er vanskeligere å integrere i distribusjonsprosessen.

Push-basert tilnærming

I push-tilnærmingen starter et eksternt system (hovedsakelig CD-pipelines) distribusjoner til klyngen etter en commit til Git-depotet eller hvis den forrige CI-pipelinen er vellykket. I denne tilnærmingen har systemet tilgang til klyngen.

Pros:

1. Sikkerheten bestemmes av Git-depotet og bygge-pipeline.
2. Det er enklere å distribuere Helm-diagrammer og støtter Helm-plugins.
3. Hemmeligheter er lettere å administrere fordi hemmeligheter kan brukes i pipelines og kan også lagres kryptert i Git (avhengig av brukerens preferanser).
4. Det er ingen kobling til et bestemt verktøy, siden alle typer kan brukes.
5. Oppdateringer av containerversjon kan initieres av byggepipelinen.

Cons:

1. Klyngetilgangsdataene er inne i byggesystemet.
2. Oppdatering av distribusjonsbeholdere er fortsatt enklere med en pull-prosess.
3. Stor avhengighet av CD-systemet, siden pipelinene vi trenger, kan ha blitt opprinnelig skrevet for Gitlab Runners, og deretter bestemmer teamet seg for å flytte til Azure DevOps eller Jenkins... og vil måtte migrere et stort antall byggepipelines.

Resultater: Push eller Pull?

Som vanligvis er tilfellet, har hver tilnærming sine fordeler og ulemper. Noen oppgaver er lettere å utføre med en og vanskeligere med en annen. Først utførte jeg distribusjoner manuelt, men etter at jeg kom over noen artikler om Weave Flux, bestemte jeg meg for å implementere GitOps-prosesser for alle prosjekter. For grunnleggende maler var dette enkelt, men så begynte jeg å få problemer med Helm-diagrammer. På den tiden tilbød Weave Flux bare en rudimentær versjon av Helm Chart Operator, men selv nå er noen oppgaver vanskeligere på grunn av behovet for å manuelt lage hemmeligheter og bruke dem. Du kan argumentere for at pull-tilnærmingen er mye sikrere fordi klyngens legitimasjon ikke er tilgjengelig utenfor klyngen, noe som gjør det så mye sikrere at det er verdt den ekstra innsatsen.

Etter litt omtanke kom jeg til den uventede konklusjonen at det ikke er slik. Hvis vi snakker om komponenter som krever maksimal beskyttelse, vil denne listen inkludere hemmelig lagring, CI/CD-systemer og Git-lagre. Informasjonen i dem er svært sårbar og trenger maksimal beskyttelse. I tillegg, hvis noen kommer inn i Git-depotet ditt og kan presse kode dit, kan de distribuere hva de vil (enten det er pull eller push) og infiltrere klyngens systemer. Dermed er de viktigste komponentene som må beskyttes Git-depotet og CI/CD-systemene, ikke klyngelegitimasjonen. Hvis du har godt konfigurerte policyer og sikkerhetskontroller for denne typen systemer, og klyngelegitimasjon bare trekkes ut i rørledninger som hemmeligheter, er den ekstra sikkerheten til en pull-tilnærming kanskje ikke så verdifull som opprinnelig antatt.

Så hvis pull-tilnærmingen er mer arbeidskrevende og ikke gir en sikkerhetsfordel, er det ikke logisk å bruke bare push-tilnærmingen? Men noen kan hevde at i push-tilnærmingen er du for bundet til CD-systemet, og kanskje er det bedre å ikke gjøre dette slik at det blir lettere å gjennomføre migrasjoner i fremtiden.

Etter min mening (som alltid) bør du bruke det som er best egnet for en spesiell sak eller kombi. Personlig bruker jeg begge tilnærmingene: Weave Flux for pull-baserte distribusjoner som stort sett inkluderer våre egne tjenester, og en push-tilnærming med Helm og plugins, som gjør det enkelt å bruke Helm-diagrammer på klyngen og lar deg lage hemmeligheter sømløst. Jeg tror det aldri vil være en enkelt løsning som passer for alle tilfeller, fordi det alltid er mange nyanser og de avhenger av den spesifikke applikasjonen. Når det er sagt, anbefaler jeg GitOps på det varmeste – det gjør livet mye enklere og forbedrer sikkerheten.

Jeg håper min erfaring om dette emnet vil hjelpe deg med å avgjøre hvilken metode som er mer egnet for din type distribusjon, og jeg vil gjerne høre din mening.

PS Notat fra oversetteren

Ulempen med pull-modellen er at det er vanskelig å sette gjengitte manifester inn i Git, men det er ingen ulemper at CD-pipelinen i pull-modellen lever separat fra utrullingen og i hovedsak blir en kategori-pipeline Kontinuerlig påfør. Derfor vil det kreves enda mer innsats for å samle statusen deres fra alle distribusjoner og på en eller annen måte gi tilgang til logger/status, gjerne med referanse til CD-systemet.

I denne forstand lar push-modellen oss gi i det minste noen garantier for utrulling, fordi levetiden til rørledningen kan gjøres lik levetiden til utrullingen.

Vi prøvde begge modellene og kom til de samme konklusjonene som forfatteren av artikkelen:

1. Pullmodellen er egnet for oss til å organisere oppdateringer av systemkomponenter på et stort antall klynger (se. artikkel om addon-operatør).
2. Push-modellen basert på GitLab CI er godt egnet for å rulle ut applikasjoner ved hjelp av Helm-diagrammer. Samtidig overvåkes utrullingen av distribusjoner i rørledninger ved hjelp av verktøyet werf. Forresten, i sammenheng med dette prosjektet vårt, hørte vi den konstante "GitOps" da vi diskuterte de presserende problemene til DevOps-ingeniører på standen vår på KubeCon Europe'19.

PPS fra oversetter

Les også på bloggen vår:

• «Kubernetes tips og triks: overføring av ressurser som kjører i en klynge til Helm 2-administrasjon";
• «Vi introduserer kubedog, et bibliotek for sporing av Kubernetes-ressurser";
• «Utvide og komplettere Kubernetes (gjennomgang og videorapport)";
• «Tips for å lage tilpassede arbeidsflyter i GitLab CI'.

Kun registrerte brukere kan delta i undersøkelsen. Logg inn, vær så snill.

Bruker du GitOps?

• Ja, trekk tilnærming

• Ja, press

• Ja, trekk + trykk

• Ja, noe annet

• Ikke

30 brukere stemte. 10 brukere avsto.

Kilde: www.habr.com