GitOps: traukimo ir stūmimo metodų palyginimas

Pastaba. vert.: Kubernetes bendruomenėje tendencija, vadinama GitOps, įgauna akivaizdų populiarumą, kaip matėme asmeniškai, lankantis KubeCon Europe 2019. Šis terminas buvo palyginti neseniai išrado Weaveworks vadovo Alexis Richardson ir reiškia kūrėjams žinomų įrankių (pirmiausia Git, iš čia ir pavadinimas) naudojimą sprendžiant veiklos problemas. Visų pirma kalbame apie „Kubernetes“ veikimą išsaugant jo konfigūracijas „Git“ ir automatiškai išleidžiant klasterio pakeitimus. Matthias Jg šiame straipsnyje kalba apie du šio diegimo būdus.

Praėjusiais metais, (Tiesą sakant, formaliai tai įvyko 2017 m. rugpjūčio mėn. – apytiksliai vertimas) Yra naujas požiūris į programų diegimą „Kubernetes“. Jis vadinamas „GitOps“ ir pagrįstas pagrindine idėja, kad diegimo versijos yra stebimos saugioje „Git“ saugyklos aplinkoje.

Pagrindiniai šio metodo pranašumai yra šie::

1. Diegimo versijų kūrimas ir pakeitimų istorija. Viso klasterio būsena saugoma „Git“ saugykloje, o diegimai atnaujinami tik per įsipareigojimus. Be to, visus pakeitimus galima sekti naudojant įsipareigojimų istoriją.
2. Atšaukimas naudojant pažįstamas Git komandas... Paprastas git reset leidžia iš naujo nustatyti diegimo pakeitimus; praeities būsenos visada prieinamos.
3. Paruošta prieigos kontrolė. Paprastai Git sistemoje yra daug jautrių duomenų, todėl dauguma įmonių skiria ypatingą dėmesį jų apsaugai. Atitinkamai, ši apsauga taip pat taikoma operacijoms su dislokavimu.
4. Diegimo politika. Dauguma „Git“ sistemų iš esmės palaiko kiekvienos šakos politiką – pavyzdžiui, pagrindinį atnaujinimą gali atlikti tik ištraukimo užklausos, o pakeitimus turi peržiūrėti ir priimti kitas komandos narys. Kaip ir prieigos valdymui, diegimo naujinimams taikomos tos pačios strategijos.

Kaip matote, „GitOps“ metodas turi daug privalumų. Per pastaruosius metus ypač išpopuliarėjo du būdai. Vienas yra stūmimo, kitas - traukimo pagrindu. Prieš apžvelgdami juos, pirmiausia pažiūrėkime, kaip atrodo tipiški Kubernetes diegimai.

Diegimo metodai

Pastaraisiais metais Kubernetes įsitvirtino įvairūs diegimo metodai ir įrankiai:

1. Remiantis vietiniais Kubernetes / Kustomize šablonais. Tai lengviausias būdas įdiegti programas Kubernetes. Kūrėjas sukuria pagrindinius YAML failus ir juos taiko. Siekiant atsikratyti nuolatinio tų pačių šablonų perrašymo, buvo sukurta Kustomize (ji paverčia Kubernetes šablonus moduliais). Pastaba. vert.: Kustomize buvo integruota į kubectl su Kubernetes 1.14 leidimas.
2. Vairo diagramos. Valdymo diagramos leidžia kurti šablonų, inicijavimo konteinerių, šoninių priekabų ir kt. rinkinius, kurie naudojami diegti programas su lankstesnėmis tinkinimo parinktimis nei naudojant šablonais pagrįstą metodą. Šis metodas pagrįstas šabloniniais YAML failais. „Helm“ užpildo juos įvairiais parametrais, o tada siunčia juos „Tiller“ – klasterio komponentui, kuris juos diegia klasteryje ir leidžia atnaujinti bei atšaukti. Svarbu tai, kad Helm iš esmės tik įterpia norimas reikšmes į šablonus ir pritaiko jas taip pat, kaip tai daroma naudojant tradicinį metodą. (daugiau apie tai, kaip visa tai veikia ir kaip galite tai panaudoti, skaitykite mūsų Helmo straipsnis - apytiksliai vertimas.). Yra daugybė paruoštų Helm diagramų, apimančių įvairias užduotis.
3. Alternatyvūs įrankiai. Yra daug alternatyvių įrankių. Jiems visiems bendra yra tai, kad kai kuriuos šablonų failus jie paverčia Kubernetes skaitomais YAML failais ir tada juos naudoja.

Savo darbe nuolat naudojame svarbių įrankių Helm diagramas (nes jose jau daug dalykų yra paruošta, o tai labai palengvina gyvenimą) ir „grynus“ Kubernetes YAML failus savo programoms diegti.

Traukti stumti

Viename iš savo naujausių tinklaraščio įrašų pristačiau šį įrankį Weave Flux, kuri leidžia įtraukti šablonus į „Git“ saugyklą ir atnaujinti diegimą po kiekvieno konteinerio įsipareigojimo ar išstūmimo. Mano patirtis rodo, kad šis įrankis yra vienas iš pagrindinių skatinančių traukos metodą, todėl dažnai juo remsiuosi. Jei norite sužinoti daugiau apie tai, kaip jį naudoti, čia nuoroda į straipsnį.

NB! Visi „GitOps“ naudojimo pranašumai abiem būdais išlieka tokie patys.

Traukimu pagrįstas metodas

Ištraukimo metodas pagrįstas tuo, kad visi pakeitimai taikomi klasteryje. Klasterio viduje yra operatorius, kuris reguliariai tikrina susijusias „Git“ ir „Docker“ registro saugyklas. Jei juose įvyksta kokių nors pakeitimų, klasterio būsena atnaujinama viduje. Šis procesas paprastai laikomas labai saugiu, nes joks išorinis klientas neturi prieigos prie klasterio administratoriaus teisių.

Argumentai "už":

1. Joks išorinis klientas neturi teisės atlikti klasterio pakeitimų; visi atnaujinimai išleidžiami iš vidaus.
2. Kai kurie įrankiai taip pat leidžia sinchronizuoti Helm diagramos naujinimus ir susieti juos su grupe.
3. „Docker Registry“ galima nuskaityti, ar nėra naujų versijų. Jei yra naujas vaizdas, Git saugykla ir diegimas atnaujinami į naują versiją.
4. Ištraukimo įrankiai gali būti paskirstyti skirtingose ​​vardų srityse su skirtingomis Git saugyklomis ir leidimais. Dėl to galima naudoti kelių nuomininkų modelį. Pavyzdžiui, A komanda gali naudoti vardų erdvę A, komanda B gali naudoti vardų erdvę B, o infrastruktūros komanda gali naudoti pasaulinę erdvę.
5. Paprastai įrankiai yra labai lengvi.
6. Kartu su tokiais įrankiais kaip operatorius Bitnami užantspauduotos paslaptys, paslaptys gali būti saugomos užšifruotos „Git“ saugykloje ir gaunamos klasteryje.
7. Nėra ryšio su CD vamzdynais, nes diegimas vyksta klasteryje.

Trūkumai:

1. Diegimo paslapčių valdymas iš „Helm“ diagramų yra sudėtingesnis nei įprastų, nes pirmiausia jas reikia sugeneruoti, tarkime, užantspauduotų paslapčių pavidalu, tada iššifruoti vidinio operatoriaus ir tik po to jos tampa prieinamos ištraukimo įrankiui. Tada galite paleisti leidimą „Helm“ naudodami jau įdiegtų paslapčių reikšmes. Lengviausias būdas yra sukurti paslaptį su visomis diegimui naudojamomis Helm reikšmėmis, ją iššifruoti ir perduoti Git.
2. Kai pasirenkate traukimo metodą, esate pririštas prie traukimo įrankių. Tai riboja galimybę tinkinti diegimo procesą grupėje. Pavyzdžiui, „Kustomize“ apsunkina tai, kad ji turi būti paleista, kol galutiniai šablonai bus priskirti „Git“. Nesakau, kad negalite naudoti atskirų įrankių, tačiau juos sunkiau integruoti į diegimo procesą.

Stūmimu pagrįstas požiūris

Taikant „push“ metodą, išorinė sistema (daugiausia CD konvejeriai) paleidžia diegimą klasteryje po įsipareigojimo „Git“ saugykloje arba jei ankstesnis CI vamzdynas yra sėkmingas. Taikant šį metodą, sistema turi prieigą prie klasterio.

Argumentai "už":

1. Saugą nustato „Git“ saugykla ir kūrimo dujotiekis.
2. „Helm“ diagramų diegimas yra lengvesnis ir palaiko „Helm“ papildinius.
3. Paslaptis lengviau valdyti, nes paslaptys gali būti naudojamos konvejeriuose ir taip pat gali būti saugomos užšifruotos Git (atsižvelgiant į vartotojo pageidavimus).
4. Nėra ryšio su konkrečiu įrankiu, nes galima naudoti bet kokį įrankį.
5. Sudėtinio rodinio versijos naujinimus gali inicijuoti kūrimo dujotiekis.

Trūkumai:

1. Klasterio prieigos duomenys yra kūrimo sistemoje.
2. Diegimo konteinerius vis dar lengviau atnaujinti naudojant ištraukimo procesą.
3. Didelė priklausomybė nuo kompaktinių diskų sistemos, nes mums reikalingi dujotiekiai iš pradžių galėjo būti sukurti Gitlab Runners, o tada komanda nusprendžia pereiti prie Azure DevOps arba Jenkins... ir turės perkelti daugybę kūrimo vamzdynų.

Rezultatai: stumti ar traukti?

Kaip paprastai, kiekvienas metodas turi savo privalumų ir trūkumų. Kai kurias užduotis lengviau atlikti su vienu, o su kitomis – sunkiau. Iš pradžių diegimą dariau rankiniu būdu, bet po kelių straipsnių apie „Weave Flux“ nusprendžiau įdiegti „GitOps“ procesus visiems projektams. Su pagrindiniais šablonais tai buvo lengva, bet tada aš pradėjau susidurti su sunkumais su Helm diagramomis. Tuo metu „Weave Flux“ siūlė tik pradinę „Helm Chart Operator“ versiją, tačiau net ir dabar kai kurios užduotys yra sunkesnės, nes reikia rankiniu būdu kurti paslaptis ir jas taikyti. Galite ginčytis, kad traukimo metodas yra daug saugesnis, nes klasterio kredencialai nepasiekiami už klasterio ribų, todėl jis yra daug saugesnis, todėl verta dėti papildomų pastangų.

Kiek pagalvojęs priėjau netikėtos išvados, kad taip nėra. Jei kalbėsime apie komponentus, kuriems reikalinga maksimali apsauga, šiame sąraše bus slapta saugykla, CI/CD sistemos ir Git saugyklos. Jų viduje esanti informacija yra labai pažeidžiama ir ją reikia maksimaliai apsaugoti. Be to, jei kas nors patenka į jūsų „Git“ saugyklą ir gali ten nusiųsti kodą, jis gali įdiegti viską, ko nori (ar tai būtų traukimas, ar stumimas) ir įsiskverbti į klasterio sistemas. Taigi svarbiausi komponentai, kuriuos reikia apsaugoti, yra „Git“ saugykla ir CI / CD sistemos, o ne klasterio kredencialai. Jei turite gerai sukonfigūruotas šių tipų sistemų strategijas ir saugos valdiklius, o klasterio kredencialai ištraukiami tik į konvejerius kaip paslaptys, papildoma traukimo metodo sauga gali būti ne tokia vertinga, kaip manyta iš pradžių.

Taigi, jei traukimo metodas yra daug darbo reikalaujantis ir nesuteikia naudos saugumui, ar nėra logiška naudoti tik stūmimo metodą? Tačiau kas nors gali ginčytis, kad naudojant „push“ metodą esate pernelyg pririštas prie kompaktinių diskų sistemos ir galbūt geriau to nedaryti, kad ateityje būtų lengviau atlikti perkėlimą.

Mano nuomone (kaip visada) reikėtų naudoti tai, kas labiausiai tinka konkrečiam atvejui ar kombainui. Asmeniškai aš naudoju abu būdus: „Weave Flux“ traukimu pagrįstiems diegimams, kurie dažniausiai apima mūsų pačių paslaugas, ir „push“ metodą su „Helm“ ir papildiniais, kurie palengvina „Helm“ diagramų pritaikymą klasteriui ir leidžia sklandžiai kurti paslaptis. Vieno sprendimo, tinkančio visiems atvejams, manau, niekada nebus, nes niuansų visada yra labai daug ir jie priklauso nuo konkretaus pritaikymo. Be to, aš labai rekomenduoju „GitOps“ – tai labai palengvina gyvenimą ir padidina saugumą.

Tikiuosi, kad mano patirtis šia tema padės jums nuspręsti, kuris metodas labiau tinka jūsų diegimo tipui, ir man bus malonu išgirsti jūsų nuomonę.

PS Vertėjo pastaba

Ištraukimo modelio trūkumai apima faktą, kad sunku įdėti pateiktus manifestus į Git, tačiau nėra jokio trūkumo, kad kompaktinio disko konvejeris traukimo modelyje gyvena atskirai nuo išleidimo ir iš esmės tampa kategorijos konvejeriu. Nuolatinis taikymas. Todėl reikės dar daugiau pastangų norint surinkti jų būseną iš visų diegimų ir kažkaip suteikti prieigą prie žurnalų / būsenos, pageidautina, atsižvelgiant į kompaktinių diskų sistemą.

Šia prasme stūmimo modelis leidžia mums suteikti bent tam tikras išplėtimo garantijas, nes dujotiekio eksploatavimo laikas gali būti lygus išleidimo trukmei.

Išbandėme abu modelius ir padarėme tokias pačias išvadas, kaip ir straipsnio autorius:

1. Ištraukimo modelis tinka mums organizuoti sistemos komponentų atnaujinimus daugelyje grupių (žr. Straipsnis apie priedų operatorių).
2. „GitLab CI“ pagrįstas „push“ modelis puikiai tinka programoms diegti naudojant „Helm“ diagramas. Tuo pačiu metu naudojant įrankį stebimas diegimų diegimas vamzdynuose werf. Beje, šio mūsų projekto kontekste nuolat girdėjome „GitOps“, kai savo stende KubeCon Europe'19 aptarinėjome aktualias DevOps inžinierių problemas.

PPS iš vertėjo

Taip pat skaitykite mūsų tinklaraštyje:

• «„Kubernetes“ patarimai ir gudrybės: išteklių, veikiančių klasteryje, perkėlimas į „Helm 2“ valdymą»;
• «Pristatome kubedog, Kubernetes išteklių stebėjimo biblioteką»;
• «„Kubernetes“ išplėtimas ir papildymas (apžvalga ir vaizdo reportažas)»;
• «Patarimai, kaip sukurti pasirinktines darbo eigas naudojant „GitLab CI“.".

Apklausoje gali dalyvauti tik registruoti vartotojai. Prisijungti, Prašau.

Ar naudojate „GitOps“?

• Taip, traukite

• Taip, stumk

• Taip, traukite + stumkite

• Taip, dar kažkas

• Ne

Balsavo 30 vartotojų. 10 vartotojai susilaikė.

Šaltinis: www.habr.com