Bilješka. prev.: Nakon nedavne objave o metodama povlačenja i guranja u GitOpsu, vidjeli smo interes za ovaj model općenito, ali bilo je vrlo malo publikacija na ruskom jeziku o ovoj temi (jednostavno ih nema na Habréu). Stoga vam sa zadovoljstvom možemo ponuditi prijevod drugog članka - doduše prije gotovo godinu dana! — iz Weaveworksa, čiji je voditelj skovao izraz "GitOps". U tekstu se objašnjava bit pristupa i ključne razlike u odnosu na postojeće.
Prije godinu dana objavili smo . Tada smo podijelili kako je tim Weaveworksa pokrenuo SaaS koji se u potpunosti temelji na Kubernetesu i razvio skup propisanih najboljih praksi za implementaciju, upravljanje i nadzor u prirodnom okruženju oblaka.
Članak se pokazao popularnim. Drugi su ljudi počeli govoriti o GitOpsu i počeli objavljivati nove alate za , , , , i tako dalje. Pojavio se na našoj web stranici publikacije i GitOps slučajevi korištenja. Ali neki ljudi još uvijek imaju pitanja. Kako se model razlikuje od tradicionalnog? i kontinuirana isporuka ()? Je li potrebno koristiti Kubernetes?
Ubrzo smo shvatili da je potreban novi opis koji nudi:
- Velik broj primjera i priča;
- Specifična definicija GitOps-a;
- Usporedba s tradicionalnom kontinuiranom isporukom.
U ovom smo članku pokušali pokriti sve te teme. Pruža ažurirani uvod u GitOps i razvojnu i CI/CD perspektivu. Prvenstveno se fokusiramo na Kubernetes, iako se model može generalizirati.
Upoznajte GitOps
Zamisli Alice. Ona vodi obiteljsko osiguranje koje nudi zdravstveno, automobilsko, kućno i putno osiguranje ljudima koji su prezaposleni da bi sami shvatili sitnice i nedostatke ugovora. Njezin je posao započeo kao sporedni projekt dok je Alice radila u banci kao podatkovna znanstvenica. Jednog je dana shvatila da može koristiti napredne računalne algoritme za učinkovitiju analizu podataka i formuliranje paketa osiguranja. Investitori su financirali projekt, a sada njezina tvrtka donosi više od 20 milijuna dolara godišnje i brzo raste. Trenutno zapošljava 180 ljudi na različitim radnim mjestima. To uključuje tehnološki tim koji razvija, održava web stranicu, bazu podataka i analizira korisničku bazu. Tim od 60 ljudi vodi Bob, tehnički direktor tvrtke.
Bobov tim postavlja proizvodne sustave u oblak. Njihove temeljne aplikacije rade na GKE-u, koristeći prednosti Kubernetesa na Google Cloudu. Osim toga, u svom radu koriste različite podatkovne i analitičke alate.
Obiteljsko osiguranje nije namjeravalo koristiti kontejnere, već ga je zahvatio Docker entuzijazam. Tvrtka je ubrzo otkrila da GKE olakšava implementaciju klastera za testiranje novih značajki. Dodani su Jenkins za CI i Quay za organiziranje registra spremnika, napisane su skripte za Jenkins koje su gurnule nove spremnike i konfiguracije u GKE.
Prošlo je neko vrijeme. Alice i Bob bili su razočarani izvedbom svog odabranog pristupa i njegovim utjecajem na poslovanje. Uvođenje spremnika nije poboljšalo produktivnost onoliko koliko se tim nadao. Ponekad bi se implementacije pokvarile i bilo je nejasno jesu li krive promjene koda. Također se pokazalo da je teško pratiti promjene konfiguracije. Često je bilo potrebno napraviti novi klaster i u njega premjestiti aplikacije, jer je to bio najlakši način da se eliminira nered u koji se sustav pretvorio. Alice se bojala da će se situacija pogoršati kako se aplikacija razvija (osim toga, spremao se novi projekt temeljen na strojnom učenju). Bob je automatizirao većinu posla i nije razumio zašto je cjevovod još uvijek nestabilan, nije dobro skaliran i zahtijeva povremenu ručnu intervenciju?
Tada su saznali za GitOps. Pokazalo se da je ova odluka upravo ono što im je trebalo da samouvjereno krenu naprijed.
Alice i Bob već godinama slušaju o Gitu, DevOpsu i infrastrukturi kao tijeku rada koda. Ono što je jedinstveno kod GitOpsa je to što donosi skup najboljih praksi — i definitivnih i normativnih — za implementaciju ovih ideja u kontekstu Kubernetesa. Ova tema , uključujući u .
Obiteljsko osiguranje odlučuje implementirati GitOps. Tvrtka sada ima model automatiziranog rada koji je kompatibilan s Kubernetesom i kombajnima brzina s stabilnostzato jer oni:
- otkrili da se produktivnost tima udvostručila, a da nitko nije poludio;
- prestao posluživati skripte. Umjesto toga, sada se mogu usredotočiti na nove značajke i poboljšati metode inženjeringa - na primjer, uvođenje Canary rollouts i poboljšanje testiranja;
- poboljšali smo proces implementacije tako da se rijetko kvari;
- dobili priliku obnoviti implementacije nakon djelomičnih kvarova bez ručne intervencije;
- kupljeno rabljenoоVeće povjerenje u sustave isporuke. Alice i Bob otkrili su da mogu podijeliti tim u mikroservisne timove koji rade paralelno;
- može napraviti 30-50 izmjena u projektu svaki dan kroz napore svake grupe i isprobati nove tehnike;
- lako je privući nove programere u projekt, koji imaju priliku uvesti ažuriranja u produkciju pomoću zahtjeva za povlačenjem unutar nekoliko sati;
- lako prolaze reviziju u okviru SOC2 (za usklađenost pružatelja usluga sa zahtjevima za sigurno upravljanje podacima; pročitajte više, na primjer, - cca. prev.).
Što se dogodilo?
GitOps su dvije stvari:
- Operativni model za Kubernetes i izvorni oblak. Pruža skup najboljih praksi za implementaciju, upravljanje i nadzor kontejnerskih klastera i aplikacija. Elegantna definicija u obliku iz :
- Put do stvaranja okruženja za upravljanje aplikacijama usmjerenog na programere. Tijek rada Git primjenjujemo i na operacije i na razvoj. Imajte na umu da se ne radi samo o Git push-u, već o organiziranju cijelog skupa CI/CD i UI/UX alata.
Nekoliko riječi o Gitu
Ako niste upoznati sa sustavima kontrole verzija i tijek rada koji se temelji na Gitu, preporučujemo da naučite o njima. Rad s ograncima i zahtjevima za povlačenjem može se isprva činiti poput crne magije, ali prednosti su vrijedne truda. Ovdje početi.
Kako radi Kubernetes
U našoj priči, Alice i Bob okrenuli su se GitOpsu nakon što su neko vrijeme radili s Kubernetesom. Doista, GitOps je usko povezan s Kubernetesom - to je operativni model za infrastrukturu i aplikacije temeljene na Kubernetesu.
Što Kubernetes daje korisnicima?
Evo nekoliko glavnih značajki:
- U Kubernetes modelu sve se može opisati u deklarativnom obliku.
- Kubernetes API poslužitelj uzima ovu deklaraciju kao ulaz i zatim kontinuirano pokušava dovesti klaster u stanje opisano u deklaraciji.
- Deklaracije su dovoljne za opisivanje i upravljanje širokim spektrom radnih opterećenja—"aplikacija".
- Kao rezultat toga, dolazi do promjena u aplikaciji i klasteru zbog:
- promjene u slikama spremnika;
- izmjene deklarativne specifikacije;
- pogreške u okruženju - na primjer, pad kontejnera.
Kubernetesove velike mogućnosti konvergencije
Kada administrator izvrši promjene konfiguracije, Kubernetes orkestrator će ih primijeniti na klaster sve dok je njegovo stanje neće se približiti novoj konfiguraciji. Ovaj model radi za bilo koji Kubernetes resurs i može se proširiti s prilagođenim definicijama resursa (CRD). Stoga Kubernetes implementacije imaju sljedeća izvrsna svojstva:
- Automatizacija: Ažuriranja Kubernetesa pružaju mehanizam za automatizaciju procesa elegantne i pravovremene primjene promjena.
- Konvergencija: Kubernetes će nastaviti s pokušajima ažuriranja dok ne uspije.
- Idempotencija: Ponovljene primjene konvergencije dovode do istog rezultata.
- Determinizam: Kada su resursi dovoljni, stanje ažuriranog klastera ovisi samo o željenom stanju.
Kako GitOps radi
Naučili smo dovoljno o Kubernetesu da objasnimo kako GitOps funkcionira.
Vratimo se timovima za mikroservise Obiteljskog osiguranja. Što obično moraju raditi? Pogledajte popis u nastavku (ako vam se neke stavke u njemu čine čudnim ili nepoznatim, molimo vas da prestanete s kritiziranjem i ostanite s nama). Ovo su samo primjeri tijekova rada temeljenih na Jenkinsu. Postoje mnogi drugi procesi kada radite s drugim alatima.
Glavna stvar je da vidimo da svako ažuriranje završava promjenama konfiguracijskih datoteka i Git repozitorija. Ove promjene u Gitu uzrokuju da "GitOps operator" ažurira klaster:
1. Proces rada: "Jenkins build - master grana".
Lista zadataka:
- Jenkins gura označene slike na Quay;
- Jenkins gura konfiguracijske i Helm karte u glavnu kantu za pohranu;
- Funkcija oblaka kopira konfiguraciju i grafikone iz glavne kante za pohranu u glavno Git spremište;
- Operator GitOps ažurira klaster.
2. Jenkins build - izdanje ili ogranak hitnog popravka:
- Jenkins gura neoznačene slike na Quay;
- Jenkins gura konfiguracijske i Helm karte u spremnik za pripremnu pohranu;
- Funkcija oblaka kopira konfiguraciju i grafikone iz kante za pripremnu pohranu u pripremnu Git repozitorij;
- Operator GitOps ažurira klaster.
3. Jenkins build - razvoj ili predstavljanje grane:
- Jenkins gura neoznačene slike na Quay;
- Jenkins gura konfiguracijske i Helm karte u spremnik za razvoj;
- Funkcija oblaka kopira konfiguraciju i grafikone iz razvojne kante za pohranu u razvojno Git spremište;
- Operator GitOps ažurira klaster.
4. Dodavanje novog klijenta:
- Upravitelj ili administrator (LCM/ops) poziva Gradle da početno implementira i konfigurira balansere mrežnog opterećenja (NLB);
- LCM/ops objavljuje novu konfiguraciju kako bi pripremio implementaciju za ažuriranja;
- Operator GitOps ažurira klaster.
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 cijelu konfiguraciju sustava u Gitu).
- Git repozitorij jedini je izvor istine o željenom stanju cijelog sustava.
- Sve promjene željenog stanja vrše se putem komitiranja u Gitu.
- Svi željeni parametri klastera također su vidljivi u samom klasteru. Na taj način možemo utvrditi koincidiraju li (konvergiraju, konvergirati) ili se razlikuju (razilaze se, razilaziti se) željena i promatrana stanja.
- Ako se željeno i promatrano stanje razlikuju, tada:
- Postoji mehanizam konvergencije koji prije ili kasnije automatski sinkronizira ciljno i promatrano stanje. Unutar klastera, Kubernetes to radi.
- Proces počinje odmah s upozorenjem "izvršena promjena".
- Nakon određenog vremenskog razdoblja koje se može konfigurirati, može se poslati upozorenje "diff" ako su stanja različita.
- Na ovaj način, sva predaja u Gitu uzrokuje provjerljiva i idempotentna ažuriranja klastera.
- Vraćanje je konvergencija u prethodno željeno stanje.
- Konvergencija je konačna. Njegovu pojavu označavaju:
- Nema upozorenja o razlikama određeno vrijeme.
- "konvergirano" upozorenje (npr. webhook, Git povratni događaj).
Što je divergencija?
Ponovimo opet: sva željena svojstva klastera moraju biti vidljiva u samom klasteru.
Neki primjeri divergencije:
- Promjena konfiguracijske datoteke zbog spajanja grana u Gitu.
- Promjena u konfiguracijskoj datoteci zbog Git predaje koju je izvršio GUI klijent.
- Višestruke promjene u željeno stanje zbog PR-a u Gitu nakon čega slijedi izgradnja slike spremnika i promjena konfiguracije.
- Promjena stanja klastera zbog pogreške, sukoba resursa koji rezultira "lošim ponašanjem" ili jednostavno slučajnim odstupanjem od izvornog stanja.
Koji je mehanizam konvergencije?
Nekoliko primjera:
- Za spremnike i klastere mehanizam konvergencije osigurava Kubernetes.
- Isti mehanizam može se koristiti za upravljanje aplikacijama i dizajnom temeljenim na Kubernetesu (kao što su Istio i Kubeflow).
- Osigurava mehanizam za upravljanje operativnom interakcijom između Kubernetesa, repozitorija slika i Gita , koji je dio .
- Za osnovne strojeve, mehanizam konvergencije mora biti deklarativan i autonoman. Iz vlastitog iskustva to možemo reći najbliže ovoj definiciji, ali još uvijek zahtijeva ljudsku kontrolu. U tom smislu, GitOps proširuje tradiciju Infrastrukture kao koda.
GitOps kombinira Git s izvrsnim motorom konvergencije Kubernetesa kako bi pružio model za iskorištavanje.
GitOps nam omogućuje da kažemo: Samo oni sustavi koji se mogu opisati i promatrati mogu biti automatizirani i kontrolirani.
GitOps je namijenjen cijelom izvornom stogu oblaka (na primjer, Terraform, itd.)
GitOps nije samo Kubernetes. Želimo da se cijeli sustav vodi deklarativno i koristi konvergenciju. Pod cijelim sustavom mislimo na kolekciju okruženja koja rade s Kubernetesom - na primjer, “dev cluster 1”, “production” itd. Svako okruženje uključuje strojeve, klastere, aplikacije, kao i sučelja za vanjske usluge koje pružaju podatke, nadzor i itd.
Primijetite koliko je Terraform važan za problem pokretanja u ovom slučaju. Kubernetes se mora negdje implementirati, a korištenje Terraforma znači da možemo primijeniti iste GitOps tijekove rada za stvaranje kontrolnog sloja koji podupire Kubernetes i aplikacije. Ovo je korisna najbolja praksa.
Postoji jak fokus na primjeni GitOps koncepata na slojeve na vrhu Kubernetesa. Trenutačno postoje rješenja tipa GitOps za Istio, Helm, Ksonnet, OpenFaaS i Kubeflow te, primjerice, za Pulumi, koja stvaraju sloj za razvoj aplikacija za cloud native.
Kubernetes CI/CD: usporedba GitOpsa s drugim pristupima
Kao što je rečeno, GitOps su dvije stvari:
- Gore opisan operativni model za Kubernetes i izvorni oblak.
- Put do okruženja za upravljanje aplikacijama usmjerenog na programere.
Za mnoge je GitOps primarno tijek rada temeljen na Git push-ovima. I on nam se sviđa. Ali to nije sve: pogledajmo sada CI/CD cjevovode.
GitOps omogućuje kontinuiranu implementaciju (CD) za Kubernetes
GitOps nudi mehanizam kontinuirane implementacije koji eliminira potrebu za zasebnim "sustavima za upravljanje implementacijom". Kubernetes obavlja sav posao umjesto vas.
- Ažuriranje aplikacije zahtijeva ažuriranje u Gitu. Ovo je ažuriranje transakcije u željeno stanje. "Raspoređivanje" zatim obavlja sam Kubernetes unutar klastera na temelju ažuriranog opisa.
- Zbog prirode načina na koji Kubernetes funkcionira, ova su ažuriranja konvergentna. Ovo pruža mehanizam za kontinuiranu implementaciju u kojoj su sva ažuriranja atomska.
- Napomena: nudi GitOps operator koji integrira Git i Kubernetes i omogućuje izvođenje CD-a usklađivanjem željenog i trenutnog stanja klastera.
Bez kubectla i skripti
Trebali biste izbjegavati korištenje Kubectla za ažuriranje klastera, a posebno izbjegavajte korištenje skripti za grupiranje kubectl naredbi. Umjesto toga, s GitOps cjevovodom, korisnik može ažurirati svoj Kubernetes klaster putem Gita.
Pogodnosti uključuju:
- Pravo. Skupina ažuriranja može se primijeniti, konvergirati i konačno potvrditi, približavajući nas cilju atomske implementacije. Nasuprot tome, korištenje skripti ne daje nikakvo jamstvo konvergencije (više o tome u nastavku).
- sigurnosti. Kelsey Hightower: “Ograničite pristup svom Kubernetes klasteru alatima za automatizaciju i administratorima koji su odgovorni za otklanjanje pogrešaka ili održavanje.” vidi također o sigurnosti i usklađenosti s tehničkim specifikacijama, kao i krađom vjerodajnica iz nemarno napisanog Jenkinsovog scenarija.
- Korisničko iskustvo. Kubectl izlaže mehaniku Kubernetes objektnog modela, koja je prilično složena. U idealnom slučaju, korisnici bi trebali komunicirati sa sustavom na višoj razini apstrakcije. Ovdje ću se opet pozvati na Kelsey i preporučiti gledanje .
Razlika između CI i CD
GitOps poboljšava postojeće CI/CD modele.
Moderni CI poslužitelj je alat za orkestraciju. Konkretno, to je alat za orkestriranje CI cjevovoda. To uključuje izgradnju, testiranje, spajanje u trunk, itd. CI poslužitelji automatiziraju upravljanje složenim cjevovodima u više koraka. Uobičajeno je iskušenje skriptirati skup Kubernetes ažuriranja i pokrenuti ga kao dio cjevovoda za stavljanje promjena u klaster. Doista, to je ono što mnogi stručnjaci rade. Međutim, to nije optimalno, a evo i zašto.
CI bi se trebao koristiti za slanje ažuriranja u deblo, a Kubernetes klaster bi se trebao promijeniti na temelju tih ažuriranja za interno upravljanje CD-om. Mi to zovemo , za razliku od CI push modela. CD je dio izvedbena orkestracija.
Zašto CI poslužitelji ne bi trebali raditi CD-ove putem izravnih ažuriranja u Kubernetesu
Nemojte koristiti CI poslužitelj za upravljanje izravnim ažuriranjima Kubernetesa kao skupa CI poslova. Ovo je anti-obrazac o kojem govorimo na svom blogu.
Vratimo se Alice i Bobu.
S kakvim su se problemima suočili? Bobov CI poslužitelj primjenjuje promjene na klaster, ali ako se sruši u procesu, Bob neće znati u kakvom je stanju (ili bi trebao biti) klaster niti kako to popraviti. Isto vrijedi i u slučaju uspjeha.
Pretpostavimo da je Bobov tim napravio novu sliku, a zatim zakrpao svoje implementacije kako bi implementirao sliku (sve iz CI cjevovoda).
Ako se slika normalno izgradi, ali cjevovod zakaže, tim će morati otkriti:
- Je li ažuriranje izašlo?
- Pokrećemo li novu verziju? Hoće li to dovesti do nepotrebnih nuspojava - s mogućnošću da imate dvije verzije iste nepromjenjive slike?
- Trebamo li pričekati sljedeće ažuriranje prije pokretanja izgradnje?
- Što je točno pošlo po zlu? Koje korake je potrebno ponoviti (a koje je sigurno ponoviti)?
Uspostava tijeka rada temeljenog na Gitu ne jamči da se Bobov tim neće susresti s ovim problemima. I dalje mogu pogriješiti s pritiskom na uvrštavanje, oznakom ili nekim drugim parametrom; međutim, ovaj je pristup još uvijek puno bliži eksplicitnom pristupu sve ili ništa.
Da rezimiramo, evo zašto CI poslužitelji ne bi trebali raditi s CD-om:
- Skripte ažuriranja nisu uvijek determinističke; U njima je lako pogriješiti.
- CI poslužitelji ne konvergiraju prema modelu deklarativnog klastera.
- Teško je jamčiti idempotencija. Korisnici moraju razumjeti duboku semantiku sustava.
- Teže se oporaviti od djelomičnog kvara.
Napomena o Helmu: Ako želite koristiti Helm, preporučujemo da ga kombinirate s GitOps operatorom kao što je . To će pomoći osigurati konvergenciju. Sam Helm nije niti deterministički niti atomski.
GitOps kao najbolji način za implementaciju kontinuirane isporuke za Kubernetes
Tim Alice i Boba implementira GitOps i otkriva da je postalo mnogo lakše raditi sa softverskim proizvodima, održavati visoku izvedbu i stabilnost. Završimo ovaj članak ilustracijom koja pokazuje kako izgleda njihov novi pristup. Imajte na umu da uglavnom govorimo o aplikacijama i uslugama, ali GitOps se može koristiti za upravljanje cijelom platformom.
Operativni model za Kubernetes
Pogledajte sljedeći dijagram. Predstavlja Git i spremište slika spremnika kao zajedničke resurse za dva orkestrirana životna ciklusa:
- Kontinuirani integracijski cjevovod koji čita i piše datoteke u Git i može ažurirati spremište slika spremnika.
- Runtime GitOps cjevovod koji kombinira implementaciju s upravljanjem i mogućnošću promatranja. Čita i piše datoteke u Git i može preuzeti slike spremnika.
Koji su glavni nalazi?
- Razdvajanje briga: Imajte na umu da oba cjevovoda mogu komunicirati samo ažuriranjem Gita ili repozitorija slika. Drugim riječima, postoji vatrozid između CI i runtime okruženja. Mi to zovemo "vatrozid nepromjenjivosti" (vatrozid nepromjenjivosti), budući da sva ažuriranja repozitorija stvaraju nove verzije. Za više informacija o ovoj temi pogledajte slajdove 72-87 .
- Možete koristiti bilo koji CI i Git poslužitelj: GitOps radi s bilo kojom komponentom. Možete nastaviti koristiti svoje omiljene CI i Git poslužitelje, spremišta slika i testne pakete. 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 čimbenik u razvoju izvornog oblaka. Uz GitOps možete koristiti poznate alate.
- Događaji kao alat integracije: Čim se podaci u Gitu ažuriraju, Weave Flux (ili operator Weave Cloud) obavještava vrijeme izvođenja. Kad god Kubernetes prihvati skup promjena, Git se ažurira. Ovo pruža jednostavan integracijski model za organiziranje radnih procesa za GitOps, kao što je prikazano u nastavku.
Zaključak
GitOps pruža snažna jamstva ažuriranja koja su potrebna za svaki moderni CI/CD alat:
- automatizacija;
- konvergencija;
- idempotencija;
- determinizam.
Ovo je važno jer nudi operativni model za izvorne programere u oblaku.
- Tradicionalni alati za upravljanje i nadzor sustava povezani su s operativnim timovima koji rade unutar runbook-a (skup rutinskih postupaka i operacija - pribl. prijevod), vezan uz određenu implementaciju.
- U izvornom upravljanju oblakom, alati za promatranje najbolji su način za mjerenje rezultata implementacija kako bi razvojni tim mogao brzo reagirati.
Zamislite mnoge klastere raštrkane po različitim oblacima i mnoge usluge s vlastitim timovima i planovima implementacije. GitOps nudi model nepromjenjiv o mjerilu za upravljanje svim ovim obiljem.
PS od prevoditelja
Pročitajte i na našem blogu:
- «»;
- «»;
- «".
U anketi mogu sudjelovati samo registrirani korisnici. , molim.
Jeste li znali za GitOps prije nego što su se ova dva prijevoda pojavila na Habréu?
-
Da, sve sam znao
-
Samo površno
-
Ne
Glasovalo je 35 korisnika. Suzdržano je bilo 10 korisnika.
Izvor: www.habr.com