Poznámka. přel.: Po nedávném zveřejnění o metodách pull a push v GitOps jsme zaznamenali zájem o tento model obecně, ale ruskojazyčných publikací na toto téma bylo velmi málo (na Habré prostě žádné nejsou). Proto jsme rádi, že vám můžeme nabídnout překlad dalšího článku - i když téměř před rokem! — od Weaveworks, jehož šéf vytvořil termín „GitOps“. Text vysvětluje podstatu přístupu a klíčové rozdíly oproti stávajícím.
Před rokem jsme publikovali . Tehdy jsme se podělili o to, jak tým Weaveworks spustil SaaS zcela založené na Kubernetes a vyvinul sadu normativních osvědčených postupů pro nasazení, správu a monitorování v nativním cloudovém prostředí.
Článek se ukázal být populární. Jiní lidé začali mluvit o GitOps a začali publikovat nové nástroje pro , , , , a tak dále. Objevilo se na našem webu publikace a případy použití GitOps. Ale někteří lidé mají stále otázky. Jak se model liší od tradičního? a nepřetržité doručování ()? Je nutné používat Kubernetes?
Brzy jsme si uvědomili, že je potřeba nový popis, který nabízí:
- Velké množství příkladů a příběhů;
- Specifická definice GitOps;
- Srovnání s tradiční kontinuální dodávkou.
V tomto článku jsme se pokusili pokrýt všechna tato témata. Poskytuje aktualizovaný úvod do GitOps a vývojářskou a CI/CD perspektivu. Primárně se zaměřujeme na Kubernetes, i když model lze zobecnit.
Seznamte se s GitOps
Představte si Alici. Provozuje rodinné pojištění, které nabízí zdravotní, auto, domov a cestovní pojištění lidem, kteří jsou příliš zaneprázdněni na to, aby sami přišli na to, co je ve smlouvách. Její podnikání začalo jako vedlejší projekt, když Alice pracovala v bance jako datová vědkyně. Jednoho dne si uvědomila, že by mohla využít pokročilé počítačové algoritmy k efektivnější analýze dat a formulování pojistných balíčků. Investoři projekt financovali a nyní její společnost přináší více než 20 milionů dolarů ročně a rychle roste. V současné době zaměstnává 180 lidí na různých pozicích. To zahrnuje technologický tým, který vyvíjí, udržuje webové stránky, databázi a analyzuje zákaznickou základnu. Tým 60 lidí vede Bob, technický ředitel společnosti.
Bobův tým nasazuje produkční systémy v cloudu. Jejich základní aplikace běží na GKE a využívají výhody Kubernetes na Google Cloud. Při své práci navíc využívají různé datové a analytické nástroje.
Rodinná pojišťovna se nepustila do používání kontejnerů, ale nechala se chytit nadšením Dockera. Společnost brzy zjistila, že GKE usnadňuje nasazení clusterů pro testování nových funkcí. Byly přidány Jenkins pro CI a Quay, aby organizovaly registr kontejnerů, pro Jenkinse byly napsány skripty, které do GKE posunuly nové kontejnery a konfigurace.
Uplynul nějaký čas. Alice a Bob byli zklamáni výkonem zvoleného přístupu a jeho dopadem na obchod. Zavedení kontejnerů nezlepšilo produktivitu tak, jak tým doufal. Někdy se nasazení zlomilo a nebylo jasné, zda za to mohou změny kódu. Ukázalo se také, že je obtížné sledovat změny konfigurace. Často bylo nutné vytvořit nový cluster a přesunout do něj aplikace, protože to byl nejjednodušší způsob, jak odstranit nepořádek, kterým se systém stal. Alice se bála, že se s vývojem aplikace situace ještě zhorší (navíc se chystal nový projekt založený na strojovém učení). Bob většinu práce zautomatizoval a nechápal, proč je potrubí stále nestabilní, špatně se měří a vyžaduje pravidelné ruční zásahy?
Pak se dozvěděli o GitOps. Ukázalo se, že toto rozhodnutí bylo přesně to, co potřebovali k sebevědomému postupu vpřed.
Alice a Bob slýchali o Gitu, DevOps a infrastruktuře jako o pracovních postupech kódu už roky. Na GitOps je jedinečné, že přináší sadu osvědčených postupů – definitivních i normativních – pro implementaci těchto nápadů v kontextu Kubernetes. Toto téma , včetně v .
Rodinná pojišťovna se rozhodla implementovat GitOps. Společnost má nyní automatizovaný provozní model, který je kompatibilní s Kubernetes a kombajny rychlost s stabilitaprotože oni:
- zjistili, že produktivita týmu se zdvojnásobila, aniž by se někdo zbláznil;
- přestalo zobrazovat skripty. Místo toho se nyní mohou soustředit na nové funkce a vylepšovat inženýrské metody – například zavádění kanárků a zlepšování testování;
- vylepšili jsme proces nasazení, takže se jen zřídka porouchá;
- získal možnost obnovit nasazení po dílčích poruchách bez ručního zásahu;
- zakoupené použitéоVětší důvěra v doručovací systémy. Alice a Bob zjistili, že mohou tým rozdělit na mikroservisní týmy pracující paralelně;
- díky úsilí každé skupiny může každý den provést 30-50 změn v projektu a vyzkoušet nové techniky;
- je snadné přilákat do projektu nové vývojáře, kteří mají možnost zavést aktualizace do produkce pomocí požadavků na stažení během několika hodin;
- snadno projít auditem v rámci SOC2 (pro soulad poskytovatelů služeb s požadavky na bezpečnou správu dat; čtěte více např. - Cca. překlad.).
Co se stalo?
GitOps jsou dvě věci:
- Operační model pro Kubernetes a cloudové nativní. Poskytuje sadu osvědčených postupů pro nasazení, správu a monitorování kontejnerových clusterů a aplikací. Elegantní definice ve formě z :
- Cesta k vytvoření prostředí pro správu aplikací zaměřené na vývojáře. Pracovní postup Git aplikujeme na provoz i vývoj. Upozorňujeme, že se nejedná pouze o Git push, ale o organizaci celé sady nástrojů CI/CD a UI/UX.
Pár slov o Gitu
Pokud nejste obeznámeni se systémy správy verzí a pracovním postupem založeným na Git, důrazně doporučujeme, abyste se o nich dozvěděli. Práce s větvemi a pull requesty se může na první pohled zdát jako černá magie, ale výhody stojí za námahu. Tady začít.
Jak funguje Kubernetes
V našem příběhu se Alice a Bob po chvíli práce s Kubernetes obrátili na GitOps. GitOps skutečně úzce souvisí s Kubernetes – je to operační model pro infrastrukturu a aplikace založené na Kubernetes.
Co dává Kubernetes uživatelům?
Zde jsou některé hlavní funkce:
- V modelu Kubernetes lze vše popsat deklarativní formou.
- Server Kubernetes API vezme tuto deklaraci jako vstup a poté se neustále pokouší uvést cluster do stavu popsaného v deklaraci.
- Prohlášení jsou dostatečná k popisu a řízení široké škály pracovních zátěží – „aplikací“.
- V důsledku toho dochází ke změnám aplikace a clusteru v důsledku:
- změny v obrázcích kontejnerů;
- změny deklarativní specifikace;
- chyby v prostředí – například pády kontejneru.
Velké konvergenční schopnosti Kubernetes
Když správce provede změny konfigurace, orchestrátor Kubernetes je použije na cluster, dokud je jeho stav se nepřiblíží nové konfiguraci. Tento model funguje pro jakýkoli zdroj Kubernetes a je rozšiřitelný pomocí vlastních definic zdrojů (CRD). Proto mají nasazení Kubernetes následující skvělé vlastnosti:
- Automatizace: Aktualizace Kubernetes poskytují mechanismus pro automatizaci procesu uplatňování změn elegantně a včas.
- Konvergence: Kubernetes se bude nadále pokoušet o aktualizace, dokud nebude úspěšný.
- Idempotence: Opakované aplikace konvergence vedou ke stejnému výsledku.
- Determinismus: Když jsou prostředky dostatečné, stav aktualizovaného clusteru závisí pouze na požadovaném stavu.
Jak GitOps funguje
Naučili jsme se o Kubernetes dost, abychom vysvětlili, jak GitOps funguje.
Vraťme se k týmům mikroslužeb Family Insurance. Co obvykle musí dělat? Podívejte se na níže uvedený seznam (pokud se vám některé položky zdají podivné nebo neznámé, odložte prosím kritiku a zůstaňte s námi). Toto jsou jen příklady pracovních postupů založených na Jenkinsovi. Při práci s jinými nástroji existuje mnoho dalších procesů.
Hlavní věc je, že vidíme, že každá aktualizace končí změnami konfiguračních souborů a repozitářů Git. Tyto změny v Gitu způsobí, že „operátor GitOps“ aktualizuje cluster:
1. Pracovní proces: "Jenkins build - master branch".
Seznam úkolů:
- Jenkins posílá označené obrázky do Quay;
- Jenkins přenese konfigurační a Helmovy diagramy do hlavního úložiště;
- Cloudová funkce zkopíruje konfiguraci a grafy z hlavního úložiště do hlavního úložiště Git;
- Operátor GitOps aktualizuje cluster.
2. Jenkins build - release nebo hotfix větev:
- Jenkins posílá neoznačené obrázky Quay;
- Jenkins vloží konfigurační a Helmovy diagramy do úložného kbelíku;
- Funkce cloud zkopíruje konfiguraci a grafy ze segmentu pracovního úložiště do pracovního úložiště Git;
- Operátor GitOps aktualizuje cluster.
3. Jenkins build - development nebo feature branch:
- Jenkins posílá neoznačené obrázky Quay;
- Jenkins vloží konfigurační a Helmovy grafy do vývojového úložiště;
- Cloudová funkce zkopíruje konfiguraci a grafy z úložiště pro vývoj do úložiště Git pro vývoj;
- Operátor GitOps aktualizuje cluster.
4. Přidání nového klienta:
- Manažer nebo administrátor (LCM/ops) volá Gradle, aby nejprve nasadil a nakonfiguroval nástroje pro vyrovnávání zatížení sítě (NLB);
- LCM/ops odevzdá novou konfiguraci, aby připravila nasazení na aktualizace;
- Operátor GitOps aktualizuje cluster.
Stručný popis GitOps
- Popište požadovaný stav celého systému pomocí deklarativních specifikací pro každé prostředí (v našem příběhu Bobův tým definuje celou konfiguraci systému v Gitu).
- Úložiště Git je jediným zdrojem pravdy ohledně požadovaného stavu celého systému.
- Všechny změny požadovaného stavu se provádějí prostřednictvím odevzdání v Gitu.
- Všechny požadované parametry clusteru jsou také pozorovatelné v samotném clusteru. Tímto způsobem můžeme určit, zda se shodují (konvergují, konvergovat) nebo se liší (rozcházejí se, rozcházet se) žádoucí a pozorované stavy.
- Pokud se požadovaný a pozorovaný stav liší, pak:
- Existuje konvergenční mechanismus, který dříve nebo později automaticky synchronizuje cíl a pozorované stavy. Uvnitř clusteru to dělá Kubernetes.
- Proces začíná okamžitě upozorněním „změna potvrzena“.
- Po určité konfigurovatelné době může být odeslána výstraha „rozdíl“, pokud se stavy liší.
- Tímto způsobem všechna potvrzení v Gitu způsobí ověřitelné a idempotentní aktualizace clusteru.
- Rollback je konvergence do dříve požadovaného stavu.
- Konvergence je konečná. Jeho výskyt je označen:
- Žádná rozdílová upozornění po určitou dobu.
- "konvergované" upozornění (např. webhook, událost zpětného zápisu Git).
Co je divergence?
Zopakujme si znovu: všechny požadované vlastnosti shluku musí být pozorovatelné v samotném shluku.
Některé příklady divergence:
- Změna v konfiguračním souboru kvůli sloučení větví v Gitu.
- Změna v konfiguračním souboru kvůli potvrzení Git provedenému klientem GUI.
- Vícenásobné změny do požadovaného stavu kvůli PR v Gitu následované vytvořením obrazu kontejneru a změnami konfigurace.
- Změna stavu clusteru v důsledku chyby, konfliktu zdrojů vedoucí ke „špatnému chování“ nebo jednoduše náhodná odchylka od původního stavu.
Jaký je mechanismus konvergence?
Několik příkladů:
- Pro kontejnery a clustery poskytuje mechanismus konvergence Kubernetes.
- Stejný mechanismus lze použít ke správě aplikací a návrhů založených na Kubernetes (jako jsou Istio a Kubeflow).
- Poskytuje mechanismus pro správu provozní interakce mezi Kubernetes, úložišti obrázků a Git , která je součástí .
- U základních strojů musí být mechanismus konvergence deklarativní a autonomní. Z vlastní zkušenosti to můžeme říci nejblíže této definici, ale stále vyžaduje lidskou kontrolu. V tomto smyslu GitOps rozšiřuje tradici Infrastructure as Code.
GitOps kombinuje Git s vynikajícím konvergenčním enginem Kubernetes a poskytuje model pro využití.
GitOps nám umožňuje říci: Automatizovat a řídit lze pouze ty systémy, které lze popsat a pozorovat.
GitOps je určen pro celý cloudový nativní stack (například Terraform atd.)
GitOps není jen Kubernetes. Chceme, aby byl celý systém řízen deklarativně a využíval konvergenci. Celým systémem rozumíme kolekci prostředí pracujících s Kubernetes – například „dev cluster 1“, „production“ atd. Každé prostředí zahrnuje stroje, clustery, aplikace, ale i rozhraní pro externí služby, které poskytují data, monitoring atd.
Všimněte si, jak důležitý je Terraform pro problém bootstrapingu v tomto případě. Kubernetes musí být někde nasazen a pomocí Terraformu můžeme použít stejné pracovní postupy GitOps k vytvoření řídicí vrstvy, která je základem Kubernetes a aplikací. Toto je užitečný osvědčený postup.
Velký důraz je kladen na aplikaci konceptů GitOps na vrstvy nad Kubernetes. V tuto chvíli existují řešení typu GitOps pro Istio, Helm, Ksonnet, OpenFaaS a Kubeflow a také například pro Pulumi, která vytvářejí vrstvu pro vývoj aplikací pro cloudové nativní.
Kubernetes CI/CD: porovnání GitOps s jinými přístupy
Jak již bylo řečeno, GitOps jsou dvě věci:
- Operační model pro Kubernetes a nativní cloud popsaný výše.
- Cesta k prostředí pro správu aplikací zaměřených na vývojáře.
Pro mnohé je GitOps především pracovní postup založený na Git pushes. My ho máme také rádi. Ale to není vše: podívejme se nyní na potrubí CI/CD.
GitOps umožňuje kontinuální nasazení (CD) pro Kubernetes
GitOps nabízí kontinuální mechanismus nasazení, který eliminuje potřebu samostatných „systémů pro správu nasazení“. Kubernetes udělá veškerou práci za vás.
- Aktualizace aplikace vyžaduje aktualizaci v Gitu. Jedná se o transakční aktualizaci do požadovaného stavu. „Nasazení“ pak v rámci clusteru provádí sám Kubernetes na základě aktualizovaného popisu.
- Vzhledem k povaze toho, jak Kubernetes funguje, jsou tyto aktualizace konvergentní. To poskytuje mechanismus pro nepřetržité nasazení, ve kterém jsou všechny aktualizace atomické.
- Poznámka: nabízí operátor GitOps, který integruje Git a Kubernetes a umožňuje provádění CD pomocí sladění požadovaného a aktuálního stavu clusteru.
Bez kubectl a skriptů
Měli byste se vyhnout použití Kubectl k aktualizaci vašeho clusteru a zejména se vyhnout použití skriptů k seskupování příkazů kubectl. Místo toho může uživatel pomocí kanálu GitOps aktualizovat svůj cluster Kubernetes přes Git.
Mezi výhody patří:
- Že jo. Lze použít, sblížit a nakonec ověřit skupinu aktualizací, čímž se přiblížíme k cíli atomového nasazení. Naproti tomu použití skriptů neposkytuje žádnou záruku konvergence (více o tom níže).
- zabezpečení. Kelsey Hightower: „Omezte přístup ke svému clusteru Kubernetes na automatizační nástroje a administrátory, kteří jsou zodpovědní za jeho ladění nebo údržbu.“ viz také o bezpečnosti a dodržování technických specifikací, jakož i ukradením přihlašovacích údajů z nedbale napsaného Jenkinsova scénáře.
- Uživatelská zkušenost. Kubectl odhaluje mechaniku objektového modelu Kubernetes, která je poměrně složitá. V ideálním případě by uživatelé měli interagovat se systémem na vyšší úrovni abstrakce. Zde opět odkážu na Kelsey a doporučím ke shlédnutí .
Rozdíl mezi CI a CD
GitOps vylepšuje stávající modely CI/CD.
Moderní CI server je nástroj pro orchestraci. Zejména se jedná o nástroj pro orchestraci CI kanálů. Patří mezi ně sestavení, testování, sloučení do kmene atd. Servery CI automatizují správu složitých vícekrokových kanálů. Běžným pokušením je skriptovat sadu aktualizací Kubernetes a spouštět ji jako součást kanálu pro zasílání změn do clusteru. Ve skutečnosti to dělá mnoho odborníků. To však není optimální a zde je důvod.
CI by se mělo používat k odesílání aktualizací do kmene a cluster Kubernetes by se měl sám změnit na základě těchto aktualizací, aby bylo možné interně spravovat CD. Říkáme tomu , na rozdíl od modelu CI push. CD je součástí běhová orchestrace.
Proč by servery CI neměly vytvářet disky CD prostřednictvím přímých aktualizací v Kubernetes
Nepoužívejte server CI k organizování přímých aktualizací Kubernetes jako sady úloh CI. To je anti-vzor, o kterém mluvíme na svém blogu.
Vraťme se k Alice a Bobovi.
S jakými problémy se potýkali? Bobův server CI aplikuje změny na cluster, ale pokud během procesu dojde k jeho zhroucení, Bob nebude vědět, v jakém stavu cluster je (nebo by měl být) ani jak jej opravit. Totéž platí v případě úspěchu.
Předpokládejme, že Bobův tým vytvořil nový obraz a poté opravil svá nasazení, aby nasadil obraz (vše z kanálu CI).
Pokud se obraz vytvoří normálně, ale potrubí selže, tým bude muset zjistit:
- Byla aktualizace spuštěna?
- Spouštíme novou stavbu? Povede to ke zbytečným vedlejším efektům – s možností mít dvě sestavení stejného neměnného obrazu?
- Měli bychom před spuštěním sestavení počkat na další aktualizaci?
- Co přesně se pokazilo? Které kroky je třeba opakovat (a které je bezpečné opakovat)?
Zavedení pracovního postupu založeného na Git nezaručuje, že Bobův tým se s těmito problémy nesetká. Stále mohou udělat chybu s potvrzením push, tagem nebo nějakým jiným parametrem; tento přístup je však stále mnohem blíže explicitnímu přístupu vše nebo nic.
Abychom to shrnuli, zde je důvod, proč by CI servery neměly pracovat s CD:
- Aktualizační skripty nejsou vždy deterministické; Je snadné v nich dělat chyby.
- Servery CI nekonvergují k modelu deklarativního clusteru.
- Je těžké zaručit idempotenci. Uživatelé musí rozumět hluboké sémantice systému.
- Z částečného selhání se vzpamatovává obtížněji.
Poznámka k Helmu: Pokud chcete Helm používat, doporučujeme jej zkombinovat s operátorem GitOps, jako je např. . To pomůže zajistit konvergenci. Helm sám o sobě není ani deterministický, ani atomový.
GitOps jako nejlepší způsob implementace Continuous Delivery pro Kubernetes
Tým Alice a Boba implementuje GitOps a zjišťuje, že je mnohem jednodušší pracovat se softwarovými produkty, udržovat vysoký výkon a stabilitu. Zakončeme tento článek ilustrací, která ukazuje, jak jejich nový přístup vypadá. Mějte na paměti, že většinou mluvíme o aplikacích a službách, ale GitOps lze použít ke správě celé platformy.
Operační model pro Kubernetes
Podívejte se na následující schéma. Představuje Git a úložiště obrázků kontejneru jako sdílené prostředky pro dva organizované životní cykly:
- Průběžný integrační kanál, který čte a zapisuje soubory do Gitu a může aktualizovat úložiště obrázků kontejnerů.
- Runtime GitOps kanál, který kombinuje nasazení se správou a pozorovatelností. Čte a zapisuje soubory do Gitu a může stahovat obrázky kontejnerů.
Jaká jsou hlavní zjištění?
- Oddělení starostí: Vezměte prosím na vědomí, že oba kanály mohou komunikovat pouze aktualizací systému Git nebo úložiště obrázků. Jinými slovy, mezi CI a runtime prostředím je firewall. Říkáme tomu "neměnný firewall" (neměnný firewall), protože všechny aktualizace úložiště vytvářejí nové verze. Další informace o tomto tématu naleznete na snímcích 72-87 .
- Můžete použít jakýkoli server CI a Git: GitOps funguje s jakoukoli komponentou. Můžete nadále používat své oblíbené servery CI a Git, úložiště obrázků a testovací sady. Téměř všechny ostatní nástroje Continuous Delivery na trhu vyžadují vlastní CI/Git server nebo úložiště obrázků. To se může stát limitujícím faktorem ve vývoji cloudového nativního. S GitOps můžete používat známé nástroje.
- Události jako integrační nástroj: Jakmile jsou data v Gitu aktualizována, Weave Flux (nebo operátor Weave Cloud) upozorní runtime. Kdykoli Kubernetes přijme sadu změn, Git se aktualizuje. To poskytuje jednoduchý integrační model pro organizaci pracovních postupů pro GitOps, jak je znázorněno níže.
Závěr
GitOps poskytuje silné záruky aktualizací, které vyžaduje jakýkoli moderní nástroj CI/CD:
- automatizace;
- konvergence;
- idempotence;
- determinismus.
To je důležité, protože nabízí operační model pro cloudové nativní vývojáře.
- Tradiční nástroje pro správu a monitorování systémů jsou spojeny s operačními týmy fungujícími v rámci sady runbook (soubor rutinních postupů a operací - cca překlad), vázané na konkrétní nasazení.
- V cloudové nativní správě jsou nástroje pozorovatelnosti nejlepším způsobem, jak měřit výsledky nasazení, aby vývojový tým mohl rychle reagovat.
Představte si mnoho clusterů rozptýlených v různých cloudech a mnoha službách s vlastními týmy a plány nasazení. GitOps nabízí měřítko-invariantní model pro správu veškerého tohoto množství.
PS od překladatele
Přečtěte si také na našem blogu:
- «";
- «";
- «".
Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. , prosím.
Věděli jste o GitOps, než se tyto dva překlady objevily na Habré?
-
Ano, věděl jsem všechno
-
Pouze povrchně
-
Ne
Hlasovalo 35 uživatelů. 10 uživatelů se zdrželo hlasování.
Zdroj: www.habr.com