Poznámka. preklad.: Po nedávnom uverejnení o metódach pull a push v GitOps sme zaznamenali záujem o tento model vo všeobecnosti, ale v ruskom jazyku bolo na túto tému veľmi málo publikácií (na Habré jednoducho nie sú). Preto sme radi, že vám môžeme ponúknuť preklad ďalšieho článku – aj keď takmer pred rokom! — od spoločnosti Weaveworks, ktorej vedúci vytvoril termín „GitOps“. Text vysvetľuje podstatu prístupu a kľúčové rozdiely od existujúcich.
Pred rokom sme zverejnili . Vtedy sme sa podelili o to, ako tím Weaveworks spustil SaaS úplne založený na Kubernetes a vyvinul súbor normatívnych osvedčených postupov na nasadenie, správu a monitorovanie v natívnom cloudovom prostredí.
Článok sa stal populárnym. Iní ľudia začali hovoriť o GitOps a začali zverejňovať nové nástroje pre , , , , a tak ďalej. Objavilo sa na našej webovej stránke publikácie a prípady použitia GitOps. Ale niektorí ľudia majú stále otázky. Ako sa model líši od tradičného? a nepretržité doručovanie ()? Je potrebné používať Kubernetes?
Čoskoro sme si uvedomili, že je potrebný nový popis, ktorý ponúka:
- Veľké množstvo príkladov a príbehov;
- Špecifická definícia GitOps;
- Porovnanie s tradičným nepretržitým doručovaním.
V tomto článku sme sa pokúsili pokryť všetky tieto témy. Poskytuje aktualizovaný úvod do GitOps a perspektívu vývojára a CI/CD. Primárne sa zameriavame na Kubernetes, aj keď model možno zovšeobecniť.
Zoznámte sa s GitOps
Predstavte si Alice. Prevádzkuje rodinné poistenie, ktoré ponúka zdravotné, auto, domáce a cestovné poistenie ľuďom, ktorí sú príliš zaneprázdnení na to, aby sami prišli na to, čo je v zmluvách. Jej podnikanie začalo ako vedľajší projekt, keď Alice pracovala v banke ako dátová vedkyňa. Jedného dňa si uvedomila, že môže použiť pokročilé počítačové algoritmy na efektívnejšiu analýzu údajov a formulovanie poistných balíkov. Investori projekt financovali a teraz jej spoločnosť prináša viac ako 20 miliónov dolárov ročne a rýchlo rastie. V súčasnosti zamestnáva 180 ľudí na rôznych pozíciách. To zahŕňa technologický tím, ktorý vyvíja, udržiava webovú stránku, databázu a analyzuje zákaznícku základňu. Tím 60 ľudí vedie Bob, technický riaditeľ spoločnosti.
Bobov tím nasadzuje produkčné systémy v cloude. Ich základné aplikácie bežia na GKE a využívajú výhody Kubernetes v Google Cloud. Okrem toho pri svojej práci využívajú rôzne dátové a analytické nástroje.
Rodinná poisťovňa sa nepustila do používania kontajnerov, ale uviazla v nadšení Dockera. Spoločnosť čoskoro zistila, že GKE uľahčuje nasadenie klastrov na testovanie nových funkcií. Na organizáciu registra kontajnerov boli pridané Jenkins pre CI a Quay, pre Jenkinsa boli napísané skripty, ktoré tlačili nové kontajnery a konfigurácie do GKE.
Uplynul nejaký čas. Alice a Bob boli sklamaní z výkonu zvoleného prístupu a jeho vplyvu na podnikanie. Zavedenie kontajnerov nezlepšilo produktivitu tak, ako tím dúfal. Niekedy sa nasadenia pokazili a nebolo jasné, či za to môžu zmeny kódu. Ukázalo sa tiež, že je ťažké sledovať zmeny konfigurácie. Často bolo potrebné vytvoriť nový klaster a presunúť doň aplikácie, pretože to bol najjednoduchší spôsob, ako odstrániť neporiadok, ktorým sa systém stal. Alice sa bála, že sa situácia s vývojom aplikácie ešte zhorší (navyše sa chystal nový projekt založený na strojovom učení). Bob zautomatizoval väčšinu práce a nechápal, prečo je potrubie stále nestabilné, zle sa škáluje a vyžaduje pravidelné manuálne zásahy?
Potom sa dozvedeli o GitOps. Ukázalo sa, že toto rozhodnutie bolo presne to, čo potrebovali, aby s istotou napredovali.
Alice a Bob už roky počúvajú o Git, DevOps a infraštruktúre ako o pracovných tokoch kódu. Na GitOps je jedinečné, že prináša súbor osvedčených postupov – definitívne aj normatívne – na implementáciu týchto myšlienok v kontexte Kubernetes. Táto téma , vrátane v .
Rodinná poisťovňa sa rozhodla implementovať GitOps. Spoločnosť má teraz automatizovaný prevádzkový model, ktorý je kompatibilný s Kubernetes a kombinuje rýchlosť s stabilitupretože oni:
- zistili, že produktivita tímu sa zdvojnásobila bez toho, aby sa niekto zbláznil;
- prestali zobrazovať skripty. Namiesto toho sa teraz môžu zamerať na nové funkcie a zlepšiť inžinierske metódy – napríklad zavedenie kanárikov a zlepšenie testovania;
- zlepšili sme proces nasadenia tak, že sa len zriedka pokazí;
- dostal možnosť obnoviť nasadenia po čiastočných poruchách bez manuálneho zásahu;
- kupované použitéоVäčšia dôvera v doručovacie systémy. Alice a Bob zistili, že môžu rozdeliť tím na mikroservisné tímy pracujúce paralelne;
- môže každý deň vykonať 30-50 zmien v projekte prostredníctvom úsilia každej skupiny a vyskúšať nové techniky;
- je ľahké prilákať do projektu nových vývojárov, ktorí majú možnosť zaviesť aktualizácie do produkcie pomocou požiadaviek na stiahnutie v priebehu niekoľkých hodín;
- ľahko prejsť auditom v rámci SOC2 (pre súlad poskytovateľov služieb s požiadavkami na bezpečnú správu údajov; prečítajte si viac napr. - približne. preklad.).
Čo sa stalo?
GitOps sú dve veci:
- Operačný model pre Kubernetes a natívny cloud. Poskytuje súbor osvedčených postupov pre nasadenie, správu a monitorovanie kontajnerových klastrov a aplikácií. Elegantná definícia vo forme od :
- Cesta k vytvoreniu prostredia na správu aplikácií zameraného na vývojárov. Pracovný postup Git aplikujeme na operácie aj vývoj. Upozorňujeme, že nejde len o Git push, ale o organizáciu celej sady nástrojov CI/CD a UI/UX.
Pár slov o Gite
Ak nie ste oboznámení so systémami na správu verzií a pracovným postupom založeným na Git, dôrazne vám odporúčame, aby ste sa o nich dozvedeli. Práca s vetvami a požiadavkami na ťahanie sa na prvý pohľad môže zdať ako čierna mágia, ale výhody stoja za námahu. Tu začať.
Ako funguje Kubernetes
V našom príbehu sa Alice a Bob po chvíli práce s Kubernetes obrátili na GitOps. GitOps skutočne úzko súvisí s Kubernetes – je to operačný model pre infraštruktúru a aplikácie založené na Kubernetes.
Čo dáva Kubernetes používateľom?
Tu je niekoľko hlavných funkcií:
- V modeli Kubernetes je možné všetko opísať v deklaratívnej forme.
- Server Kubernetes API berie túto deklaráciu ako vstup a potom sa neustále pokúša uviesť klaster do stavu opísaného v deklarácii.
- Vyhlásenia sú dostatočné na opísanie a riadenie širokej škály pracovných záťaží – „aplikácií“.
- V dôsledku toho dochádza k zmenám v aplikácii a klastri v dôsledku:
- zmeny v obrázkoch kontajnerov;
- zmeny deklaratívnej špecifikácie;
- chyby v prostredí – napríklad pády kontajnerov.
Kubernetesove skvelé konvergenčné schopnosti
Keď správca vykoná zmeny v konfigurácii, orchestrátor Kubernetes ich použije na klaster, pokiaľ je jeho stav sa nepriblížia novej konfigurácii. Tento model funguje pre akýkoľvek zdroj Kubernetes a je rozšíriteľný pomocou vlastných definícií zdrojov (CRD). Preto nasadenia Kubernetes majú nasledujúce úžasné vlastnosti:
- automatizácia: Aktualizácie Kubernetes poskytujú mechanizmus na automatizáciu procesu uplatňovania zmien elegantne a včas.
- Konvergencia: Kubernetes sa bude naďalej pokúšať o aktualizácie, kým nebudú úspešné.
- Idempotencia: Opakované aplikácie konvergencie vedú k rovnakému výsledku.
- Determinizmus: Keď sú zdroje dostatočné, stav aktualizovaného klastra závisí len od požadovaného stavu.
Ako funguje GitOps
O Kubernetes sme sa naučili dosť na to, aby sme vysvetlili, ako GitOps funguje.
Vráťme sa k tímom mikroslužieb Family Insurance. Čo zvyčajne musia robiť? Pozrite si zoznam nižšie (ak sa vám niektoré položky zdajú zvláštne alebo neznáme, zdržte sa kritiky a zostaňte s nami). Toto sú len príklady pracovných postupov založených na Jenkinsovi. Pri práci s inými nástrojmi existuje mnoho ďalších procesov.
Hlavná vec je, že vidíme, že každá aktualizácia končí zmenami v konfiguračných súboroch a úložiskách Git. Tieto zmeny v Git spôsobia, že „operátor GitOps“ aktualizuje klaster:
1. Pracovný proces: "Jenkins build - master branch".
Zoznam úloh:
- Jenkins posúva označené obrázky do Quay;
- Jenkins vloží konfiguračné a Helmove grafy do hlavného úložného vedra;
- Funkcia cloud skopíruje konfiguráciu a grafy z hlavného úložiska do hlavného úložiska Git;
- Operátor GitOps aktualizuje klaster.
2. Pobočka Jenkins build - release alebo hotfix:
- Jenkins posúva neoznačené obrázky Quay;
- Jenkins vloží konfiguračné a Helmove grafy do odkladacieho úložného vedra;
- Funkcia cloud skopíruje konfiguráciu a grafy zo zásobníka prípravného úložiska do prípravného úložiska Git;
- Operátor GitOps aktualizuje klaster.
3. Jenkins build - development alebo feature branch:
- Jenkins posúva neoznačené obrázky Quay;
- Jenkins vloží konfiguračné a Helmove grafy do vývojového úložiska;
- Cloudová funkcia skopíruje konfiguráciu a grafy z vývojového úložiska do vývojového úložiska Git;
- Operátor GitOps aktualizuje klaster.
4. Pridanie nového klienta:
- Manažér alebo správca (LCM/ops) zavolá Gradle, aby najprv nasadil a nakonfiguroval vyrovnávače zaťaženia siete (NLB);
- LCM/ops odovzdá novú konfiguráciu na prípravu nasadenia na aktualizácie;
- Operátor GitOps aktualizuje klaster.
Stručný popis GitOps
- Popíšte požadovaný stav celého systému pomocou deklaratívnych špecifikácií pre každé prostredie (v našom príbehu Bobov tím definuje celú konfiguráciu systému v Git).
- Úložisko Git je jediným zdrojom pravdy o požadovanom stave celého systému.
- Všetky zmeny požadovaného stavu sa vykonávajú prostredníctvom odovzdania v Git.
- Všetky požadované parametre klastra sú tiež pozorovateľné v samotnom klastri. Týmto spôsobom môžeme určiť, či sa zhodujú (konvergujú, konvergovať) alebo sa líšia (odlišujú sa, rozbiehajú) želané a pozorované stavy.
- Ak sa požadované a pozorované stavy líšia, potom:
- Existuje konvergenčný mechanizmus, ktorý skôr či neskôr automaticky synchronizuje cieľové a pozorované stavy. Vo vnútri klastra to robí Kubernetes.
- Proces sa začne okamžite s upozornením „potvrdená zmena“.
- Po určitom konfigurovateľnom časovom období môže byť zaslané upozornenie „rozdiel“, ak sú stavy odlišné.
- Týmto spôsobom všetky potvrdenia v Git spôsobia overiteľné a idempotentné aktualizácie klastra.
- Rollback je konvergencia do predtým požadovaného stavu.
- Konvergencia je konečná. Jeho výskyt je indikovaný:
- Žiadne upozornenia na rozdiely na určité časové obdobie.
- „konvergované“ upozornenie (napr. webhook, udalosť spätného zápisu Git).
Čo je divergencia?
Zopakujme si ešte raz: všetky požadované vlastnosti klastra musia byť pozorovateľné v samotnom klastri.
Niekoľko príkladov divergencie:
- Zmena v konfiguračnom súbore v dôsledku zlúčenia vetiev v Git.
- Zmena v konfiguračnom súbore v dôsledku potvrdenia Git vykonaného klientom GUI.
- Viacnásobné zmeny do požadovaného stavu v dôsledku PR v Git, po ktorých nasleduje vytvorenie obrazu kontajnera a zmeny konfigurácie.
- Zmena stavu klastra v dôsledku chyby, konflikt zdrojov, ktorý má za následok „zlé správanie“ alebo jednoducho náhodnú odchýlku od pôvodného stavu.
Aký je mechanizmus konvergencie?
Niekoľko príkladov:
- Pre kontajnery a klastre poskytuje mechanizmus konvergencie Kubernetes.
- Rovnaký mechanizmus možno použiť na správu aplikácií a návrhov založených na Kubernetes (napríklad Istio a Kubeflow).
- Poskytuje mechanizmus na riadenie prevádzkovej interakcie medzi Kubernetes, archívmi obrázkov a Git , ktorá je súčasťou .
- Pre základné stroje musí byť mechanizmus konvergencie deklaratívny a autonómny. Z vlastnej skúsenosti to môžeme povedať najbližšie k tejto definícii, ale stále si vyžaduje ľudskú kontrolu. V tomto zmysle GitOps rozširuje tradíciu Infrastructure as Code.
GitOps kombinuje Git s vynikajúcim konvergenčným motorom Kubernetes a poskytuje model na využitie.
GitOps nám umožňuje povedať: Automatizovať a riadiť sa dajú len tie systémy, ktoré je možné opísať a pozorovať.
GitOps je určený pre celý cloudový natívny zásobník (napríklad Terraform atď.)
GitOps nie je len Kubernetes. Chceme, aby bol celý systém riadený deklaratívne a využíval konvergenciu. Celým systémom máme na mysli kolekciu prostredí pracujúcich s Kubernetes – napríklad „dev cluster 1“, „production“ atď. Každé prostredie zahŕňa stroje, klastre, aplikácie, ale aj rozhrania pre externé služby, ktoré poskytujú dáta, monitorovanie atď.
Všimnite si, aký dôležitý je v tomto prípade Terraform pre problém s bootstrapingom. Kubernetes musí byť niekde nasadený a pomocou Terraformu môžeme použiť rovnaké pracovné postupy GitOps na vytvorenie riadiacej vrstvy, ktorá podporuje Kubernetes a aplikácie. Toto je užitočný osvedčený postup.
Veľký dôraz sa kladie na aplikáciu konceptov GitOps na vrstvy nad Kubernetes. Momentálne existujú riešenia typu GitOps pre Istio, Helm, Ksonnet, OpenFaaS a Kubeflow, ako aj napríklad pre Pulumi, ktoré vytvárajú vrstvu pre vývoj aplikácií pre cloudové natívne.
Kubernetes CI/CD: porovnanie GitOps s inými prístupmi
Ako už bolo uvedené, GitOps sú dve veci:
- Operačný model pre Kubernetes a natívny cloud popísaný vyššie.
- Cesta k vývojárskemu prostrediu správy aplikácií.
Pre mnohých je GitOps primárne pracovný postup založený na Git pushing. Aj my ho máme radi. Ale to nie je všetko: pozrime sa teraz na potrubia CI/CD.
GitOps umožňuje nepretržité nasadenie (CD) pre Kubernetes
GitOps ponúka mechanizmus nepretržitého nasadenia, ktorý eliminuje potrebu samostatných „systémov na správu nasadenia“. Kubernetes robí všetku prácu za vás.
- Aktualizácia aplikácie vyžaduje aktualizáciu v Git. Ide o transakčnú aktualizáciu do požadovaného stavu. „Nasadenie“ potom vykoná v rámci klastra samotný Kubernetes na základe aktualizovaného popisu.
- Vzhľadom na povahu fungovania Kubernetes sú tieto aktualizácie konvergentné. To poskytuje mechanizmus nepretržitého nasadenia, v ktorom sú všetky aktualizácie atomické.
- Poznámka: ponúka operátora GitOps, ktorý integruje Git a Kubernetes a umožňuje vykonávať CD zosúladením požadovaného a aktuálneho stavu klastra.
Bez kubectl a skriptov
Mali by ste sa vyhnúť používaniu Kubectl na aktualizáciu vášho klastra a najmä nepoužívaniu skriptov na zoskupovanie príkazov kubectl. Namiesto toho môže používateľ pomocou potrubia GitOps aktualizovať svoj klaster Kubernetes cez Git.
Medzi výhody patrí:
- Správny. Skupinu aktualizácií možno použiť, zblížiť a nakoniec overiť, čím sa priblížime k cieľu nasadenia atómov. Naopak, používanie skriptov neposkytuje žiadnu záruku konvergencie (viac o tom nižšie).
- zabezpečenia. Kelsey Hightower: „Obmedzte prístup k vášmu klastru Kubernetes na automatizačné nástroje a správcov, ktorí sú zodpovední za jeho ladenie alebo údržbu.“ pozri tiež o bezpečnosti a dodržiavaní technických špecifikácií, ako aj ukradnutím poverení z nedbalo napísaného Jenkinsovho scenára.
- Používateľská skúsenosť. Kubectl odhaľuje mechaniku objektového modelu Kubernetes, ktorý je pomerne zložitý. V ideálnom prípade by používatelia mali interagovať so systémom na vyššej úrovni abstrakcie. Tu sa opäť odvolám na Kelsey a odporúčam pozrieť .
Rozdiel medzi CI a CD
GitOps vylepšuje existujúce modely CI/CD.
Moderný server CI je nástroj na orchestráciu. Ide najmä o nástroj na organizovanie CI potrubí. Tieto zahŕňajú zostavenie, testovanie, zlúčenie do kmeňa atď. Servery CI automatizujú správu zložitých viackrokových potrubí. Bežným pokušením je naskriptovať sadu aktualizácií Kubernetes a spustiť ju ako súčasť potrubia na prenesenie zmien do klastra. V skutočnosti to robia mnohí odborníci. To však nie je optimálne a tu je dôvod.
CI by sa malo používať na odosielanie aktualizácií do kmeňa a klaster Kubernetes by sa mal sám meniť na základe týchto aktualizácií, aby interne spravoval CD. Hovoríme tomu , na rozdiel od modelu CI push. CD je súčasťou runtime orchestrácia.
Prečo by servery CI nemali robiť CD prostredníctvom priamych aktualizácií v Kubernetes
Nepoužívajte server CI na organizovanie priamych aktualizácií Kubernetes ako sady úloh CI. Toto je anti-vzor, o ktorom hovoríme na svojom blogu.
Vráťme sa k Alice a Bobovi.
Akým problémom čelili? Bobov server CI aplikuje zmeny na klaster, ale ak v procese zlyhá, Bob nebude vedieť, v akom stave sa klaster nachádza (alebo by mal byť) ani ako to opraviť. To isté platí aj v prípade úspechu.
Predpokladajme, že Bobov tím vytvoril nový obraz a potom opravil svoje nasadenia na nasadenie obrazu (všetky z kanála CI).
Ak sa obraz vytvorí normálne, ale potrubie zlyhá, tím bude musieť zistiť:
- Bola spustená aktualizácia?
- Spúšťame novú stavbu? Povedie to k zbytočným vedľajším účinkom – s možnosťou mať dve zostavy rovnakého nemenného obrazu?
- Mali by sme pred spustením zostavy počkať na ďalšiu aktualizáciu?
- Čo presne sa pokazilo? Ktoré kroky je potrebné opakovať (a ktoré je bezpečné opakovať)?
Vytvorenie pracovného postupu založeného na systéme Git nezaručuje, že Bobov tím sa s týmito problémami nestretne. Stále sa môžu pomýliť s pushom odovzdania, tagom alebo nejakým iným parametrom; tento prístup je však stále oveľa bližšie k explicitnému prístupu všetko alebo nič.
Aby sme to zhrnuli, tu je dôvod, prečo by servery CI nemali riešiť CD:
- Aktualizačné skripty nie sú vždy deterministické; Je ľahké sa v nich pomýliť.
- Servery CI nekonvergujú k deklaratívnemu klastrovému modelu.
- Je ťažké zaručiť idempotenciu. Používatelia musia pochopiť hlbokú sémantiku systému.
- Ťažšie sa zotavuje z čiastočného zlyhania.
Poznámka o Helme: Ak chcete Helm používať, odporúčame ho skombinovať s operátorom GitOps ako napr. . To pomôže zabezpečiť konvergenciu. Helm sám o sebe nie je ani deterministický, ani atómový.
GitOps ako najlepší spôsob implementácie nepretržitého doručovania pre Kubernetes
Tím Alice a Boba implementuje GitOps a zisťuje, že je oveľa jednoduchšie pracovať so softvérovými produktmi, udržiavať vysoký výkon a stabilitu. Zakončme tento článok ilustráciou, ktorá ukazuje, ako vyzerá ich nový prístup. Majte na pamäti, že väčšinou hovoríme o aplikáciách a službách, ale GitOps sa dá použiť na správu celej platformy.
Operačný model pre Kubernetes
Pozrite sa na nasledujúci diagram. Predstavuje Git a úložisko obrázkov kontajnera ako zdieľané prostriedky pre dva organizované životné cykly:
- Priebežný integračný kanál, ktorý číta a zapisuje súbory do systému Git a môže aktualizovať úložisko obrázkov kontajnerov.
- Runtime GitOps kanál, ktorý kombinuje nasadenie so správou a pozorovateľnosťou. Číta a zapisuje súbory do Git a môže sťahovať obrázky kontajnerov.
Aké sú hlavné zistenia?
- Oddelenie obáv: Upozorňujeme, že oba kanály môžu komunikovať iba aktualizáciou systému Git alebo úložiska obrázkov. Inými slovami, medzi CI a runtime prostredím je firewall. Nazývame to "nezmeniteľný firewall" (nezmeniteľný firewall), pretože všetky aktualizácie úložiska vytvárajú nové verzie. Viac informácií o tejto téme nájdete na snímkach 72-87 .
- Môžete použiť akýkoľvek server CI a Git: GitOps funguje s akýmkoľvek komponentom. Môžete pokračovať v používaní svojich obľúbených serverov CI a Git, archívov obrázkov a testovacích balíkov. Takmer všetky ostatné nástroje Continuous Delivery na trhu vyžadujú vlastný CI/Git server alebo úložisko obrázkov. To sa môže stať obmedzujúcim faktorom vo vývoji natívneho cloudu. S GitOps môžete používať známe nástroje.
- Udalosti ako integračný nástroj: Hneď ako sú údaje v Git aktualizované, Weave Flux (alebo operátor Weave Cloud) upozorní runtime. Vždy, keď Kubernetes prijme sadu zmien, Git sa aktualizuje. Toto poskytuje jednoduchý integračný model na organizovanie pracovných postupov pre GitOps, ako je uvedené nižšie.
Záver
GitOps poskytuje silné záruky aktualizácie, ktoré vyžaduje akýkoľvek moderný nástroj CI/CD:
- automatizácia;
- konvergencia;
- idempotencia;
- determinizmus.
Je to dôležité, pretože ponúka operačný model pre natívnych cloudových vývojárov.
- Tradičné nástroje na správu a monitorovanie systémov sú spojené s operačnými tímami fungujúcimi v rámci runbooku (súbor rutinných postupov a operácií - cca preklad), viazaný na konkrétne nasadenie.
- V cloudovej natívnej správe sú nástroje pozorovateľnosti najlepším spôsobom, ako merať výsledky nasadení, aby tím vývojárov mohol rýchlo reagovať.
Predstavte si veľa klastrov roztrúsených v rôznych cloudoch a mnohých službách s vlastnými tímami a plánmi nasadenia. GitOps ponúka model nemenný v mierke na správu všetkého tohto množstva.
PS od prekladateľa
Prečítajte si aj na našom blogu:
- «»;
- «»;
- «".
Do prieskumu sa môžu zapojiť iba registrovaní užívatelia. Prosím.
Vedeli ste o GitOps predtým, ako sa tieto dva preklady objavili na Habré?
-
Áno, všetko som vedel
-
Iba povrchne
-
Nie
Hlasovalo 35 užívateľov. 10 užívateľov sa zdržalo hlasovania.
Zdroj: hab.com