Op. prev.: V skupnosti Kubernetes pridobiva izrazit pomen trend, imenovan GitOps, čemur smo osebno priče, KubeCon Europe 2019. Ta izraz je bil relativno nedavno od vodje podjetja Weaveworks - Alexis Richardson - in pomeni uporabo orodij, ki so razvojnim ekipam poznana (predvsem Git, od koder tudi ime) za reševanje nalog upravljanja. Gre predvsem za upravljanje Kubernetes, pri čemer so njegove konfiguracije shranjene v Gitu in se spremembe avtomatsko nalagajo v klaster. O dveh pristopih k tej nalogi piše Matthias Jg v tem članku.
Lani (v resnici se je to formalno zgodilo avgusta 2017 - op. prev.) se je pojavil nov pristop k uvajanju aplikacij v Kubernetes. Imenuje se GitOps, njegova osnovna ideja pa je, da se različice namestitev sledijo v varnem GIT repozitoriju.
Osnovne prednosti tega pristopa so naslednje:
- Sledenje različicam namestitev in zgodovina sprememb. Stanje celotnega klasterja se shranjuje v Git repozitoriju, namestitve pa se posodabljajo le z metodami commitov. Poleg tega je mogoče vse spremembe slediti preko zgodovine commitov.
- Povratki z uporabo znanih ukazov Git. Preprosto
git resetomogoča vračanje sprememb v namestitvah; vedno so dostopne prejšnje različice. - Pripravljen nadzor dostopa. Običajno GIT sistem vsebuje vrsto zaupnih podatkov, zato večina podjetij posebno pozornost namenja njegovi zaščiti. Tako se ta zaščita razširi tudi na operacije z namestitvami.
- Politike za namestitve. Večina GIT sistemov prvotno podpira politike za različne veje - na primer, le pull requesti lahko posodabljajo master, spremembe pa mora pregledati in sprejeti drug član ekipe. Tako kot pri nadzoru dostopa se iste politike uporabljajo za posodobitve namestitev.
Kot vidite, metoda GitOps prinaša številne prednosti. V preteklem letu sta pridobila posebno priljubljenost dva pristopa. Eden temelji na push, drugi pa na pull. Preden ju preučimo, si poglejmo, kako izgledajo tipične namestitve Kubernetes.
Načini uvajanja
V zadnjih letih so se v Kubernetesu uveljavili različni načini in orodja za uvajanje:
- Na osnovi domačih predlog Kubernetes/KustomizeTo je najlažji način za upravljanje aplikacijami v Kubernetesu. Razvijalec ustvari osnovne YAML datoteke in jih uporabi. Da se izogne nenehnemu prepisovanju istih predlog, je bil razvit Kustomize (spremeni predloge Kubernetes v module). Op. prev.: Kustomize je bil integriran v kubectl z .
- Helm Charti. Helm Charti omogočajo ustvarjanje sklopov predlog, init kontejnerjev, sidecar-ov itd., ki se uporabljajo za namestitev aplikacij z večjo fleksibilnostjo prilagajanja kot pri pristopu na osnovi predlog. Ta metoda se opira na predlogirane YAML datoteke. Helm jih izpolnjuje z različnimi parametri in nato pošlje Tillerju — klasterskemu komponentu, ki jih namesti v klaster in omogoča nadgradnje in povratke. Pomembno je, da Helm pravzaprav samo vstavi potrebne vrednosti v predloge in jih nato uporabi na enak način, kot se to počne pri tradicionalnem pristopu. (več o tem, kako to vse deluje in kako ga lahko uporabite, preberite v naši — op. prev.). Obstaja velika raznolikost pripravljenih Helm chartov, ki pokrivajo širok spekter nalog.
- Alternativna orodja. Obstaja številna alternativna orodja. Vse jih združuje dejstvo, da pretvarjajo določene predloge v razumljive Kubernetes YAML datoteke in jih nato aplicirajo.
Pri svojem delu nenehno uporabljamo Helm chart-e za pomembna orodja (ker je v njih veliko že pripravljenega, kar bistveno olajša življenje) ter 'čiste' YAML datoteke Kubernetes za nameščanje lastnih aplikacij.
Pull & Push
V eni svojih nedavnih objav na blogu sem predstavil orodje , ki omogoča committing predlog v Git repozitorij in posodabljanje namestitve po vsakem commitu ali push-u kontejnerja. Moje izkušnje kažejo, da je to orodje eno izmed ključnih pri spodbujanju pull pristopa, zato se bom pogosto skliceval na njega. Če želite izvedeti več o tem, kako ga uporabljati, je tukaj .
NB! Vse prednosti uporabe GitOps ostajajo za oba pristopa.
Pristop na osnovi Pull
Osnova pristopa pull temelji na dejstvu, da se vse spremembe izvajajo znotraj klasterja. Znotraj klasterja je operator, ki redno preverja povezane Git in Docker Registry repozitorije. Če pride do kakršnih koli sprememb, se stanje klasterja posodobi od znotraj. To se običajno šteje za precej varno, saj noben zunanji klient nima dostopa do adminsitrativnih pravic klasterja.
Prednosti:
- Noben zunanji klient nima pravic za uvajanje sprememb v klaster, vse posodobitve se izvajajo od znotraj.
- Nekateri alati prav tako omogočajo sinhronizacijo posodobitev Helm chartov in njihovo povezovanje s klasterjem.
- Docker Registry lahko skenirate za nove različice. Če se pojavi nova slika, se Git repozitorij in deployment posodobita na novo različico.
- Pull alati so lahko razdeljeni po različnih imenskih prostorih z različnimi Git repozitoriji in pravicami dostopa. Zaradi tega je mogoče uporabiti večnajemno (multitenant) model. Na primer, skupina A lahko uporablja imenski prostor A, skupina B pa imenski prostor B, skupina, ki se ukvarja z infrastrukturo, pa lahko uporablja globalni prostor.
- Na splošno so alati precej lahki.
- V kombinaciji z alat omejevalcem, , se skrivnosti lahko shranijo v šifrirani obliki v Git repozitoriju in pridobijo znotraj klasterja.
- Ni povezave s CD-pipelines, saj se razporeditve izvajajo znotraj klasterja.
Недостатки:
- Upravljanje skrivnosti za razporeditve iz Helm chartov je bolj zapleteno kot običajno, saj jih je najprej treba ustvariti v obliki, recimo, sealed secrets, nato jih dešifrirati s stranskim operatorjem in šele nato so na voljo za pull alat. Nato lahko zaženete izdajo v Helmu z vrednostmi v že razporejenih skrivnostih. Najenostavnejši način je ustvariti skrivnost z vsemi vrednostmi Helm, ki se uporabljajo za razporeditev, jo dešifrirati in jo shraniti v Git.
- Uporaba pull-pristopa vas veže na orodja, ki delujejo s pulli. To omejuje možnosti prilagajanja procesa uvajanja deploymentov v grozd. Na primer, delo s Kustomize je oteženo, ker ga je treba izvesti, preden končni predlogi pridejo v Git. Ne pravim, da ne morete uporabljati posameznih orodij, vendar njihovo integracijo v uvajanje otežuje.
Pristop, ki temelji na Push
V push-pristopu zunanja sistem (predvsem CD-pipeline) sproži uvajanja v grozd po commitu v Git-repozitoriju ali ob uspešnem zaključku prejšnjega CI-pipeline. V tem pristopu ima sistem dostop do grozda.
Prednosti:
- Varnost je določena z Git-repozitorijem in procesom gradnje.
- Uvajanje Helm grafikonov je lažje, saj je podprto s Helm vtičniki.
- Upravljanje s skrivnostmi je lažje, saj jih lahko uporabite v pipeline, poleg tega pa jih lahko shranite v Git v šifrirani obliki (odvisno od uporabnikovih preferenc).
- Pomanjkanje vezave na določeno orodje, saj lahko uporabite katerokoli vrsto.
- Posodobitve različic kontejnerjev lahko sproži proces gradnje.
Недостатки:
- Podatki za dostop do grozda so shranjeni v sistemu gradnje.
- Posodabljanje kontejnerjev v deploymentih je še vedno lažje izvajati s pull-procesom.
- Močna odvisnost od CD-sistema, saj so potrebni pipeline morda prvotno napisani za Gitlab Runners, nato pa se odloči ekipa preiti na Azure DevOps ali Jenkins… in bo potrebno migrirati veliko število procesov gradnje.
Zaključki: Push ali Pull?
Kot običajno, vsak pristop ima svoje prednosti in slabosti. Nekatere naloge je lažje izvesti na en način, druge pa na drugega. Sprva sem ročno izvajal wdpritje, a ko sem naletel na nekaj člankov o Weave Flux, sem se odločil uvesti procese GitOps za vse projekte. Za osnovne predloge je bilo to enostavno, a kmalu sem se začel srečevati s težavami pri delu z Helm charti. Takrat je Weave Flux ponujal le začetno različico Helm Chart Operatorja, vendar tudi zdaj so nekatere naloge zahtevnejše zaradi potrebe po ročni izdelavi skrivnosti in njihovem uporabi. Lahko bi rekli, da je pull pristop veliko bolj varen, saj so poverilnice klasterja dostopne le v svojem okviru, kar povečuje varnost in upravičuje dodatne napore.
Po krajšem razmišljanju sem prišel do nepričakovanega zaključka, da to ni tako. Kar se tiče komponent, ki zahtevajo največjo zaščito, bi se na ta seznam uvrstili skladišča skrivnosti in CI/CD sistemi, Git repozitoriji. Informacije v njih so precej ranljive in potrebujejo največjo zaščito. Poleg tega, če nekdo prodre v vaš Git repozitorij in lahko pošlje kodo, potem lahko razporedi vse, kar želi (ne glede na izbrani pristop, bodisi pull bodisi push), in vstopi v sisteme klasterja. Tako so najpomembnejše komponente, ki zahtevajo zaščito, Git repozitorij in CI/CD sistemi, ne pa poverilnice klasterja. Če imate dobro nastavljen politike in varnostne ukrepe za takšne sisteme, in se poverilnice klasterja izčrpavajo v pipeline samo kot skrivnosti, dodatna varnost pull pristopa morda ni tako dragocena, kot je sprva izgledalo.
Torej, če je pull pristop bolj delovno intenziven in ne prinaša varnostne prednosti, ali ni logično uporabiti le push pristop? Vendar pa bi nekdo lahko trdil, da ste pri push pristopu preveč odvisni od CD sistema in da morda ni pametno, da to delate, da bi v prihodnosti olajšali migracije.
Po mojem mnenju (kot vedno) bi morali uporabiti tisto, kar bolje ustreza specifičnemu primeru ali kombinirati. Osebno uporabljam oba pristopa: Weave Flux za implementacije na osnovi pull, ki večinoma vključujejo naše lastne storitve, in push-pristop s Helm-om in vtičniki, ki poenostavi uporabo Helm chartov v klasterju ter omogoča brez težav ustvarjanje skrivnosti. Mislim, da nikoli ne bo enotne rešitve, primerne za vse primere, saj je vedno veliko podrobnosti in so odvisne od konkretne uporabe. Ob tem močno priporočam GitOps — ta močno olajša življenje in poveča varnost.
Upam, da bo moje znanje na to temo pomagalo odločiti, kateri metoda bolj ustreza vašemu tipu implementacij, z veseljem pa bi izvedel tudi vaše mnenje.
P.S. Opomba prevajalca
Med slabostmi pull modela je točka, da je težko shraniti v Git upodobljene manifeste, vendar ni slabosti, da CD-pipeline v pull modelu živi ločeno od implementacije in v bistvu postane pipeline kategorije Continuous Apply. Zato bo potrebnih še več naporov, da se zbere status iz vseh implementacij in nekako omogoči dostop do zapisov/statusa, pri čemer bi bilo zaželeno, da je povezan s CD sistemom.
V tem smislu push model omogoča zagotavljanje vsaj nekaterih garancij pri izvajanju, saj lahko življenjsko dobo pipeline-a nastavimo enako življenjski dobi izvajanja.
Preizkusili smo oba modela in prišli do enakih zaključkov kot avtor članka:
- Pull model se nam prilagaja za organizacijo posodobitve sistemskih komponent na številnih klasterjih (glejte ).
- Push model na osnovi GitLab CI se dobro poda za izvedbo aplikacij z uporabo Helm chartov. Pri tem se izvajanje implementacij v okviru pipeline-ov spremlja z orodjem . Mimogrede, v kontekstu tega našega projekta smo nenehno slišali 'GitOps', ko smo razpravljali o nujnih težavah DevOps inženirjev pri našem razstavnem prostoru na KubeCon Europe’19.
P.P.S. od prevajalca
Preberite tudi na našem blogu:
- «»;
- «»;
- «»;
- «».
Samo registrovani korisnici mogu učestvovati u anketi. , molim vas.
Ali uporabljate GitOps?
Da, pull pristop
Da, push
Da, pull + push
Da, nekaj drugega
Ne
Glasovalo je 30 uporabnikov. 10 uporabnikov se je vzdržalo.
Izvor: habr.com
