Napomena za prijevod.: Nakon nedavne objave o metodama pull i push u GitOps-u, primijetili smo interes za ovaj model u cjelini, no na hrvatskom jeziku gotovo da i nema publikacija na ovu temu (na Habr-u ih jednostavno nema). Stoga smo sretni što vam možemo ponuditi prijevod drugog članka — iako je star gotovo godinu dana! — od tvrtke Weaveworks, čiji je osnivač smislio pojam „GitOps“. U tekstu se objašnjava suština pristupa i ključne razlike u odnosu na postojeće modele.
Prije godinu dana objavili smo . Tada smo govorili o tome kako je tim Weaveworks-a pokrenuo SaaS koji se u potpunosti temelji na Kubernetes-u i razvio set propisnih najboljih praksi za implementaciju, upravljanje i nadzor u cloud native okruženju.
Članak je bio popularan. Drugi ljudi su počeli govoriti o GitOps-u, a pojavili su se i novi alati za , , , , itd. Na našoj web stranici pojavio se publikacija i primjera korištenja GitOps-a. No, neki ljudi su ipak imali pitanja. Kako se ovaj model razlikuje od tradicionalnog i kontinuirane isporuke ()? Je li obavezno koristiti Kubernetes?
Ubrzo smo shvatili da je potrebno novo objašnjenje koje nudi:
- Velik broj primjera i priča;
- Konkretnu definiciju GitOps-a;
- Usporedbu s tradicionalnom kontinuiranom isporukom.
U ovom članku pokušali smo obuhvatiti sve ove teme. Pronaći ćete ažurirani uvod u GitOps i pogled na njega iz perspektive programera i CI/CD-a. Većinom se fokusiramo na Kubernetes, iako se model može generalizirati.
Upoznajte se: GitOps
Zamislite Alisu. Ona upravlja kompanijom Family Insurance koja nudi police zdravstvenog osiguranja, osiguranja automobila, nekretnina i putnog osiguranja ljudima koji su previše zauzeti da bi se sami bavili sitnicama ugovora. Njen posao počeo je kao sporedni projekt dok je Alisa radila u banci kao podatkovna znanstvenica. Jednog dana shvatila je da može koristiti napredne računalne algoritme za učinkovitiju analizu podataka i kreiranje osiguravateljskih paketa. Investitori su financirali projekt i sada njezina kompanija zarađuje više od 20 milijuna dolara godišnje i brzo raste. Trenutno u njoj radi 180 osoba na raznim pozicijama, uključujući tehnološki tim koji se bavi razvojem, održavanjem web stranice, baze podataka i analizom klijentske baze. Tim od 60 ljudi predvodi Bob, tehnički direktor kompanije.
Bobov tim implementira produkcijske sustave u oblaku. Njihove glavne aplikacije rade na GKE-u, koristeći prednosti Kubernetesa u Google Cloud-u. Također koriste razne alate za obradu podataka i analitiku.
Family Insurance prvotno nije planirala koristiti kontejnere, ali je uhvatila entuzijazam oko Dockera. Ubrzo su stručnjaci kompanije otkrili da GKE omogućava jednostavno i lako implementaciju klastera za testiranje novih funkcionalnosti. Dodani su Jenkins za CI i Quay za organizaciju registra kontejnera, napisani su skripti za Jenkins koji su pushali nove kontejnere i konfiguracije u GKE.
Prošlo je određeno vrijeme. Alisa i Bob su se razočarali u performanse odabranog pristupa i njegov utjecaj na poslovanje. Uvođenje kontejnera nije značajno poboljšalo performanse koliko se ekipa nadala. Ponekad su se implementacije rušile, a nije bilo jasno jesu li za to krive promjene u kodu. Također je bilo teško pratiti promjene u konfiguracijama. Često je bilo potrebno stvoriti novi klaster i premjestiti aplikacije u njega, jer je to bilo najlakše rješenje za raspetljavanje kaosa u kojem se sustav našao. Alisa se bojala da će situacija pogoršati kako aplikacija bude rasla (osim toga, bio je na pomolu novi projekt temeljen na strojnom učenju). Bob je automatizirao veći dio posla i nije razumio zašto je pipeline i dalje nestabilan, teško se skalira i povremeno zahtijeva ručnu intervenciju?
Tada su saznali za GitOps. Ovo rješenje se pokazalo upravo onim što im je bilo potrebno za sigurno kretanje unaprijed.
Alisa i Bob već godinama čuju o radnim procesima temeljenim na Gitu, DevOpsu i infrastrukturi kao kodu. Jedinstvenost GitOps-a leži u tome što uvodi niz najboljih praksi — strogo definiranih i normativnih — za implementaciju ovih ideja u kontekstu Kubernetes-a. Ova tema , uključujući i u .
Family Insurance odlučuje implementirati GitOps. Sada kompanija ima automatizirani model operacija, kompatibilan s Kubernetesom, koji kombinira brzinu s stabilnošću, jer su:
- otkrili da je timska produktivnost dvostruko veća i nitko pritom ne poludi;
- prestali su održavati skripte. Umjesto toga, sada se mogu fokusirati na nove značajke i unaprijediti inženjerske metode — na primjer, implementirati kanareke i poboljšati testiranje;
- uspavili proces implementacije — sada se rijetko ruši;
- dobili mogućnost vraćanja implementacija nakon djelomičnih kvarova bez ručne intervencije;
- stvorili veću sigurnost u sustavima isporuke. Alisa i Bob su otkrili da mogu podijeliti tim na grupe koje se bave mikroservisima i rade paralelno;omogu unositi 30-50 promjena u projekt svaki dan trudi svake grupe i isprobavati nove tehnike;
- mogu unositi 30-50 promjena u projekt svaki dan naporima svake grupe i isprobavati nove tehnike;
- lako privlače nove programere u projekt, koji imaju mogućnost implementacije ažuriranja na produkciju putem pull requestova već za nekoliko sati;
- lako prolaze reviziju u okviru SOC2 (u vezi s usklađenošću pružatelja usluga s zahtjevima za sigurnim upravljanjem podacima; više informacija pročitajte, na primjer, — napomena prev.).
Što se dogodilo?
GitOps - to su dvije stvari:
- Model operacija za Kubernetes i cloud native. Pruža skup najboljih praksi za implementaciju, upravljanje i praćenje klastera i aplikacija pakiranih u kontejnere. Elegantan opis u obliku od :
- Put do stvaranja okruženja usmjerenog na programere za upravljanje aplikacijama. Primjenjujemo radni proces Git za operacije i razvoj. Imajte na umu da ne govorimo samo o Git push, već o organizaciji kompletnog skupa CI/CD i UI/UX alata.
Par riječi o Git-u
Ako niste upoznati s kontrolnim sustavima verzija i Git-baziranim radnim procesom, toplo preporučujemo da ih istražite. Isprva se rad s granama i pull requestovima može činiti kao crna magija, ali prednosti nadmašuju uložen trud. Evo za početak.
Kako radi Kubernetes
U našoj priči, Alisa i Bob su se obratili GitOps-u, nakon što su neko vrijeme radili s Kubernetesom. Uistinu, GitOps je usko povezan s Kubernetesom - to je model operacije za infrastrukturu i aplikacije temeljene na Kubernetesu.
Što Kubernetes pruža korisnicima?
Evo nekoliko osnovnih mogućnosti:
- U Kubernetes modelu sve se može opisati u deklarativnom obliku.
- Kubernetes API server prihvaća takvu deklaraciju kao ulazne podatke, a zatim neprekidno pokušava dovesti klaster u stanje opisano u deklaraciji.
- Deklaracije su dovoljne za opisivanje i upravljanje velikim raznolikostima radnih opterećenja - "aplikacija".
- Kao rezultat, promjene u aplikaciji i klasteru se događaju zbog:
- promjena u slikama kontejnera;
- promjena u deklarativnoj specifikaciji;
- grešaka u okruženju - na primjer, padova kontejnera.
Izvrsne sposobnosti Kubernetes-a za konvergenciju
Kada administrator unese promjene u konfiguraciju, Kubernetes orkestrator će ih primjenjivati na klaster sve dok njegovo stanje ne bude blizu nove konfiguracije. Ovaj model radi za bilo koji Kubernetes resurs i može se proširiti pomoću Custom Resource Definitions (CRDs). Stoga, Kubernetes deploymenti imaju sljedeće nevjerojatne karakteristike:
- Automatizacija: ažuriranja Kubernetes-a pružaju mehanizam za automatizaciju procesa primjene promjena na ispravan i pravodoban način.
- Konvergencija: Kubernetes će nastaviti pokušavati ažuriranja dok ne postigne uspjeh.
- Idempotentnost: ponovna primjena konvergencije dovodi do istog rezultata.
- Determinističnost: pri dovoljnoj količini resursa stanje ažurirane grupe ovisi samo o željenom stanju.
Kako funkcionira GitOps
Dovoljno smo naučili o Kubernetesu da objasnimo principe rada GitOps-a.
Vratimo se timovima Family Insurance vezanim za mikroservise. Čime se obično bave? Pogledajte popis u nastavku (ako neki stavci djeluju čudno ili nepoznato — molim vas, suzdržite se od kritike i ostanite s nama). Ovo su samo primjeri radnih procesa temeljenih na Jenkins-u. Postoji mnogo drugih procesa na drugim alatima.
Najvažnije — vidimo da svako ažuriranje završava promjenama u konfiguracijskim datotekama i Git repozitorijima. Te promjene u Gitu dovode do toga da „GitOps operater“ ažurira grupu:
1. Radni proces: „Jenkins Build — master grana».
Popis zadataka:
- Jenkins šalje tagirane slike u Quay;
- Jenkins šalje konfiguraciju i Helm grafikon u master skladište;
- Oblačna funkcija kopira konfiguraciju i grafikone iz master skladišta u Git repozitorij master;
- GitOps operater ažurira grupu.
2. Jenkins Build — release ili hotfix grana:
- Jenkins šalje netagirane slike u Quay;
- Jenkins šalje konfiguraciju i Helm grafikone u staging skladište;
- Oblačna funkcija kopira konfiguraciju i grafikone iz staging skladišta u Git repozitorij staging;
- GitOps operater ažurira grupu.
3. Jenkins Build — develop ili feature grana:
- Jenkins šalje netagirane slike u Quay;
- Jenkins šalje konfiguraciju i Helm grafikone u develop skladište;
- Oblačna funkcija kopira konfiguraciju i grafikone iz develop skladišta u Git repozitorij develop;
- GitOps operater ažurira grupu.
4. Dodavanje novog klijenta:
- Menadžer ili administrator (LCM/ops) pokreće Gradle za inicijalno raspoređivanje i postavljanje mrežnih balansirajućih sistema (NLB);
- LCM/ops commit-a novu konfiguraciju za pripremu deploymenta za ažuriranja;
- GitOps operater ažurira grupu.
Kratak opis GitOps-a
- Opišite željeno stanje cijelog sustava koristeći deklarativne specifikacije za svako okruženje (u našoj priči Bobov tim definira svu konfiguraciju sustava u Gitu).
- Git repozitorij je jedini izvor istine u vezi željenog stanja cijelog sustava.
- Sve promjene u željenom stanju događaju se putem commitova u Gitu.
- Sve željene karakteristike klastera također su uočljive u samom klasteru. Tako možemo odrediti da li se željeno i uočeno stanje poklapaju (konvergiraju, converge) ili se razlikuju (divergiraju, diverge) od željenog i uočenog stanja.
- Ako se željeno i uočeno stanje razlikuju, tada:
- Postoji mehanizam konvergencije koji će prije ili kasnije automatski sinkronizirati ciljno i uočeno stanje. Unutar klastera time se bavi Kubernetes.
- Proces započinje odmah s obavijesti „promjena potvrđena”.
- Nakon određenog prilagodljivog vremenskog perioda može biti poslana obavijest „diff”, ako se stanja razlikuju.
- Tako svi commitovi u Gitu uzrokuju provjerljive i idempotentne ažuriranja u klasteru.
- Povratak je konvergencija prema ranije željenom stanju.
- Konvergencija je konačna. O njoj svjedoče:
- Nema obavijesti „diff” tijekom određenog vremenskog razdoblja.
- Obavijest „konvergirano” (na primjer, webhook, događaj Git writeback).
Što je divergenicija?
Ponovimo još jednom: sva željena svojstva klastera moraju biti uočljiva u samom klasteru.
Nekoliko primjera divergenicije:
- Promjena u datoteci konfiguracije zbog spajanja grana u Gitu.
- Promjena u datoteci konfiguracije zbog commit-a u Gitu, napravljenog putem GUI klijenta.
- Višestruke promjene u željenom stanju zbog PR-a u Gitu s naknadnom izgradnjom kontejnerske slike i promjenama u konfiguraciji.
- Promjena stanja klastera zbog greške, sukoba resursa koji vodi do „lošeg ponašanja”, ili jednostavno slučajne odstupanja od originalnog stanja.
Što predstavlja mehanizam konvergencije?
Nekoliko primjera:
- Za kontejnere i klastere mehanizam konvergencije osigurava Kubernetes.
- Isti mehanizam se može koristiti za upravljanje aplikacijama i konstrukcijama temeljenim na Kubernetesu (npr. Istio i Kubeflow).
- Mehanizam za upravljanje radnom interakcijom između Kubernetes-a, repozitorija slika i Git-a pruža , koji je deo .
- Za osnovne mašine, mehanizam konvergencije mora biti deklarativan i autonoman. Naše iskustvo ukazuje na to da najbliže ovom definiciji, iako ipak zahteva ljudsku kontrolu. U tom smislu, GitOps proširuje tradiciju Infrastructure as Code.
GitOps povezuje Git s odličnim mehanizmom konvergencije Kubernetes-a, nudeći model za eksploataciju.
GitOps nam omogućava da kažemo: automatski se kontrolišu samo oni sistemi koje možemo opisati i posmatrati.
GitOps je namenjen celom cloud native staku (na primer, Terraform i slično)
GitOps nije samo Kubernetes. Želimo da čitav sistem bude upravljan deklarativno i da koristi konvergenciju. Pod celim sistemom podrazumevamo skup okruženja koja rade sa Kubernetes-om — na primer, 'dev cluster 1', 'production' i slično. U svako okruženje ulaze mašine, klasteri, aplikacije i interfejsi za spoljne usluge koje pružaju podatke, monitoring i slično.
Primetite koliko je u ovom slučaju Terraform važan za problem bootstrapping-a. Kubernetes mora biti negde postavljen, a korišćenje Terraforma znači da možemo primeniti iste radne tokove GitOps-a za izgradnju upravljačkog sloja koji leži ispod Kubernetes-a i aplikacija. Ovo je korisna najbolja praksa.
Velika pažnja posvećena je primeni koncepta GitOps na slojeva iznad Kubernetes-a. Do sada postoje GitOps rešenja za Istio, Helm, Ksonnet, OpenFaaS i Kubeflow, kao i, na primer, za Pulumi, koji stvaraju sloj za razvoj aplikacija pod cloud native.
Kubernetes CI/CD: poređenje GitOps-a s drugim pristupima
Kao što je rečeno, GitOps je dve stvari:
- Model eksploatacije za Kubernetes i cloud native, opisano gore.
- Put ka organizaciji orijentisanoj na programere za upravljanje aplikacijama.
Za mnoge, GitOps je pre svega radni tok zasnovan na Git push-evima. Takođe nam se sviđa. Ali to nije sve: pogledajmo sada CI/CD pipelines.
GitOps omogućava kontinuirano razmeštanje (CD) pod Kubernetes-om
GitOps nudi mehanizam kontinuiranog razmeštanja koji eliminiše potrebu za posebnim 'sistemima za upravljanje razmeštanjem'. Sav posao obavlja Kubernetes.
- Ažuriranje aplikacije zahtijeva ažuriranje u Git-u. Ovo je transakcijsko ažuriranje do željenog stanja. „Implementacija“ zatim se provodi unutar klastera od strane samog Kubernetesa na temelju ažuriranog opisa.
- Zbog specifičnosti rada Kubernetesa, ta ažuriranja su konvergenta. Tako se omogućava mehanizam za kontinuiranu implementaciju, gdje su sva ažuriranja atomska.
- Napomena: nudi GitOps-operator koji integrira Git i Kubernetes i omogućava izvršavanje CD-a usklađivanjem željenog i trenutnog stanja klastera.
Bez kubectl i skripti
Trebali bismo izbjegavati korištenje Kubectl-a za ažuriranje klastera, a posebno skripti za grupiranje kubectl naredbi. Umjesto toga, uz pomoć GitOps pipeline-a korisnik može ažurirati svoj Kubernetes klaster putem Gita.
Prednosti uključuju:
- Ispravnost. Grupa ažuriranja može se primijeniti, konvergirati i konačno validirati, što nas približava cilju atomskog implementiranja. S druge strane, korištenje skripti ne pruža nikakve garancije konvergencije (više o tome u nastavku).
- Sigurnost. Kelsey Hightower: „Ograničite pristup klasteru Kubernetesa automatizacijskim alatima i administratorima čija je odgovornost njegovu dijagnostiku ili održavanje funkcionalnosti“. Također pogledajte o sigurnosti i usklađenosti sa tehničkim specifikacijama, kao i kroz krađu vjerodajnica iz nepažljivo sastavljenog Jenkins skripta.
- Korisničko iskustvo. Kubectl otkriva mehaniku objektne modele Kubernetesa, koja je vrlo složena. U idealnom slučaju, korisnici bi trebali komunicirati sa sustavom na višem razini apstrakcije. Ovdje se ponovno referiram na Kelsey-a i preporučujem da pogledate .
Razlika između CI i CD
GitOps poboljšava postojeće CI/CD modele.
Moderni CI server je alat za orkestraciju. Konkretno, to je alat za orkestraciju CI pipeline-a. Oni uključuju build, test, merge to trunk itd. CI serveri automatiziraju upravljanje složenim višekratnim pipeline-ima. Čest je nagon da se napravi skripta za skup ažuriranja Kubernetesa i izvrši se kao dio pipeline-a za push promjena u klaster. Uistinu, mnogi stručnjaci to čine. Međutim, to nije optimalno, i evo zašto.
CI treba koristiti za primjenu ažuriranja u trunk, a Kubernetes klastra treba se mijenjati na temelju tih ažuriranja radi upravljanja CD "unutarnje". Ovo nazivamo , za razliku od CI push-modela. CD je dio runtime-orchestracije.
Zašto CI serveri ne bi trebali raditi CD putem izravnih ažuriranja u Kubernetes
Ne koristiti CI server za orkestraciju izravnih ažuriranja u Kubernetes kao set CI poslova. Ovo je antipatron, o tome smo na našem blogu.
Vratimo se Alisi i Bobu.
S kojim problemima su se suočili? CI server Boba nanosi promjene u klaster, ali ako tijekom procesa dođe do pada, Bob neće znati u kojem je stanju (ili bi trebao biti) klaster i kako ga popraviti. Isto vrijedi i u slučaju uspjeha.
Pretpostavimo da je Bobov tim izgradio novu sliku i zatim ažurirao svoje deployment-e kako bi implementirao sliku (sve to iz CI pipeline-a).
Ako se slika normalno izgradi, ali pipeline padne, timu će biti potrebno utvrditi:
- Je li ažuriranje implementirano?
- Pokrećemo li novu verziju? Hoće li to dovesti do neopravdanih nuspojava — s mogućnošću da dobijemo dvije verzije iste nepromijenjene slike?
- Trebamo li čekati sljedeće ažuriranje prije nego što pokrenemo verziju?
- Što točno nije bilo u redu? Koje korake treba ponoviti (i koji od njih su sigurno ponovljivi)?
Organizacija radnog procesa temeljenog na Gitu ne jamči da se Bobov tim neće suočiti s ovim problemima. I dalje mogu pogriješiti s push-om commita, s oznakom ili nekim drugim parameterom; međutim, ovaj pristup je ipak mnogo bliži jasnom svemu ili ništa.
Ukratko, evo zašto CI serveri ne bi trebali raditi CD:
- Skripte za ažuriranje nisu uvijek deterministične; lako je napraviti greške u njima.
- CI serveri se ne konvergiraju u deklarativni model klastera.
- Teško je jamčiti idempotentnost. Korisnici trebaju razumjeti duboku semantiku sustava.
- Teže se oporaviti od djelomičnog kvara.
Napomena o Helm-u: ako želite koristiti Helm, preporučujemo da ga spojite s GitOps operatorom, kao što je . To će pomoći osigurati konvergenciju. Sam po sebi Helm nije ni deterministički ni atomski.
GitOps kao najbolji način za provođenje Continuous Delivery za Kubernetes
Tim Alice i Boba implementira GitOps i otkriva da je mnogo lakše raditi s softverskim proizvodima, održavati visoku produktivnost i stabilnost. Završimo ovaj članak ilustracijama koje prikazuju kako izgleda njihov novi pristup. Imajte na umu da se uglavnom bavimo aplikacijama i servisima, no GitOps se može koristiti za upravljanje cijelom platformom.
Model rada za Kubernetes
Pogledajte sljedeću dijagramu. Ona prikazuje Git i spremište slika kontejnera kao zajedničke resurse za dva orkestrirana životna ciklusa:
- Pipeline kontinuirane integracije, koji čita i zapisuje datoteke u Git i može ažurirati spremište kontejnerskih slika.
- Pipeline Runtime GitOps, koji kombinira implementaciju s upravljanjem i nadgledanjem. On čita i zapisuje datoteke u Git i može učitati slike kontejnera.
Koji su glavni zaključci?
- Razdvajanje problema: Imajte na umu da oba pipelinea mogu razmjenjivati podatke samo ažuriranjem Gita ili spremišta slika. Drugim riječima, postoji vatrozid između CI i runtime okruženja. Nazivamo ga 'vatrozidom nepromjenjivosti' (immutability firewall), budući da sve novosti u spremištima stvaraju nove verzije. Za dodatne informacije o ovoj temi, obratite se slajdovima 72-87 .
- Može se koristiti bilo koji CI i Git poslužitelj: GitOps radi s bilo kojim komponentama. Možete nastaviti koristiti svoje omiljene CI i Git poslužitelje, spremišta slika i testne skupove. Gotovo svi ostali alati za kontinuiranu isporuku na tržištu zahtijevaju vlastiti CI/Git poslužitelj ili spremište slika. To može postati ograničavajući faktor u razvoju cloud native. U slučaju GitOps-a možete koristiti alate na koje ste navikli.
- Događaji kao alat za integraciju: Čim se podaci u Gitu ažuriraju, Weave Flux (ili Weave Cloud operator) obavještava o tome runtime. Svaki put kada Kubernetes prihvati skup promjena, Git se ažurira. To osigurava jednostavan model integracije za organizaciju radnih procesa za GitOps, kao što je prikazano u nastavku.
Zaključak
GitOps pruža značajna jamstva ažuriranja potrebna svakom modernom CI/CD alatu:
- automacija;
- konvergencija;
- idempotentnost;
- determinizam.
To je važno jer nudi operativni model za programere u području cloud native.
- Tradicionalni alati za upravljanje i nadzor sustava povezani su s operativnim timovima koji djeluju unutar runbook-a (skupa rutinskih postupaka i operacija — nap. prev.), vezanog uz određeni deployment.
- U upravljanju cloud native sustavima, alati za nadzor su najbolji način za procjenu rezultata isporuka kako bi se tim programera mogao brzo prilagoditi.
Zamislite brojne klastere rasprostranjene preko raznih oblaka i mnoštvo usluga s vlastitim timovima i planovima isporuka. GitOps nudi skalabilan model za upravljanje tom raznolikošću.
P.S. od prevodioca
Pročitajte i na našem blogu:
- «»;
- «»;
- «».
Samo registrirani korisnici mogu sudjelovati u anketi. , molimo.
Jeste li znali za GitOps prije nego što su ova dva prijevoda objavljena na Habra?
Da, sve sam znao(la)
Samo povremeno
Ne
Glasalo je 35 korisnika. Uzdržalo se 10 korisnika.
Izvor: habr.com
