Pozn. přek.: Po nedávném zveřejnění o metodách pull a push v GitOps jsme zaznamenali zájem o tento model jako celek, nicméně publikace v ruštině na toto téma se ukázalo být velmi málo (na Habr vlastně žádné nejsou). Proto jsme rádi, že vám můžeme nabídnout překlad jiného článku — i když je už skoro roční! — od společnosti Weaveworks, jejíž šéf vymyslel termín „GitOps“. V textu je vysvětlena podstata přístupu a klíčové rozdíly od již existujících.
Před rokem jsme zveřejnili . Tehdy jsme řekli, jak tým Weaveworks spustil SaaS zcela založený na Kubernetes a vyvinul sadu doporučení pro nasazení, správu a monitorování v prostředí cloud native.
Článek se ukázal jako populární. Jiní lidé začali mluvit o GitOps, začali publikovat nové nástroje pro , , , , atd. Na našich stránkách se objevilo publikací a případů použití GitOps. Ale někteří lidé stále měli otázky. Jak se model liší od tradičního a nepřetržitého dodávání ()? Je nutné používat Kubernetes?
Brzy jsme si uvědomili, že je potřeba nové vysvětlení, které nabízí:
- Velké množství příkladů a příběhů;
- Konkrétní definici GitOps;
- Srovnání s tradičním nepřetržitým dodáváním.
V tomto článku jsme se pokusili zahrnout všechna tato témata. Najdete v něm aktualizovaný úvod do GitOps a pohled na něj z pohledu vývojářů a CI/CD. Většinou se soustředíme na Kubernetes, i když model lze poměrně dobře zobecnit.
Seznamte se: GitOps
Představte si Alici. Řídí společnost Family Insurance, která nabízí pojistné produkty pro zdravotní, automobilové a nemovitostní pojištění, stejně jako cestovní pojištění lidem, kteří mají příliš málo času na porozumění složitostem smluv. Její podnikání začalo jako vedlejší projekt, když Alice pracovala v bance jako datová vědkyně. Jednou si uvědomila, že může využít pokročilé počítačové algoritmy k efektivnější analýze dat a vytváření 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ě v ní pracuje na různých pozicích 180 zaměstnanců. Mezi nimi je technologický tým, který se zabývá vývojem, údržbou webu, databáze a analýzou klientské základny. Tým o 60 lidech vede Bob — technický ředitel společnosti.
Bobův tým nasazuje produkční systémy v cloudu. Jejich hlavní aplikace běží na GKE, těží z výhod Kubernetes v Google Cloudu. Kromě toho používají různé nástroje pro práci s daty a analýzu.
Family Insurance neplánovala používat kontejnery, ale nadchla se pro Docker. Brzy odborníci společnosti zjistili, že GKE umožňuje snadno a bezproblémově nasazovat clustery pro testování nových funkcí. Byly přidány Jenkins pro CI a Quay pro organizaci registru kontejnerů, a napsaly se skripty pro Jenkins, které nahrávaly nové kontejnery a konfigurace do GKE.
Uteklo nějaké době. Alice a Bob byli zklamaní výkonností zvoleného přístupu a jeho vlivem na podnikání. Zavedení kontejnerů nezvýšilo výkon tak, jak tým doufal. Někdy se deploymenty rozbíjely a nebylo jasné, zda za to mohou změny kódu. Také bylo těžké sledovat změny v konfiguracích. Často museli vytvářet nové klastr a přesouvat do něj aplikace, protože to byl nejjednodušší způsob, jak vyřešit chaos, do kterého se systém proměnil. Alice se bála, že se situace zhorší s rozvojem aplikace (kromě toho se blížil nový projekt založený na strojovém učení). Bob automatizoval většinu práce a nechápal, proč je pipeline stále nestabilní, špatně se škáluje a občas vyžaduje ruční zásah?
Poté se dozvěděli o GitOps. Toto řešení se ukázalo být přesně tím, co potřebovali pro jistý pokrok.
Alice a Bob už léta slyšeli o pracovních procesech založených na Gitu, DevOps a infrastruktuře jako kódu. Jedinečnost GitOps spočívá v tom, že přináší řadu osvědčených praktik - kategorických a regulativních - pro implementaci těchto nápadů v kontextu Kubernetes. Tato téma , včetně .
Family Insurance se rozhodla zavést GitOps. Nyní má společnost automatizovaný model provozu kompatibilní s Kubernetes a kombinuje rychlost s stabilitu, protože:
- zjistili, že výkon týmu se zdvojnásobil a nikdo se při tom nezbláznil;
- přestali spravovat skripty. Místo toho se nyní mohou soustředit na nové funkce a zlepšování inženýrských metod - například zavést kanárková nasazení a zlepšit testování;
- vylepšili proces nasazení - nyní se často nerozbíjí;
- získali možnost obnovit deploymenty po částečných selháních bez ručního zásahu;
- získali větší důvěru v dodací systémy. Alice a Bob zjistili, že mohou rozdělit tým na skupiny zabývající se mikroslužbami a pracující paralelně;omohou provádět 30-50 změn v projektu každý den díky úsilí každé skupiny a zkoušet nové techniky;
- mohou denně provádět 30-50 změn v projektu vynaložením úsilí každé skupiny a zkoušet nové techniky;
- snadno přitahují nové vývojáře k projektu, kteří mají možnost aplikovat aktualizace na produkci pomocí pull requestů již během několika hodin;
- snadno procházejí auditem v rámci SOC2 (na shodu poskytovatelů služeb s požadavky na bezpečné řízení dat; více si přečtěte například, — pozn. překl.).
Co se stalo?
GitOps — to jsou dvě věci:
- Model provozu pro Kubernetes a cloud native. Poskytuje sadu osvědčených postupů pro nasazení, správu a monitorování kontejnerovaných clusterů a aplikací. Elegantní definice v podobě od :
- Cesta k vytvoření vývojářského prostředí pro správu aplikací. Používáme pracovní postup Git jak pro provoz, tak pro vývoj. Všimněte si, že se nejedná pouze o Git push, ale o organizaci celého souboru nástrojů CI/CD a UI/UX.
Pár slov o Gitu
Pokud nejste obeznámeni se systémy pro kontrolu verzí a pracovním postupem založeným na Git, důrazně doporučujeme se s nimi seznámit. Na začátku může práce s větvemi a pull requesty působit jako černá magie, ale výhody stojí za vynaložené úsilí. Tady je k začátku.
Jak funguje Kubernetes
V našem příběhu se Alice a Bob obrátili na GitOps poté, co nějakou dobu pracovali s Kubernetes. Opravdu, GitOps je úzce spjat s Kubernetes — je to model provozu pro infrastrukturu a aplikace založené na Kubernetes.
Co Kubernetes poskytuje uživatelům?
Zde jsou některé hlavní schopnosti:
- V modelu Kubernetes lze vše popisovat v deklarativní formě.
- API server Kubernetes přijímá tento deklaraci jako vstupní data a neustále se snaží uvést cluster do stavu popsaného v deklaraci.
- Deklarace jsou dostatečné k popisu a správě širokého spektra pracovních zátěží — "aplikací".
- V důsledku toho dochází ke změnám v aplikaci a clusteru z důvodu:
- změn v obrazech kontejnerů;
- změn v deklarativní specifikaci;
- chyb v prostředí — například pád kontejnerů.
Skvělé schopnosti Kubernetes v konvergenci
Když správce provede změny v konfiguraci, orchestrace Kubernetes je aplikuje na cluster, dokud jeho stav se nepřiblíží nové konfiguraci. Tento model funguje pro jakýkoli Kubernetes zdroj a lze jej rozšířit pomocí Custom Resource Definitions (CRDs). Proto mají Kubernetes deploymenty následující úžasné vlastnosti:
- Automatizace: aktualizace Kubernetes poskytují mechanismus pro automatizaci procesu aplikace změn správně a včas.
- Konvergence: Kubernetes se bude i nadále snažit o aktualizace, dokud nebude úspěšný.
- Idempotence: opakované aplikace konvergence vedou ke stejnému výsledku.
- Determinismus: za dostatečných zdrojů je stav aktualizovaného clusteru závislý pouze na požadovaném stavu.
Jak GitOps funguje
Dostatečně jsme se naučili o Kubernetes, abychom mohli vysvětlit principy fungování GitOps.
Vraťme se k týmům Family Insurance, které se zabývají mikroslužbami. Čím se obvykle zabývají? Podívejte se na seznam níže (pokud se vám některé položky zdají podivné nebo neznámé, prosím, zdržte se kritiky a zůstaňte s námi). Toto jsou jen příklady pracovních procesů založených na Jenkinsu. Existuje také mnoho dalších procesů při práci s jinými nástroji.
Hlavní je, že vidíme, že každá aktualizace končí provedením změn v konfiguračních souborech a Git repozitářích. Tyto změny v Gitu vedou k tomu, že „GitOps operátor“ aktualizuje cluster:
1. Pracovní proces: „Jenkins build — master větev».
Seznam úkolů:
- Jenkins posílá tagované obrazy do Quay;
- Jenkins posílá konfiguraci a Helm šablony do master storage bucketu;
- Cloudová funkce zkopíruje konfiguraci a šablony z master storage bucketu do Git repozitáře master;
- GitOps operátor aktualizuje cluster.
2. Jenkins build — release nebo hotfix větev:
- Jenkins posílá netagované obrazy do Quay;
- Jenkins posílá konfiguraci a Helm šablony do staging storage bucketu;
- Cloudová funkce zkopíruje konfiguraci a šablony ze staging storage bucketu do Git repozitáře staging;
- GitOps operátor aktualizuje cluster.
3. Jenkins build — develop nebo feature větev:
- Jenkins posílá netagované obrazy do Quay;
- Jenkins posílá konfiguraci a Helm šablony do develop storage bucketu;
- Cloudová funkce zkopíruje konfiguraci a šablony z develop storage bucketu do Git repozitáře develop;
- GitOps operátor aktualizuje cluster.
4. Přidání nového klienta:
- Manager nebo administrátor (LCM/ops) spouští Gradle pro počáteční nasazení a nastavení síťových vyrovnávačů zatížení (NLB);
- LCM/ops commituje novou konfiguraci pro přípravu deploymentu na aktualizace;
- GitOps operátor aktualizuje cluster.
Krátký 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 tým Boba určuje všechny konfigurace systému v Gitu).
- Gitový repozitář je jediným zdrojem pravdy ohledně požadovaného stavu celého systému.
- Všechny změny v požadovaném stavu se provádějí prostřednictvím commitů v Gitu.
- Všechny požadované parametry clusteru jsou také pozorovatelné v samotném clusteru. Takže můžeme určit, zda se požadované a pozorované stavy shodují (konvergují, converge) nebo liší (divergují, diverge) požadované a pozorované stavy.
- Pokud se požadované a pozorované stavy liší, pak:
- Existuje mechanismus konvergence, který dříve či později automaticky synchronizuje cílový a pozorovaný stav. O to se v clusteru stará Kubernetes.
- Proces je spuštěn okamžitě s upozorněním „změna potvrzena“.
- Po určitém nastavitelného časovém intervalu může být odesláno upozornění „diff“, pokud se stavy liší.
- Takže všechny commity v Gitu vyvolávají kontrolovatelné a idempotentní aktualizace v clusteru.
- Rollback je konvergence k dříve požadovanému stavu.
- Konvergence je definitivní. O jejím dosažení svědčí:
- Nedostatek upozornění „diff“ po určitém časovém intervalu.
- Upozornění „converged“ (například webhook, událost Git writeback).
Co je divergence?
Opakujme znovu: všechny požadované vlastnosti clusteru by měly být pozorovatelné v samotném clusteru..
Několik příkladů divergence:
- Změna v konfiguračním souboru v důsledku sloučení větví v Gitu.
- Změna v konfiguračním souboru v důsledku commitu v Gitu, provedeného GUI klientem.
- Vícenásobné změny v požadovaném stavu v důsledku PR v Gitu s následným sestavením kontejnerového obrazu a změnami v konfiguraci.
- Změna stavu clusteru v důsledku chyby, konfliktu zdrojů vedoucímu k „špatnému chování“, nebo prostě náhodného odklonu od původního stavu.
Co představuje mechanismus konvergence?
Několik příkladů:
- Pro kontejnery a clustery poskytuje mechanismus konvergence Kubernetes.
- Tentýž mechanismus lze použít pro správu aplikací a konstrukcí založených na Kubernetes (například Istio a Kubeflow).
- Mechanismus pro řízení pracovního interakce mezi Kubernetes, repozitáři obrazů a Gitem poskytuje , který je součástí .
- Pro základní stroje musí být mechanismus konvergence deklarativní a autonomní. Na základě našich zkušeností můžeme říci, že se nejvíce blíží tomuto vymezení, přesto však vyžaduje lidskou kontrolu. V tomto smyslu GitOps rozšiřuje tradice Infrastructure as Code.
GitOps spojuje Git s vynikajícím mechanismem konvergence Kubernetes, nabízející model pro provoz.
GitOps nám umožňuje říct: k automatizaci a kontrole podléhají pouze systémy, které lze popisovat a sledovat.
GitOps je určen pro celý cloud native stack (např. Terraform atd.)
GitOps není jen Kubernetes. Chceme, aby celý systém byl řízen deklarativně a využíval konvergenci. Pod celým systémem rozumíme souhrn prostředí pracujících s Kubernetes – například 'dev cluster 1', 'production' atd. Do každého prostředí patří stroje, clustery, aplikace a také rozhraní pro externí služby, které poskytují data, sledování atd.
Všimněte si, jak je v tomto případě Terraform důležitý pro problém bootstrappingu. Kubernetes musí být někde nasazen, a využití Terraformu znamená, že můžeme použít stejné pracovní postupy GitOps pro vytvoření řídicí vrstvy, která leží pod Kubernetes a aplikacemi. To je užitečná osvědčená praxe.
Velká pozornost je věnována aplikaci konceptů GitOps na vrstvy nad Kubernetes. V současné době existují řešení typu GitOps pro Istio, Helm, Ksonnet, OpenFaaS a Kubeflow, stejně jako například pro Pulumi, která vytvářejí vrstvu pro vývoj aplikací pro cloud native.
Kubernetes CI/CD: srovnání GitOps s jinými přístupy
Jak bylo řečeno, GitOps je dvě věci:
- Model provozu pro Kubernetes a cloud native, popsaný výše.
- Cesta k organizaci orientované na vývojáře pro správu aplikací.
Pro mnohé je GitOps především pracovní proces založený na Git push. Nám se to také líbí. Ale to není všechno: pojďme se nyní podívat na CI/CD pipeline.
GitOps zajišťuje kontinuální nasazení (CD) pod Kubernetes
GitOps nabízí mechanismus kontinuálního nasazení, který eliminuje potřebu samostatných 'nasazovacích systémů'. Celou práci za vás vykonává Kubernetes.
- Aktualizace aplikace vyžaduje aktualizaci v Gitu. To je transakční aktualizace do požadovaného stavu. "Nasazení" se poté provádí uvnitř clusteru samotným Kubernetes na základě aktualizovaného popisu.
- Vzhledem k povaze fungování Kubernetes jsou tyto aktualizace konvergentní. To zajišťuje mechanismus pro kontinuální nasazení, kde jsou všechny aktualizace atomární.
- Poznámka: nabízí GitOps operátora, který integruje Git a Kubernetes a umožňuje provádět CD prostřednictvím souladu požadovaného a aktuálního stavu clusteru.
Bez kubectl a skriptů
Je třeba se vyhnout používání Kubectl pro aktualizaci clusteru, zejména skriptů pro seskupování příkazů kubectl. Místo toho může uživatel aktualizovat svůj cluster Kubernetes prostřednictvím GitOps pipeline.
Výhody zahrnují:
- Správnost. Skupinu aktualizací lze aplikovat, konvergovat a nakonec ověřit, což nás přibližuje k cíli atomárního nasazení. Naopak, použití skriptů neposkytuje žádné záruky konvergence (více o tom níže).
- Bezpečnost. Kelsey Hightower: "Omezte přístup k clusteru Kubernetes automatizačním nástrojům a administrátorům, jejichž úkolem je jeho ladění nebo údržba funkčnosti." Více informací viz o bezpečnosti a souladě technických podmínek, stejně jako způsobem získání přihlašovacích údajů z nedbale sestaveného Jenkins skriptu.
- Uživatelská zkušenost. Kubectl odhaluje mechaniku objektového modelu Kubernetes, který je velmi složitý. Ideálně by uživatelé měli interagovat se systémem na vyšší úrovni abstrakce. Zde se znovu odvolám na Kelsey a doporučím podívat se na .
Rozdíl mezi CI a CD
GitOps zlepšuje existující CI/CD modely.
Moderní CI server je nástrojem pro orchestraci. Konkrétně jde o nástroj pro orchestraci CI pipeline. Ty zahrnují build, test, merge to trunk atd. CI servery automatizují správu složitých vícestupňových pipeline. Častým lákadlem je vytvořit skript pro soubor aktualizací Kubernetes a spustit jej jako součásti pipeline pro push změn do clusteru. Opravu, takto to dělá mnoho specialistů. Nicméně to není optimální a zde je proč.
CI by měla být používána k aplikaci aktualizací do trunku a Kubernetes cluster by se měl měnit na základě těchto aktualizací, aby spravoval CD „interně“. Nazýváme to , na rozdíl od CI push-modelu. CD je součástí runtime-orchestrace..
Proč by CI servery neměly provádět CD prostřednictvím přímých aktualizací v Kubernetes
Nepoužívejte CI server pro orchestraci přímých aktualizací v Kubernetes ve formě sady CI úloh. To je anti-patern, o kterém jsme na našem blogu.
Vraťme se k Alici a Bobovi.
S jakými problémy se potýkali? CI server Boba aplikuje změny do clusteru, ale pokud v procesu selže, Bob nebude vědět, v jakém stavu se cluster nachází (nebo by měl být) a jak ho opravit. Totéž platí i v případě úspěchu.
Předpokládejme, že Bobův tým vytvořil nový obraz a pak opravili své nasazení, aby nainstalovali obraz (všechno to z CI pipeline).
Pokud se obraz vytvoří správně, ale pipeline selže, tým bude muset zjistit:
- Byla aktualizace nasazena?
- Spouštíme novou sestavu? Povede to k nežádoucím vedlejším účinkům – s možností mít dvě sestavy stejného neměnného obrazu?
- Máme čekat na další aktualizaci, než spustíme sestavu?
- Co přesně se pokazilo? Které kroky je třeba zopakovat (a které je bezpečné zopakovat)?
Organizace pracovního procesu založeného na Gitu nezaručuje, že tým Boba nenarazí na tyto problémy. Stále mohou udělat chybu při pushi commitu, s tagem nebo jiným parametrem; nicméně tento přístup je stále mnohem blíž k jasnému všemu nebo ničemu.
Shrneme si, proč by CI servery neměly dělat CD:
- Aktualizační skripty nejsou vždy deterministické; snadno se v nich dělají chyby.
- CI servery se neslučují s deklarativním modelem clusteru.
- Je obtížné zaručit idempotentnost. Uživatelé musí rozumět hluboké semantice systému.
- Je obtížnější provádět obnovu po částečném selhání.
Poznámka k Helm: Pokud chcete používat Helm, doporučujeme jej spojit s GitOps operátorem, jako je . To pomůže zajistit konvergenci. Sám o sobě není Helm ani deterministický, ani atomární.
GitOps jako nejlepší způsob pro realizaci Continuous Delivery pro Kubernetes
Tým Alice a Boba zavádí GitOps a zjišťuje, že práce se softwarovými produkty, udržování vysokého výkonu a stability se stává mnohem jednodušší. Ukončeme tento článek ilustracemi, které ukazují, jak vypadá jejich nový přístup. Vezměte na vědomí, že se převážně bavíme o aplikacích a službách, ale GitOps lze použít pro správu celé platformy.
Model provozu pro Kubernetes
Podívejte se na následující diagram. Znázorňuje Git a úložiště kontejnerových obrazů jako společné zdroje pro dva orchestrální životní cykly:
- Pipelines neustálé integrace, které čtou a zapisují soubory do Gitu a mohou aktualizovat repozitář kontejnerových obrazů.
- Pipelines Runtime GitOps, které kombinují nasazení s řízením a sledováním. Čte a zapisuje soubory do Gitu a může stahovat kontejnerové obrazy.
Jaké jsou hlavní závěry?
- Dělení problémů: Všimněte si, že oba pipelines si mohou vyměňovat data pouze aktualizací Gitu nebo repozitáře obrazů. Jinými slovy, existuje firewall mezi CI a runtime prostředím. Nazýváme jej „firewallem neměnnosti“ (immutability firewall), protože všechny aktualizace repozitářů vytvářejí nové verze. Pro více informací k tomuto tématu se podívejte na slajdy 72-87 .
- Lze použít jakýkoli CI a Git server: GitOps funguje s jakýmikoli komponenty. Můžete nadále používat své oblíbené CI a Git servery, repozitáře obrazů a testovací sady. Téměř všechny ostatní nástroje pro Continuous Delivery na trhu vyžadují svůj vlastní CI/Git server nebo úložiště obrazů. To může být omezujícím faktorem v rozvoji cloud native. V případě GitOps můžete používat známé nástroje.
- Události jako nástroj integrace: Jakmile jsou data v Git aktualizována, Weave Flux (nebo Weave Cloud operator) o tom informuje runtime. Kdykoli Kubernetes přijme sadu změn, Git se aktualizuje. To zajišťuje jednoduchý model integrace pro organizaci pracovních toků pro GitOps, jak je ukázáno níže.
Závěr
GitOps poskytuje zásadní záruky aktualizací, které jsou nezbytné pro jakýkoli moderní nástroj CI/CD:
- automatizace;
- konvergence;
- idempotentnost;
- determinismus.
Je to důležité, protože nabízí provozní model pro vývojáře v oblasti cloud native.
- Tradiční nástroje pro správu a monitorování systémů jsou spojeny s provozními týmy, které fungují v rámci runbooku (sady rutinních procedur a operací — pozn. př.), navázaného na konkrétní nasazení.
- V řízení cloud native systémů je nástroj pro sledování nejlepším způsobem, jak vyhodnotit výsledky nasazení, aby na ně vývojový tým mohl rychle reagovat.
Představte si celou řadu klastrů rozložení po různých cloudech a množství služeb se svými vlastními týmy a plány nasazení. GitOps nabízí škálově invariantní model pro správu celé této rozmanitosti.
P.S. od překladatele
Přečtěte si také náš blog:
- «»;
- «»;
- «».
Pouze registrovaní uživatelé se mohou účastnit ankety. , prosím.
Věděli jste o GitOps před vznikem těchto dvou překladů na habru?
Ano, všechno jsem věděl(a)
Jen povrchně
Ne
Hlasovalo 35 uživatelů. 10 uživatelů se zdrželo.
Zdroj: habr.com
