Opomba. prevod: V skupnosti Kubernetes trend, imenovan GitOps, pridobiva očitno popularnost, kot smo osebno videli, KubeCon Europe 2019. Ta izraz je bil relativno nov vodja Weaveworks - Alexis Richardson - in pomeni uporabo razvijalcem poznanih orodij (predvsem Git, od tod tudi ime) za reševanje operativnih težav. Predvsem govorimo o delovanju Kubernetesa s shranjevanjem njegovih konfiguracij v Git in samodejnim uvajanjem sprememb v gručo. Matthias Jg v tem članku govori o dveh pristopih k tej uvedbi.
Lansko leto, (pravzaprav se je formalno to zgodilo avgusta 2017 – pribl. prev.) V Kubernetesu obstaja nov pristop k uvajanju aplikacij. Imenuje se GitOps in temelji na osnovni ideji, da se različicam uvajanja sledi v varnem okolju repozitorija Git.
Glavne prednosti tega pristopa so naslednje::
- Uvajanje različic in zgodovina sprememb. Stanje celotne gruče je shranjeno v repozitoriju Git, uvedbe pa se posodabljajo samo s potrditvami. Poleg tega je vsem spremembam mogoče slediti z zgodovino objave.
- Povrnitve z znanimi ukazi Git... Navaden
git resetomogoča ponastavitev sprememb uvajanj; pretekla stanja so vedno na voljo. - Pripravljen nadzor dostopa. Običajno sistem Git vsebuje veliko občutljivih podatkov, zato večina podjetij posveča posebno pozornost njihovi zaščiti. V skladu s tem ta zaščita velja tudi za operacije z razmestitvami.
- Politike za uvajanja. Večina sistemov Git izvorno podpira pravilnike za posamezne veje – na primer, samo zahteve po vleki lahko posodobijo glavni del, spremembe pa mora pregledati in sprejeti drug član ekipe. Tako kot pri nadzoru dostopa veljajo isti pravilniki tudi za posodobitve uvajanja.
Kot lahko vidite, ima metoda GitOps številne prednosti. V zadnjem letu sta dva pristopa pridobila posebno popularnost. Ena temelji na potiskanju, druga na vlečenju. Preden si jih ogledamo, si najprej poglejmo, kako so videti tipične uvedbe Kubernetes.
Metode uvajanja
V zadnjih letih je Kubernetes vzpostavil različne metode in orodja za uvedbe:
- Temelji na domačih predlogah Kubernetes/Customize. To je najlažji način za uvajanje aplikacij v Kubernetes. Razvijalec ustvari osnovne datoteke YAML in jih uporabi. Da bi se znebili nenehnega prepisovanja istih predlog, je bil razvit Kustomize (predloge Kubernetes spreminja v module). Opomba. prevod: Kustomize je bil integriran v kubectl z .
- Karte Helm. Karte Helm vam omogočajo ustvarjanje nizov predlog, zagonskih vsebnikov, stranskih prikolic itd., ki se uporabljajo za uvajanje aplikacij z bolj prilagodljivimi možnostmi prilagajanja kot pri pristopu, ki temelji na predlogah. Ta metoda temelji na datotekah YAML s predlogami. Helm jih napolni z različnimi parametri in jih nato pošlje Tillerju, komponenti gruče, ki jih namesti v gručo in omogoča posodobitve in povrnitve. Pomembno je, da Helm v bistvu samo vstavi želene vrednosti v predloge in jih nato uporabi na enak način, kot je to storjeno pri tradicionalnem pristopu. (preberite več o tem, kako vse deluje in kako ga lahko uporabite v našem — pribl. prev.). Obstaja široka paleta že pripravljenih Helmovih kart, ki pokrivajo širok spekter nalog.
- Alternativna orodja. Obstaja veliko alternativnih orodij. Vsem je skupno, da nekatere datoteke predlog spremenijo v datoteke YAML, ki jih je mogoče brati s Kubernetesom, in jih nato uporabijo.
Pri našem delu nenehno uporabljamo Helmove grafikone za pomembna orodja (saj imajo veliko stvari že pripravljenih, kar močno olajša življenje) in “čiste” Kubernetes YAML datoteke za postavitev lastnih aplikacij.
Potegnite in potisnite
V eni od svojih nedavnih objav v blogu sem predstavil orodje , ki vam omogoča, da objavite predloge v repozitorij Git in posodobite razmestitev po vsaki objavi ali potisku vsebnika. Moje izkušnje kažejo, da je to orodje eno glavnih pri spodbujanju pristopa vleka, zato se ga bom pogosto skliceval. Če želite izvedeti več o tem, kako ga uporabljati, tukaj .
Opomba! Vse prednosti uporabe GitOps ostajajo enake za oba pristopa.
Pristop, ki temelji na vleki
Pristop vleka temelji na dejstvu, da se vse spremembe uporabijo znotraj gruče. V gruči je operater, ki redno preverja povezana repozitorija Git in Docker Registry. Če se na njih pojavijo kakršne koli spremembe, se stanje gruče interno posodobi. Ta postopek na splošno velja za zelo varnega, saj noben zunanji odjemalec nima dostopa do skrbniških pravic gruče.
Profesionalci:
- Noben zunanji odjemalec nima pravice spreminjati gruče; vse posodobitve se izvajajo od znotraj.
- Nekatera orodja vam omogočajo tudi sinhronizacijo posodobitev karte Helm in njihovo povezavo z gručo.
- Docker Registry je mogoče skenirati za nove različice. Če je na voljo nova slika, se repozitorij Git in uvedba posodobita na novo različico.
- Orodja za vleko je mogoče porazdeliti po različnih imenskih prostorih z različnimi repozitoriji in dovoljenji Git. Zahvaljujoč temu je mogoče uporabiti večnajemniški model. Na primer, ekipa A lahko uporablja imenski prostor A, ekipa B lahko uporablja imenski prostor B, infrastrukturna ekipa pa lahko uporablja globalni prostor.
- Orodja so praviloma zelo lahka.
- V kombinaciji z orodji, kot je operater , lahko skrivnosti šifrirano shranite v repozitorij Git in jih pridobite znotraj gruče.
- Ni povezave s cevovodi CD, ker se uvajanja izvajajo znotraj gruče.
Proti:
- Upravljanje skrivnosti uvajanja iz grafikonov Helm je težje kot običajnih, saj jih je treba najprej generirati v obliki, recimo, zapečatenih skrivnosti, nato jih dešifrira notranji operater in šele nato postanejo na voljo orodju za vlečenje. Nato lahko zaženete izdajo v Helmu z vrednostmi v že razporejenih skrivnostih. Najlažji način je ustvariti skrivnost z vsemi vrednostmi Helm, ki se uporabljajo za uvajanje, jo dešifrirati in predati Gitu.
- Ko se odločite za vlečni pristop, postanete vezani na vlečna orodja. To omejuje možnost prilagajanja postopka uvajanja v gruči. Na primer, Kustomize je zapleten zaradi dejstva, da se mora zagnati, preden so končne predloge predane Gitu. Ne rečem, da ne morete uporabljati samostojnih orodij, vendar jih je težje integrirati v vaš postopek uvajanja.
Pristop, ki temelji na potiskanju
Pri potisnem pristopu zunanji sistem (večinoma cevovodi CD-jev) zažene uvedbe v gručo po potrditvi v repozitorij Git ali če je prejšnji cevovod CI uspešen. Pri tem pristopu ima sistem dostop do gruče.
Pros:
- Varnost določata repozitorij Git in cevovod gradnje.
- Uvajanje grafikonov Helm je enostavnejše in podpira vtičnike Helm.
- Skrivnosti je lažje upravljati, ker se skrivnosti lahko uporabljajo v cevovodih in se lahko tudi šifrirano shranijo v Git (odvisno od uporabnikovih preferenc).
- Ni povezave z določenim orodjem, saj je mogoče uporabiti katero koli vrsto.
- Posodobitve različice vsebnika lahko sproži cevovod gradnje.
Proti:
- Podatki za dostop do gruče so znotraj sistema gradnje.
- Posodabljanje razmestitvenih vsebnikov je še vedno lažje s postopkom vleke.
- Močna odvisnost od sistema CD, saj so bili cevovodi, ki jih potrebujemo, morda prvotno napisani za Gitlab Runners, nato pa se ekipa odloči, da bo prešla na Azure DevOps ali Jenkins ... in bo morala preseliti veliko število cevovodov gradnje.
Rezultati: Push or Pull?
Kot je običajno, ima vsak pristop svoje prednosti in slabosti. Nekatere naloge je z enim lažje opraviti, z drugim pa težje. Sprva sem uvajanja izvajal ročno, ko pa sem naletel na nekaj člankov o Weave Flux, sem se odločil implementirati procese GitOps za vse projekte. Za osnovne predloge je bilo to enostavno, potem pa sem začel naleteti na težave s Helmovimi grafikoni. Takrat je Weave Flux ponujal le osnovno različico operaterja Helm Chart, vendar so tudi zdaj nekatere naloge težje zaradi potrebe po ročnem ustvarjanju skrivnosti in njihovi uporabi. Lahko trdite, da je pristop vleke veliko bolj varen, ker poverilnice gruče niso dostopne zunaj gruče, zaradi česar je toliko bolj varen, da je vreden dodatnega truda.
Po premisleku sem prišel do nepričakovanega zaključka, da temu ni tako. Če govorimo o komponentah, ki zahtevajo maksimalno zaščito, bo ta seznam vključeval skrivno shranjevanje, sisteme CI/CD in repozitorije Git. Informacije v njih so zelo ranljive in potrebujejo maksimalno zaščito. Poleg tega, če nekdo pride v vaše skladišče Git in lahko tja potisne kodo, lahko uvede, kar hoče (bodisi je vlečno ali potisno) in se infiltrira v sisteme gruče. Tako so najpomembnejše komponente, ki jih je treba zaščititi, repozitorij Git in sistemi CI/CD, ne pa poverilnice gruče. Če imate dobro konfigurirane pravilnike in varnostne kontrole za te vrste sistemov in so poverilnice gruče ekstrahirane v cevovode samo kot skrivnosti, dodatna varnost pristopa vleka morda ni tako dragocena, kot se je prvotno mislilo.
Torej, če je pristop vlečenja bolj delovno intenziven in ne zagotavlja varnostne koristi, ali ni logično uporabiti samo pristop potiskanja? Toda kdo bi lahko trdil, da ste pri potisnem pristopu preveč vezani na sistem CD in je morda bolje, da tega ne storite, da boste v prihodnosti lažje izvajali migracije.
Po mojem mnenju (kot vedno) morate uporabiti tisto, kar je najbolj primerno za določen primer ali kombinacijo. Osebno uporabljam oba pristopa: Weave Flux za uvedbe, ki temeljijo na vlečenju, ki večinoma vključujejo naše lastne storitve, in potisni pristop s Helmom in vtičniki, ki olajša uporabo grafikonov Helm v gručo in vam omogoča brezhibno ustvarjanje skrivnosti. Mislim, da nikoli ne bo ene same rešitve, primerne za vse primere, ker je vedno veliko nians in so odvisne od konkretne aplikacije. Glede na to zelo priporočam GitOps - zelo olajša življenje in izboljša varnost.
Upam, da vam bodo moje izkušnje na to temo pomagale pri odločitvi, katera metoda je primernejša za vašo vrsto uvedbe, in vesel bom vašega mnenja.
PS Opomba prevajalca
Slaba stran vlečnega modela je, da je težko vstaviti upodobljene manifeste v Git, vendar ni slaba stran, da cevovod CD v vlečnem modelu živi ločeno od uvajanja in v bistvu postane cevovod kategorije Nenehna uporaba. Zato bo potrebno še več truda, da zberemo njihov status iz vseh razmestitev in nekako zagotovimo dostop do dnevnikov/statusa, po možnosti glede na sistem CD.
V tem smislu nam potisni model omogoča, da zagotovimo vsaj nekaj jamstev za uvedbo, saj lahko življenjsko dobo cevovoda izenačimo z življenjsko dobo uvedbe.
Preizkusili smo oba modela in prišli do enakih zaključkov kot avtor članka:
- Pull model je primeren za organizacijo posodobitev sistemskih komponent na velikem številu gruč (glej. ).
- Potisni model, ki temelji na GitLab CI, je zelo primeren za uvajanje aplikacij z uporabo grafikonov Helm. Istočasno se z orodjem spremlja uvedba uvajanj znotraj cevovodov . Mimogrede, v okviru tega našega projekta smo slišali stalni "GitOps", ko smo razpravljali o perečih težavah inženirjev DevOps na naši stojnici na KubeCon Europe'19.
PPS od prevajalca
Preberite tudi na našem blogu:
- «»;
- «»;
- «»;
- «".
V anketi lahko sodelujejo samo registrirani uporabniki. , prosim.
Ali uporabljate GitOps?
-
Da, potegni pristop
-
Da, potisni
-
Da, potegni + potisni
-
Ja, nekaj drugega
-
Št
Glasovalo je 30 uporabnikov. 10 uporabnikov se je vzdržalo.
Vir: www.habr.com