GitOps: sammenligning av Pull- og Push-metoder

Obs. overs.: I Kubernetes-samfunnet blir trenden kalt GitOps stadig mer populær, noe vi personlig fikk bekreftet da vi besøkte KubeCon Europe 2019. Dette begrepet ble relativt nylig oppfunnet av lederen for Weaveworks — Alexis Richardson — og innebærer bruk av de verktøyene som utviklere kjenner godt (i første rekke — Git, derav navnet) for å løse driftsoppgaver. Spesielt handler det om drift av Kubernetes gjennom å lagre konfigurasjonene i Git og automatisk rulle ut endringer til klyngen. Matthias Jg forklarer de to tilnærmingene til denne utrullingen i denne artikkelen.

I fjor (egentlig, formelt sett skjedde dette i august 2017 — anm. oversetter.) oppsto en ny tilnærming for distribusjon av applikasjoner i Kubernetes. Den kalles GitOps, og den er basert på den grunnleggende ideen om at versjonskontroll av distribusjoner skjer i et sikkert Git-repositorium.

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

1. Versjonering av distribusjoner og historikk over endringer. Tilstanden til hele klyngen lagres i Git-repositoriet, og distribusjoner oppdateres kun ved hjelp av commits. I tillegg kan alle endringer spores ved hjelp av commit-historikken.
2. Tilbakerullinger ved bruk av kjente Git-kommandoer. En enkel git reset lar deg tilbakestille endringer i distribusjoner; tidligere tilstander er alltid tilgjengelige.
3. Klar tilgangskontroll. Vanligvis inneholder Git-systemer mange konfidensielle data, så de fleste selskaper gir spesiell oppmerksomhet til beskyttelsen av dem. Denne beskyttelsen gjelder derfor også for operasjoner med distribusjoner.
4. Retningslinjer for distribusjoner. De fleste Git-systemer støtter fra starten av retningslinjer for ulike grener — for eksempel kan bare pull requests oppdatere master, og endringer må godkjennes og aksepteres av et annet teammedlem. Som med tilgangskontrollen, blir de samme retningslinjene anvendt på oppdateringer av distribusjoner.

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

Distributionsmetoder

I løpet av de siste årene har det etablert seg ulike metoder og verktøy for distribusjoner i Kubernetes:

1. Basert på native maler Kubernetes/KustomizeDette er den enkleste måten å deployere applikasjoner i Kubernetes. Utvikleren lager grunnleggende YAML-filer og anvender dem. For å unngå å måtte skrive de samme malene om igjen, ble Kustomize utviklet (det omdanner Kubernetes-maler til moduler). Obs. overs.: Kustomize ble integrert i kubectl med Kubernetes versjon 1.14.
2. Helm Charts. Helm Charts lar deg lage sett med maler, init-containere, sidecar-er, osv., som brukes til å deployere applikasjoner med mer fleksible tilpasningsmuligheter enn malebaserte tilnærminger. I bunn av denne metoden ligger malifiserte YAML-filer. Helm fyller dem med ulike parametere og sender dem deretter til Tiller – den klyngekomponenten som deployerer dem i klyngen og tillater oppdateringer og tilbakestillinger. Det viktigste er at Helm i utgangspunktet bare setter inn de nødvendige verdiene i malene og deretter anvender dem akkurat som det gjøres i tradisjonelle tilnærminger. (for mer informasjon om hvordan dette fungerer og hvordan det kan brukes, se vår artikkel om Helm – obs. overs.). Det finnes et stort mangfold av ferdige Helm-charts som dekker et bredt spekter av oppgaver.
3. Alternativer. Det finnes mange alternative verktøy. Alle deler det at de omdanner visse malfiler til forståelige Kubernetes YAML-filer og deretter anvender dem.

I vårt arbeid bruker vi kontinuerlig Helm-charts for viktige verktøy (siden mye allerede er klart, noe som betydelig forenkler livet) og 'rene' Kubernetes YAML-filer for å deployere egne applikasjoner.

Pull & Push

I et av mine nyere blogginnlegg presenterte jeg verktøyet Weave Flux, som lar deg commite maler til et Git-repositorium og oppdatere deployment etter hver commit eller push av containeren. Min erfaring viser at dette verktøyet er et av de viktigste for å fremme pull-tilnærmingen, så jeg vil ofte referere til det. Hvis du vil vite mer om hvordan du bruker det, her er lenken til artikkelen.

NB! Alle fordelene ved å bruke GitOps gjelder for begge tilnærminger.

Pull-baserte tilnærminger

Grunnlaget for pull-tilnærmingen ligger i det faktum at alle endringer blir anvendt fra innsiden av klyngen. Inne i klyngen finnes det en operatør som regelmessig sjekker de tilknyttede Git-repositoriene og Docker Registry. Hvis det skjer noen endringer der, oppdateres tilstanden til klyngen fra innsiden. Det anses vanligvis for å være ganske sikkert, ettersom ingen eksterne kunder har tilgang til administratorrettighetene til klyngen.

Fordeler:

1. Ingen eksterne kunder har rett til å foreta endringer i klyngen, alle oppdateringer rulles ut fra innsiden.
2. Noen verktøy lar også synkronisere oppdateringer av Helm-diagrammer og knytte dem til klyngen.
3. Docker Registry kan skannes for nye versjoner. Hvis et nytt bilde dukker opp, oppdateres Git-repositoriet og distribusjonen til den nye versjonen.
4. Pull-verktøy kan distribueres på forskjellige navnerom med ulike Git-repositorier og tilgangsrettigheter. Dette gjør det mulig å benytte en multitenant-modell. For eksempel kan Team A bruke navnerom A, Team B et navnerom B, mens teamet som jobber med infrastrukturen kan bruke et globalt navnerom.
5. Generelt er verktøyene ganske lette.
6. I kombinasjon med verktøy som operatøren Bitnami Sealed Secrets, kan hemmeligheter lagres i kryptert format i Git-repositoriet og hentes inne i klyngen.
7. Det er ingen forbindelse til CD-pipelines, ettersom distribusjoner skjer inne i klyngen.

Ulemper:

1. Å administrere hemmelighetene til distribusjoner fra Helm-diagrammer er mer komplisert enn vanlige, siden de først må genereres som for eksempel sealed secrets, deretter dekrypteres av den interne operatøren, og først da blir de tilgjengelige for pull-verktøyet. Deretter kan man kjøre en utgivelse i Helm med verdier fra allerede distribuerte hemmeligheter. Den enkleste måten er å lage en hemmelighet med alle Helm-verdiene brukt for distribusjonen, dekryptere den og commite den til Git.
2. Ved å bruke pull-tilnærmingen er du bundet til verktøyene som håndterer pull. Dette begrenser muligheten til å tilpasse distribusjonsprosessen av deployment i klyngen. For eksempel blir arbeidet med Kustomize komplisert fordi det må kjøres før de endelige malene går til Git. Jeg sier ikke at man ikke kan bruke separate verktøy, men de er vanskeligere å integrere i distribusjonsprosessen.

Push-basert tilnærming

I push-tilnærmingen starter et eksternt system (for det meste CD-pipelines) distribusjonene i klyngen etter at det er gjort et commit i Git-repositoriet eller etter vellykket kjøring av den foregående CI-pipelinen. I denne tilnærmingen har systemet tilgang til klyngen.

Fordeler:

1. Sikkerheten bestemmes av Git-repositoriet og bygge-pipelinen.
2. Det er enklere å distribuere Helm-diagrammer, med støtte for Helm-plugins.
3. Å administrere hemmeligheter er enklere, siden man kan bruke hemmelighetene i pipeliner og oppbevare dem i Git i kryptert form (avhengig av brukerens preferanser).
4. Ingen binding til spesifikke verktøy, siden alle typer kan brukes.
5. Oppdateringer av containerversjoner kan initieres av bygge-pipelinen.

Ulemper:

1. Data for å få tilgang til klyngen er inne i byggesystemet.
2. Det er fremdeles enklere å oppdatere containere for deployments med pull-prosessen.
3. Sterk avhengighet av CD-systemet, siden de nødvendige pipeline-ene kanskje først ble skrevet for Gitlab Runners, og så bestemmer teamet seg for å gå over til Azure DevOps eller Jenkins… og det må migreres mange bygge-pipelines.

Oppsummering: Push eller Pull?

Som vanlig har hver tilnærming sine fordeler og ulemper. Noen oppgaver er lettere å utføre med én løsning, mens andre er vanskeligere med en annen. I starten utførte jeg distribusjoner manuelt, men etter å ha kommet over noen artikler om Weave Flux, bestemte jeg meg for å implementere GitOps-prosesser for alle prosjektene mine. For grunnleggende maler var dette enkelt, men jeg begynte deretter å møte utfordringer med Helm-diagrammer. Da tilbød Weave Flux bare en tidlig versjon av Helm Chart Operator, men selv nå er noen oppgaver vanskeligere på grunn av behovet for manuelt å opprette hemmeligheter og bruke dem. Du kan si at pull-tilnærmingen er mye sikrere, siden klyngelegitimasjonen ikke er tilgjengelig utenfor, noe som øker sikkerheten så mye at det er verdt den ekstra innsatsen.

Etter å ha tenkt en stund, kom jeg til den overraskende konklusjonen at dette ikke er tilfelle. Når det gjelder komponenter som krever maksimal beskyttelse, må hemmelighetslagre og CI/CD-systemer, Git-repositorier, inkluderes i listen. Informasjonen inne i dem er svært sårbar og trenger maksimal beskyttelse. I tillegg, hvis noen får tilgang til Git-repositoriet ditt og kan pushe kode dit, kan de distribuere hva som helst (uavhengig av hvilken tilnærming som brukes, enten det er pull eller push), og infiltrere klyngesystemene. Dermed er de mest kritiske komponentene som trenger beskyttelse Git-repositoriet og CI/CD-systemene, ikke klyngelegitimasjonen. Hvis du har godt konfigurerte sikkerhetstiltak for slike systemer, og klyngelegitimasjonen hentes inn i pipeline bare som hemmeligheter, kan den ekstra sikkerheten fra pull-tilnærmingen vise seg å ikke være så verdifull som først antatt.

Så, hvis pull-tilnærmingen er mer arbeidskrevende og ikke gir noen sikkerhetsfordel, er det ikke logisk å bruke kun push-tilnærmingen? Men noen kan hevde at med push-tilnærmingen er du for avhengig av CI-systemet, og det kan være bedre å unngå det for å gjøre fremtidige migrasjoner enklere.

Etter min mening (som alltid) bør man bruke det som passer best til den aktuelle situasjonen, eller kombinere. Personlig bruker jeg begge tilnærminger: Weave Flux for deployment basert på pull, som hovedsakelig omfatter våre egne tjenester, og push-tilnærmingen med Helm og plugins, som forenkler bruken av Helm-diagrammer i klyngen og gjør det enkelt å opprette hemmeligheter. Jeg tror aldri det vil finnes én løsning som passer for alle tilfeller, fordi det alltid finnes mange nyanser som avhenger av den konkrete bruken. Samtidig vil jeg sterkt anbefale GitOps – det gjør livet mye enklere og øker sikkerheten.

Jeg håper min erfaring på dette området kan hjelpe deg med å finne ut hvilken metode som passer best for din type deployment, og jeg vil gjerne høre din mening.

P.S. Merknad fra oversetteren

Ulempen med pull-modellen er at det er vanskelig å legge de rendert manifestene i Git, men det er ikke en ulempe at CD-pipeline i pull-modellen lever adskilt fra utrullingen og i praksis blir en pipeline av kategorien Continuous Apply. Derfor vil det kreve enda mer innsats for å samle statusen fra alle deployment og på en eller annen måte gi tilgang til logger/status, helst knyttet til CD-systemet.

I denne forstand tillater push-modellen å gi noen garantier for utrullingen fordi levetiden til pipeline kan gjøres lik levetiden til utrullingen.

Vi har testet begge modeller og kommet til de samme konklusjonene som forfatteren av artikkelen:

1. Pull-modellen passer oss for å organisere oppdatering av systemkomponenter på et stort antall klynger (se artikkelen om addon-operator).
2. Push-modellen basert på GitLab CI passer godt for utrulling av applikasjoner ved hjelp av Helm-diagrammer. Utrullingen av deployment i tilknytning til pipelines spores ved hjelp av verktøyet werf. For øvrig, i konteksten av dette prosjektet hørte vi stadig "GitOps" når vi diskuterte de presserende problemene DevOps-ingeniører hadde ved vårt stand på KubeCon Europe 19.

P.P.S. fra oversetteren

Also read in our blog:

• «Kubernetes tips & tricks: oversette kjørende ressurser i klyngen til Helm 2»;
• «Vi presenterer kubedog-biblioteket for overvåkning av Kubernetes-ressurser»;
• «Utvider og supplere Kubernetes (oversikt og video av foredraget)»;
• «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, pull-tilnærmingen

• Ja, push

• Ja, pull + push

• Ja, noe annet

• Nei

30 brukere stemte. 10 brukere avholdt seg.

Kilde: habr.com