Bilješka. transl.: Nakon nedavne objave o metodama pull i push u GitOps-u, vidjeli smo interesovanje za ovaj model općenito, ali je bilo vrlo malo publikacija na ruskom jeziku na ovu temu (jednostavno ih nema na Habréu). Stoga nam je zadovoljstvo ponuditi vašoj pažnji prijevod još jednog članka - iako prije skoro godinu dana! — iz Weaveworksa, čiji je šef skovao termin „GitOps“. Tekst objašnjava suštinu pristupa i ključne razlike od postojećih.
Prije godinu dana objavili smo . Tada smo podijelili kako je Weaveworks tim pokrenuo SaaS u potpunosti zasnovan na Kubernetesu i razvio skup propisanih najboljih praksi za implementaciju, upravljanje i nadgledanje u prirodnom okruženju u oblaku.
Članak se pokazao popularnim. Drugi ljudi su počeli da pričaju o GitOps-u i počeli da objavljuju nove alate za , , , , i tako dalje. Pojavio se na našoj web stranici publikacije i slučajevi upotrebe GitOps-a. Ali neki ljudi i dalje imaju pitanja. Po čemu se model razlikuje od tradicionalnog? i kontinuirana isporuka ()? Da li je potrebno koristiti Kubernetes?
Ubrzo smo shvatili da je potreban novi opis, koji nudi:
- Veliki broj primjera i priča;
- Specifična definicija GitOps-a;
- Poređenje sa tradicionalnom kontinuiranom isporukom.
U ovom članku pokušali smo pokriti sve ove teme. Pruža ažurirani uvod u GitOps i perspektivu programera i CI/CD-a. Prvenstveno se fokusiramo na Kubernetes, iako se model može generalizirati.
Upoznajte GitOps
Zamisli Alice. Ona vodi Porodično osiguranje, koje nudi zdravstveno, auto, kućno i putno osiguranje ljudima koji su previše zauzeti da bi sami shvatili detalje ugovora. Njen posao je započeo kao sporedni projekat kada je Alice radila u banci kao data naučnik. Jednog dana je shvatila da može koristiti napredne kompjuterske algoritme za efikasniju analizu podataka i formulisanje paketa osiguranja. Investitori su finansirali projekat, a sada njena kompanija donosi više od 20 miliona dolara godišnje i brzo raste. Trenutno zapošljava 180 ljudi na različitim pozicijama. Ovo uključuje tehnološki tim koji razvija, održava web stranicu, bazu podataka i analizira korisničku bazu. Tim od 60 ljudi predvodi Bob, tehnički direktor kompanije.
Bobov tim postavlja proizvodne sisteme u oblaku. Njihove osnovne aplikacije rade na GKE-u, koristeći prednosti Kubernetesa na Google Cloud-u. Osim toga, u svom radu koriste različite alate za podatke i analitiku.
Family Insurance nije namjeravao koristiti kontejnere, ali je bio uhvaćen u Docker entuzijazam. Kompanija je ubrzo otkrila da je GKE olakšao postavljanje klastera za testiranje novih funkcija. Jenkins za CI i Quay su dodani za organizaciju registra kontejnera, napisane su skripte za Jenkins koje su gurale nove kontejnere i konfiguracije u GKE.
Prošlo je neko vrijeme. Alice i Bob su bili razočarani učinkom svog izabranog pristupa i njegovim uticajem na poslovanje. Uvođenje kontejnera nije poboljšalo produktivnost onoliko koliko se tim nadao. Ponekad bi implementacije pokvarile, i nije bilo jasno da li su za to krive promjene koda. Također se pokazalo da je teško pratiti promjene u konfiguraciji. Često je bilo potrebno kreirati novi klaster i premjestiti aplikacije u njega, jer je to bio najlakši način da se eliminiše nered koji je sistem postao. Alice se bojala da će se situacija pogoršati kako se aplikacija razvija (osim toga, spremao se novi projekat baziran na mašinskom učenju). Bob je automatizirao većinu posla i nije razumio zašto je cjevovod još uvijek nestabilan, nije dobro skalirao i zahtijevao je povremeno ručnu intervenciju?
Tada su saznali za GitOps. Ispostavilo se da je ova odluka upravo ono što im je bilo potrebno da samopouzdano krenu naprijed.
Alice i Bob godinama slušaju o Gitu, DevOps-u i infrastrukturi kao tokovima rada koda. Ono što je jedinstveno kod GitOps-a je to što donosi skup najboljih praksi – i definitivnih i normativnih – za implementaciju ovih ideja u kontekstu Kubernetesa. Ova tema , uključujući u .
Porodično osiguranje odlučuje implementirati GitOps. Kompanija sada ima model automatizovanog rada koji je kompatibilan sa Kubernetes-om i kombajnom brzina sa stabilnostjer oni:
- otkrili da se produktivnost tima udvostručila, a da niko nije poludio;
- prestao da servira skripte. Umjesto toga, sada se mogu fokusirati na nove karakteristike i poboljšati inženjerske metode – na primjer, uvođenje kanarinca i poboljšanje testiranja;
- poboljšali smo proces implementacije tako da se rijetko kvari;
- dobio priliku da obnovi implementacije nakon djelomičnih kvarova bez ručne intervencije;
- kupljen polovniоVeće povjerenje u sisteme isporuke. Alice i Bob su otkrili da mogu podijeliti tim na mikroservisne timove koji rade paralelno;
- može napraviti 30-50 promjena na projektu svaki dan kroz napore svake grupe i isprobati nove tehnike;
- lako je privući nove programere u projekat, koji imaju priliku da uvedu ažuriranja za proizvodnju koristeći zahtjeve za povlačenjem u roku od nekoliko sati;
- lako proći reviziju u okviru SOC2 (za usklađenost pružatelja usluga sa zahtjevima za sigurno upravljanje podacima; pročitajte više, npr. - cca. prevod).
Šta se desilo?
GitOps su dvije stvari:
- Operativni model za Kubernetes i native cloud. Pruža skup najboljih praksi za implementaciju, upravljanje i praćenje kontejnerskih klastera i aplikacija. Elegantna definicija u formi iz :
- Put do stvaranja okruženja za upravljanje aplikacijama usmjerenog na programere. Mi primjenjujemo Git radni tok i na operacije i na razvoj. Imajte na umu da se ne radi samo o Git pushu, već o organiziranju cijelog skupa CI/CD i UI/UX alata.
Nekoliko riječi o Gitu
Ako niste upoznati sa sistemima kontrole verzija i tokom rada zasnovanim na Gitu, toplo preporučujemo da naučite o njima. Rad s granama i zahtjevima za povlačenjem može izgledati kao crna magija u početku, ali prednosti su vrijedne truda. Evo početi.
Kako radi Kubernetes
U našoj priči, Alice i Bob su se okrenuli GitOps-u nakon što su neko vrijeme radili s Kubernetesom. Zaista, GitOps je usko povezan sa Kubernetesom – to je operativni model za infrastrukturu i aplikacije zasnovane na Kubernetesu.
Šta Kubernetes daje korisnicima?
Evo nekih glavnih karakteristika:
- U Kubernetes modelu sve se može opisati u deklarativnom obliku.
- Kubernetes API server uzima ovu deklaraciju kao ulaz i zatim neprestano pokušava da dovede klaster u stanje opisano u deklaraciji.
- Deklaracije su dovoljne za opis i upravljanje širokim spektrom radnih opterećenja – „aplikacija“.
- Kao rezultat toga, promjene u aplikaciji i klasteru nastaju zbog:
- promjene u slikama kontejnera;
- izmjene deklarativne specifikacije;
- greške u okruženju - na primjer, pad kontejnera.
Kubernetesove velike mogućnosti konvergencije
Kada administrator napravi 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 proširiv je prilagođenim definicijama resursa (CRD). Stoga, Kubernetes implementacije imaju sljedeća divna svojstva:
- Automatizacija: Kubernetes ažuriranja pružaju mehanizam za automatizaciju procesa primjene promjena na graciozan i blagovremen način.
- Konvergencija: Kubernetes će nastaviti s pokušajima ažuriranja dok ne bude uspješan.
- Idempotencija: Ponovljene primjene konvergencije dovode do istog rezultata.
- Determinizam: Kada su resursi dovoljni, stanje ažuriranog klastera ovisi samo o željenom stanju.
Kako funkcioniše GitOps
Naučili smo dovoljno o Kubernetesu da objasnimo kako GitOps funkcioniše.
Vratimo se timovima mikroservisa Porodičnog osiguranja. Šta obično moraju da urade? Pogledajte donju listu (ako vam se bilo koja stavka u njoj čini čudnom ili nepoznatom, prestanite s kritikama i ostanite s nama). Ovo su samo primjeri tokova rada zasnovanih na Jenkinsu. Postoje mnogi drugi procesi kada radite s drugim alatima.
Glavna stvar je da vidimo da se 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 - glavna 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 memorije u glavno Git spremište;
- GitOps operater ažurira klaster.
2. Jenkins build - izdanje ili grana hitne popravke:
- Jenkins gura neoznačene slike na Quay;
- Jenkins gura konfiguracijske i Helm grafikone u scenu za skladištenje;
- Funkcija oblaka kopira konfiguraciju i grafikone iz spremnika za pohranu u probno Git spremište;
- GitOps operater ažurira klaster.
3. Jenkins gradi - razvija ili predstavlja granu:
- Jenkins gura neoznačene slike na Quay;
- Jenkins gura konfiguracijske i Helm grafikone u razvojni spremnik za pohranu;
- Funkcija oblaka kopira konfiguraciju i grafikone iz razvojnog spremnika za pohranu u razvojno Git spremište;
- GitOps operater ažurira klaster.
4. Dodavanje novog klijenta:
- Menadžer ili administrator (LCM/ops) poziva Gradle da inicijalno postavi i konfiguriše balansere mrežnog opterećenja (NLB);
- LCM/ops urezuje novu konfiguraciju za pripremu implementacije za ažuriranja;
- GitOps operater ažurira klaster.
Kratak opis GitOps-a
- Opišite željeno stanje čitavog sistema koristeći deklarativne specifikacije za svako okruženje (u našoj priči, Bobov tim definiše kompletnu konfiguraciju sistema u Gitu).
- Git repozitorijum je jedini izvor istine u vezi sa željenim stanjem čitavog sistema.
- Sve promjene u željeno stanje se vrše putem urezivanja u Gitu.
- Svi željeni parametri klastera su također vidljivi u samom klasteru. Na taj način možemo utvrditi da li se poklapaju (konvergiraju, konvergirati) ili se razlikuju (razilaze se, divergira) željena i posmatrana stanja.
- Ako se željena i promatrana stanja razlikuju, tada:
- Postoji mehanizam konvergencije koji prije ili kasnije automatski sinkronizira ciljno i promatrano stanje. Unutar klastera, Kubernetes to radi.
- Proces počinje odmah sa upozorenjem „izmjena izvršena“.
- Nakon određenog vremenskog perioda koji se može podesiti, "diff" upozorenje se može poslati ako su stanja različita.
- Na ovaj način, sva urezivanja u Gitu uzrokuju provjerljiva i idempotentna ažuriranja klastera.
- Vraćanje je konvergencija u prethodno željeno stanje.
- Konvergencija je konačna. Na njenu pojavu ukazuje:
- Nema upozorenja o razlikama za određeni vremenski period.
- "konvergentno" upozorenje (npr. webhook, Git back writeback događaj).
Šta je divergencija?
Ponovimo ponovo: 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 urezivanja koju je napravio GUI klijent.
- Višestruke promjene u željeno stanje zbog PR-a u Gitu praćene izgradnjom slike kontejnera i promjenama konfiguracije.
- Promjena stanja klastera zbog greške, sukoba resursa koji rezultira "lošim ponašanjem", ili jednostavno nasumično odstupanje od prvobitnog stanja.
Koji je mehanizam konvergencije?
Nekoliko primjera:
- Za kontejnere i klastere, mehanizam konvergencije obezbeđuje Kubernetes.
- Isti mehanizam se može koristiti za upravljanje aplikacijama i dizajnom zasnovanim na Kubernetes (kao što su Istio i Kubeflow).
- Obezbeđuje mehanizam za upravljanje operativnom interakcijom između Kubernetesa, repozitorijuma slika i Gita , koji je dio .
- Za osnovne mašine, mehanizam konvergencije mora biti deklarativni i autonoman. Iz sopstvenog iskustva to možemo reći najbliže ovoj definiciji, ali ipak zahtijeva ljudsku kontrolu. U tom smislu, GitOps proširuje tradiciju infrastrukture kao koda.
GitOps kombinuje Git sa odličnim motorom za konvergenciju Kubernetes-a kako bi pružio model za eksploataciju.
GitOps nam omogućava da kažemo: Samo oni sistemi koji se mogu opisati i posmatrati mogu biti automatizovani i kontrolisani.
GitOps je namijenjen za cijeli nativni stog oblaka (na primjer, Terraform, itd.)
GitOps nije samo Kubernetes. Želimo da se cijeli sistem vodi deklarativno i da koristi konvergenciju. Pod cijelim sistemom podrazumijevamo kolekciju okruženja koja rade sa Kubernetesom – na primjer, “dev cluster 1”, “production” itd. Svako okruženje uključuje mašine, klastere, aplikacije, kao i interfejse za eksterne servise koji obezbeđuju podatke, praćenje i sl.
Obratite pažnju koliko je Terraform važan za problem pokretanja u ovom slučaju. Kubernetes mora biti raspoređen negdje, a korištenje Terraforma znači da možemo primijeniti iste GitOps radne tokove za kreiranje kontrolnog sloja koji podupire Kubernetes i aplikacije. Ovo je korisna najbolja praksa.
Snažan fokus je na primjeni GitOps koncepata na slojeve na vrhu Kubernetesa. Trenutno postoje rješenja tipa GitOps za Istio, Helm, Ksonnet, OpenFaaS i Kubeflow, kao i, na primjer, za Pulumi, koji stvaraju sloj za razvoj aplikacija za native cloud.
Kubernetes CI/CD: poređenje GitOpsa sa drugim pristupima
Kao što je rečeno, GitOps su dvije stvari:
- Operativni model za Kubernetes i izvorni oblak opisan je gore.
- Put do okruženja upravljanja aplikacijama usmjerenog na programere.
Za mnoge, GitOps je prvenstveno tok posla zasnovan na Git pushes. I nama se sviđa. Ali to nije sve: pogledajmo sada CI/CD cevovode.
GitOps omogućava kontinuiranu implementaciju (CD) za Kubernetes
GitOps nudi mehanizam kontinuirane implementacije koji eliminiše potrebu za odvojenim „sistemima upravljanja implementacijom“. Kubernetes radi sav posao za vas.
- Ažuriranje aplikacije zahtijeva ažuriranje u Gitu. Ovo je transakcijsko ažuriranje do željenog stanja. "Raspoređivanje" se zatim vrši unutar klastera od strane samog Kubernetesa na osnovu ažuriranog opisa.
- Zbog prirode načina na koji Kubernetes funkcionira, ova ažuriranja su konvergentna. Ovo pruža mehanizam za kontinuiranu implementaciju u kojem su sva ažuriranja atomska.
- Napomena: nudi GitOps operator koji integriše Git i Kubernetes i omogućava izvođenje CD-a usklađivanjem željenog i trenutnog stanja klastera.
Bez kubectla i skripti
Trebali biste izbjegavati korištenje Kubectl-a za ažuriranje vašeg klastera, a posebno izbjegavajte korištenje skripti za grupiranje kubectl komandi. Umjesto toga, s GitOps cevovodom, korisnik može ažurirati svoj Kubernetes klaster putem Gita.
Prednosti uključuju:
- U redu. Grupa ažuriranja se može primijeniti, konvergirati i konačno potvrditi, približavajući nas cilju atomske implementacije. Nasuprot tome, korištenje skripti ne daje nikakvu garanciju konvergencije (više o tome u nastavku).
- Sigurnost. Kelsey Hightower: “Ograničite pristup vašem Kubernetes klasteru na alate za automatizaciju i administratore koji su odgovorni za njegovo otklanjanje grešaka ili održavanje.” vidi takođe o sigurnosti i usklađenosti sa tehničkim specifikacijama, kao i krađom akreditiva iz nemarno napisanog Dženkinsovog 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 sistemom na višem nivou apstrakcije. Ovdje ću se ponovo osvrnuti na Kelsey i preporučiti gledanje .
Razlika između CI i CD-a
GitOps poboljšava postojeće CI/CD modele.
Moderni CI server je orkestarski alat. Konkretno, to je alat za orkestriranje CI cjevovoda. To uključuje izgradnju, testiranje, spajanje u trunk, itd. CI serveri automatiziraju upravljanje složenim cjevovodima u više koraka. Uobičajeno iskušenje je da skriptirate skup Kubernetes ažuriranja i pokrenete ga kao dio cjevovoda za provođenje promjena u klaster. Zaista, to je ono što mnogi stručnjaci rade. Međutim, ovo nije optimalno, a evo i zašto.
CI bi se trebao koristiti za prebacivanje ažuriranja u trunk, a Kubernetes klaster bi se trebao mijenjati na osnovu tih ažuriranja za interno upravljanje CD-om. Mi to zovemo , za razliku od CI push modela. CD je dio runtime orkestracija.
Zašto CI serveri ne bi trebali raditi CD-ove putem direktnih ažuriranja u Kubernetesu
Nemojte koristiti CI server za orkestriranje direktnih ažuriranja Kubernetesa kao skupa CI poslova. Ovo je anti-šablon o kojem govorimo na vašem blogu.
Vratimo se Alice i Bobu.
S kojim su se problemima suočili? Bobov CI server primjenjuje promjene na klaster, ali ako se sruši u procesu, Bob neće znati u kojem je stanju (ili bi trebao biti) klaster niti kako to popraviti. Isto važi i za slučaj uspeha.
Pretpostavimo da je Bobov tim napravio novu sliku, a zatim zakrpio svoje implementacije da bi postavio sliku (sve iz CI pipeline-a).
Ako se slika normalno gradi, ali cevovod ne uspije, tim će morati shvatiti:
- Da li je ažuriranje objavljeno?
- Pokrećemo li novu gradnju? Hoće li to dovesti do nepotrebnih nuspojava - sa mogućnošću da imate dvije verzije iste nepromjenjive slike?
- Trebamo li čekati sljedeće ažuriranje prije pokretanja gradnje?
- Šta je tačno pošlo po zlu? Koje korake treba ponoviti (i koje je sigurno ponoviti)?
Uspostavljanje toka rada zasnovanog na Gitu ne garantuje da Bobov tim neće naići na ove probleme. Oni i dalje mogu pogriješiti s pushom urezivanja, oznakom ili nekim drugim parametrom; međutim, ovaj pristup je i dalje mnogo bliži eksplicitnom pristupu sve ili ništa.
Da rezimiramo, evo zašto CI serveri ne bi trebali raditi s CD-om:
- Skripte za ažuriranje nisu uvijek determinističke; U njima je lako napraviti greške.
- CI serveri ne konvergiraju deklarativnom modelu klastera.
- Teško je garantovati idempotenciju. Korisnici moraju razumjeti duboku semantiku sistema.
- Teže je oporaviti se od djelomičnog kvara.
Napomena o Helmu: Ako želite da koristite Helm, preporučujemo da ga kombinujete sa GitOps operatorom kao što je . Ovo će pomoći u osiguravanju konvergencije. Sam Helm nije ni deterministički ni atomski.
GitOps kao najbolji način za implementaciju kontinuirane isporuke za Kubernetes
Alice i Bobov tim implementira GitOps i otkriva da je postalo mnogo lakše raditi sa softverskim proizvodima, održavati visoke performanse 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. On predstavlja Git i spremište slika kontejnera kao zajedničke resurse za dva orkestrirana životna ciklusa:
- Kontinuirani integracioni cevovod koji čita i upisuje datoteke u Git i može ažurirati spremište slika kontejnera.
- Runtime GitOps cevovod koji kombinuje primenu sa upravljanjem i vidljivošću. Čita i upisuje datoteke u Git i može preuzeti slike kontejnera.
Koji su glavni nalazi?
- Razdvajanje briga: Imajte na umu da oba cjevovoda mogu komunicirati samo ažuriranjem Gita ili spremišta slika. Drugim riječima, postoji zaštitni zid između CI-a i okruženja za izvršavanje. Mi to zovemo "zaštitni zid nepromjenjivosti" (zaštitni zid nepromjenjivosti), budući da sva ažuriranja spremišta stvaraju nove verzije. Za više informacija o ovoj temi pogledajte slajdove 72-87 .
- Možete koristiti bilo koji CI i Git server: GitOps radi sa bilo kojom komponentom. Možete nastaviti da koristite svoje omiljene CI i Git servere, spremišta slika i testne pakete. Gotovo svi ostali alati za kontinuiranu isporuku na tržištu zahtijevaju vlastiti CI/Git server ili spremište slika. Ovo može postati ograničavajući faktor u razvoju native cloud-a. Uz GitOps, možete koristiti poznate alate.
- Događaji kao alat za integraciju: Čim se podaci u Gitu ažuriraju, Weave Flux (ili Weave Cloud operator) obavještava vrijeme izvođenja. Kad god Kubernetes prihvati skup promjena, Git se ažurira. Ovo pruža jednostavan model integracije za organizovanje tokova rada za GitOps, kao što je prikazano u nastavku.
zaključak
GitOps pruža snažne garancije ažuriranja koje zahtijeva svaki moderni CI/CD alat:
- automatizacija;
- konvergencija;
- idempotencija;
- determinizam.
Ovo je važno jer nudi operativni model za programere koji se nalaze u oblaku.
- Tradicionalni alati za upravljanje i praćenje sistema povezani su sa operativnim timovima koji rade u okviru runbook-a (skup rutinskih procedura i operacija - pribl. prev.), vezano za određenu implementaciju.
- U izvornom upravljanju u oblaku, alati za posmatranje su najbolji način za mjerenje rezultata implementacije tako da razvojni tim može brzo odgovoriti.
Zamislite mnoge klastere razbacane po različitim oblacima i mnoge usluge s vlastitim timovima i planovima implementacije. GitOps nudi model koji je nepromjenjiv na skali za upravljanje svim ovim obiljem.
PS od prevodioca
Pročitajte i na našem blogu:
- «»;
- «»;
- «".
Samo registrovani korisnici mogu učestvovati u anketi. molim.
Jeste li znali za GitOps prije nego što su se ova dva prijevoda pojavila na Habréu?
-
Da, znao sam sve
-
Samo površno
-
Nijedan
Glasalo je 35 korisnika. Uzdržano je bilo 10 korisnika.
izvor: www.habr.com