Bilješka. prev.: U Kubernetes zajednici, trend nazvan GitOps dobiva očiglednu popularnost, kao što smo osobno vidjeli, KubeCon Europe 2019. Ovaj termin je bio relativno novi od strane voditelja Weaveworksa - Alexisa Richardsona - i podrazumijeva korištenje alata poznatih programerima (prvenstveno Git, otuda i naziv) za rješavanje operativnih problema. Konkretno, govorimo o radu Kubernetesa pohranjivanjem njegovih konfiguracija u Git i automatskim uvođenjem promjena u klaster. Matthias Jg u ovom članku govori o dva pristupa ovom uvođenju.
Prošle godine (zapravo, formalno se to dogodilo u kolovozu 2017. - pribl. prev.) Postoji novi pristup postavljanju aplikacija u Kubernetes. Zove se GitOps i temelji se na osnovnoj ideji da se verzije implementacije prate u sigurnom okruženju Git repozitorija.
Glavne prednosti ovog pristupa su sljedeće::
- Verzija implementacije i povijest promjena. Stanje cijelog klastera pohranjuje se u Git repozitorij, a implementacije se ažuriraju samo putem obveza. Osim toga, sve promjene mogu se pratiti korištenjem povijesti predaje.
- Vraćanje pomoću poznatih Git naredbi... Jednostavan
git resetomogućuje poništavanje promjena u implementacijama; prošla stanja su uvijek dostupna. - Spremna kontrola pristupa. Git sustav obično sadrži puno osjetljivih podataka, pa većina tvrtki posvećuje posebnu pozornost njihovoj zaštiti. Sukladno tome, ova se zaštita također odnosi na operacije s implementacijama.
- Pravila za implementacije. Većina Git sustava izvorno podržava pravila grane po grane—na primjer, samo zahtjevi za povlačenje mogu ažurirati master, a promjene mora pregledati i prihvatiti drugi član tima. Kao i kod kontrole pristupa, ista se pravila primjenjuju na ažuriranja implementacije.
Kao što vidite, postoji mnogo prednosti GitOps metode. Tijekom prošle godine dva su pristupa stekla posebnu popularnost. Jedan se temelji na guranju, a drugi na povlačenju. Prije nego što ih pogledamo, prvo pogledajmo kako izgledaju tipične Kubernetes implementacije.
Metode postavljanja
Posljednjih su godina u Kubernetesu uspostavljene različite metode i alati za implementaciju:
- Na temelju izvornih Kubernetes/Customize predložaka. Ovo je najlakši način za implementaciju aplikacija na Kubernetes. Programer stvara osnovne YAML datoteke i primjenjuje ih. Kako bi se riješili stalnog prepisivanja istih predložaka, razvijen je Kustomize (pretvara Kubernetes predloške u module). Bilješka. prev.: Kustomize je integriran u kubectl sa .
- Helm karte. Helm karte vam omogućuju stvaranje skupova predložaka, init spremnika, bočnih prikolica itd., koji se koriste za implementaciju aplikacija s fleksibilnijim opcijama prilagodbe nego u pristupu temeljenom na predlošku. Ova se metoda temelji na YAML datotekama s predlošcima. Helm ih ispunjava različitim parametrima, a zatim ih šalje Tilleru, komponenti klastera koja ih postavlja na klaster i omogućuje ažuriranje i vraćanje u prethodno stanje. Važno je da Helm u biti samo umeće željene vrijednosti u predloške i zatim ih primjenjuje na isti način kao što se radi u tradicionalnom pristupu (pročitajte više o tome kako sve to radi i kako to možete koristiti u našem - cca. prev.). Postoji veliki izbor gotovih Helm karata koje pokrivaju širok raspon zadataka.
- Alternativni alati. Postoje mnogi alternativni alati. Ono što im je svima zajedničko jest da pretvaraju neke predloške u YAML datoteke čitljive za Kubernetes i zatim ih koriste.
U svom radu stalno koristimo Helmove grafikone za važne alate (jer imaju dosta toga već spremnog, što znatno olakšava život) i “čiste” Kubernetes YAML datoteke za implementaciju vlastitih aplikacija.
Povuci gurni
U jednom od svojih nedavnih postova na blogu predstavio sam alat , koji vam omogućuje predaju predložaka u Git repozitorij i ažuriranje implementacije nakon svakog predavanja ili guranja spremnika. Moje iskustvo pokazuje da je ovaj alat jedan od glavnih u promicanju pull pristupa, pa ću ga često spominjati. Ako želite saznati više o tome kako ga koristiti, ovdje .
NB! Sve prednosti korištenja GitOpsa ostaju iste za oba pristupa.
Pristup temeljen na povlačenju
Pristup povlačenja temelji se na činjenici da se sve promjene primjenjuju unutar klastera. Unutar klastera postoji operater koji redovito provjerava pridružena spremišta Git i Docker Registry. Ako se na njima dogode bilo kakve promjene, stanje klastera se interno ažurira. Ovaj se proces općenito smatra vrlo sigurnim budući da nijedan vanjski klijent nema pristup pravima administratora klastera.
Pros:
- Nijedan vanjski klijent nema prava mijenjati klaster; sva se ažuriranja uvode iznutra.
- Neki vam alati također omogućuju sinkronizaciju ažuriranja Helm karte i njihovo povezivanje s klasterom.
- Docker Registry se može skenirati za nove verzije. Ako je dostupna nova slika, Git spremište i implementacija ažuriraju se na novu verziju.
- Alati za povlačenje mogu se distribuirati u različitim imenskim prostorima s različitim Git spremištima i dopuštenjima. Zahvaljujući tome, može se koristiti višestanarski model. Na primjer, tim A može koristiti prostor imena A, tim B može koristiti prostor imena B, a infrastrukturni tim može koristiti globalni prostor.
- Alati su u pravilu vrlo lagani.
- U kombinaciji s alatima kao što su operator , tajne se mogu pohraniti šifrirane u Git repozitorij i dohvatiti unutar klastera.
- Ne postoji veza s cjevovodima CD-a jer se implementacije odvijaju unutar klastera.
Cons:
- Upravljanje tajnama implementacije iz Helmovih dijagrama je teže od uobičajenih, budući da se prvo moraju generirati u obliku, recimo, zapečaćenih tajni, zatim dešifrirati interni operater, a tek nakon toga postaju dostupne alatu za povlačenje. Zatim možete pokrenuti izdanje u Helmu s vrijednostima u već raspoređenim tajnama. Najlakši način je stvoriti tajnu sa svim Helm vrijednostima koje se koriste za implementaciju, dešifrirati je i predati Gitu.
- Kada prihvatite potezni pristup, postajete vezani za potezne alate. Ovo ograničava mogućnost prilagodbe procesa implementacije u klasteru. Na primjer, Kustomize je kompliciran činjenicom da se mora pokrenuti prije nego što se konačni predlošci predaju Gitu. Ne kažem da ne možete koristiti samostalne alate, ali teže ih je integrirati u vaš proces implementacije.
Push temeljen pristup
U push pristupu, vanjski sustav (uglavnom CD cjevovodi) pokreće implementacije u klaster nakon predaje Git repozitoriju ili ako je prethodni CI cjevovod uspješan. U ovom pristupu sustav ima pristup klasteru.
Prozodija:
- Sigurnost je određena Git repozitorijem i cjevovodom izgradnje.
- Implementacija Helm grafikona je jednostavnija i podržava Helm dodatke.
- Tajnama je lakše upravljati jer se tajne mogu koristiti u cjevovodima i također mogu biti pohranjene šifrirane u Gitu (ovisno o preferencijama korisnika).
- Ne postoji veza s određenim alatom, jer se može koristiti bilo koja vrsta.
- Ažuriranje verzije spremnika može pokrenuti cjevovod za izgradnju.
Cons:
- Podaci o pristupu klasteru nalaze se unutar sustava za izgradnju.
- Ažuriranje spremnika za implementaciju još je lakše s postupkom povlačenja.
- Velika ovisnost o CD sustavu, budući da su cjevovodi koji nam trebaju možda izvorno napisani za Gitlab Runners, a onda tim odlučuje prijeći na Azure DevOps ili Jenkins... i morat će migrirati veliki broj cjevovoda za izgradnju.
Rezultati: Push or Pull?
Kao što to obično biva, svaki pristup ima svoje prednosti i nedostatke. Neke je zadatke lakše izvršiti s jednim, a teže s drugim. Isprva sam implementacije izvodio ručno, ali nakon što sam naišao na nekoliko članaka o Weave Fluxu, odlučio sam implementirati GitOps procese za sve projekte. Za osnovne predloške to je bilo lako, ali onda sam počeo nailaziti na poteškoće s Helmovim grafikonima. U to je vrijeme Weave Flux nudio samo rudimentarnu verziju Helm Chart Operatora, no čak su i sada neki zadaci teži zbog potrebe za ručnim stvaranjem tajni i njihovom primjenom. Mogli biste tvrditi da je pristup povlačenju mnogo sigurniji jer vjerodajnice klastera nisu dostupne izvan klastera, što ga čini toliko sigurnijim da je vrijedno dodatnog truda.
Nakon malo razmišljanja došao sam do neočekivanog zaključka da to nije tako. Ako govorimo o komponentama koje zahtijevaju maksimalnu zaštitu, ovaj popis će uključivati tajnu pohranu, CI/CD sustave i Git repozitorije. Informacije unutar njih vrlo su ranjive i trebaju maksimalnu zaštitu. Osim toga, ako netko uđe u vaše Git spremište i tamo može gurnuti kod, može implementirati što god želi (bilo da je to push ili pull) i infiltrirati se u sustave klastera. Stoga su najvažnije komponente koje treba zaštititi Git repozitorij i CI/CD sustavi, a ne vjerodajnice klastera. Ako imate dobro konfigurirane politike i sigurnosne kontrole za ove vrste sustava, a vjerodajnice klastera ekstrahiraju se samo u cjevovode kao tajne, dodatna sigurnost pristupa povlačenja možda neće biti tako vrijedna kao što se prvobitno mislilo.
Dakle, ako je pristup povlačenja intenzivniji i ne pruža sigurnosnu korist, nije li logično koristiti samo pristup povlačenju? Ali netko bi mogao tvrditi da ste u push pristupu previše vezani za CD sustav i da je možda bolje ne činiti to kako bi u budućnosti bilo lakše provoditi migracije.
Po mom mišljenju (kao i uvijek), trebali biste koristiti ono što je najprikladnije za određeni slučaj ili kombinaciju. Osobno koristim oba pristupa: Weave Flux za implementaciju temeljenu na povlačenju koja uglavnom uključuje naše vlastite usluge, i push pristup s Helmom i dodacima, koji olakšava primjenu Helm grafikona na klaster i omogućuje vam neprimjetno stvaranje tajni. Mislim da nikada neće postojati jedinstveno rješenje prikladno za sve slučajeve, jer uvijek postoji puno nijansi i one ovise o specifičnoj primjeni. Uz to, toplo preporučujem GitOps - uvelike olakšava život i poboljšava sigurnost.
Nadam se da će vam moje iskustvo o ovoj temi pomoći da odlučite koja je metoda prikladnija za vašu vrstu implementacije i bilo bi mi drago čuti vaše mišljenje.
PS Napomena prevoditelja
Loša strana modela povlačenja je ta što je teško staviti renderirane manifeste u Git, ali nema loše strane što cjevovod CD-a u modelu povlačenja živi odvojeno od uvođenja i u biti postaje cjevovod kategorije Kontinuirana primjena. Stoga će biti potrebno još više truda da se prikupi njihov status sa svih implementacija i nekako se omogući pristup zapisnicima/statusu, po mogućnosti s referencom na CD sustav.
U tom smislu, push model nam omogućuje da pružimo barem neka jamstva uvođenja, jer životni vijek cjevovoda može biti jednak životnom vijeku uvođenja.
Isprobali smo oba modela i došli do istih zaključaka kao i autor članka:
- Model povlačenja prikladan je za organiziranje ažuriranja komponenti sustava na velikom broju klastera (vidi. ).
- Push model temeljen na GitLab CI vrlo je prikladan za uvođenje aplikacija pomoću Helmovih grafikona. U isto vrijeme, uvođenje implementacija unutar cjevovoda prati se pomoću alata . Usput, u kontekstu ovog našeg projekta čuli smo stalni “GitOps” kada smo raspravljali o gorućim problemima DevOps inženjera na našem štandu na KubeCon Europe'19.
PPS od prevoditelja
Pročitajte i na našem blogu:
- «»;
- «»;
- «»;
- «".
U anketi mogu sudjelovati samo registrirani korisnici. , molim.
Koristite li GitOps?
-
Da, povuci pristup
-
Da, guraj
-
Da, povuci + gurni
-
Da, još nešto
-
Ne
Glasovalo je 30 korisnika. Suzdržano je bilo 10 korisnika.
Izvor: www.habr.com