Pozn. přek.: V komunitě Kubernetes získává na popularitě trend zvaný GitOps, čemuž jsme se osobně přesvědčili, KubeCon Europe 2019. Tento termín byl relativně nedávno šéfem společnosti Weaveworks — Alexisem Richardstonem — a znamená využití běžných nástrojů pro vývojáře (především Git, odtud i název) pro řešení provozních úkolů. Konkrétně jde o provoz Kubernetes prostřednictvím ukládání jeho konfigurací v Gitu a automatického nasazení změn do clusteru. O dvou přístupech k tomuto nasazení hovoří Matthias Jg v tomto článku.
V loňském roce (ve skutečnosti se to formálně stalo v srpnu 2017 — pozn. překl.) se objevil nový přístup k nasazení aplikací v Kubernetes. Nazývá se GitOps a jeho základem je základní představa, že verze nasazení jsou sledovány v bezpečném prostředí gitového repozitáře.
Hlavní výhody tohoto přístupu jsou následující:
- Versionování nasazení a historie změn. Stav celého clusteru je uložen v gitovém repozitáři a nasazení se aktualizují pouze pomocí commitů. Navíc je možné sledovat všechny změny prostřednictvím historie commitů.
- Vrátit pomocí běžných gitových příkazů. Snadné
git resetumožňuje vrátit změny v nasazeních; vždy jsou k dispozici předchozí stavy. - Hotová kontrola přístupu. Obvykle gitový systém obsahuje mnoho důvěrných informací, proto většina společností věnuje zvláštní pozornost jeho ochraně. Tato ochrana se tedy vztahuje také na operace s nasazením.
- Politiky pro nasazení. Většina gitových systémů zpočátku podporuje politiky pro různé větve — například pouze pull requesty mohou aktualizovat master, a změny musí schválit a přijmout jiný člen týmu. Stejně jako u kontroly přístupu se stejné politiky uplatňují na aktualizace nasazení.
Jak vidíte, metoda GitOps má mnoho výhod. V uplynulém roce si dvě přístupy získaly zvláštní popularitu. Jeden je založen na push, druhý na pull. Než se na ně podíváme, podívejme se nejprve, jak vypadají typická nasazení Kubernetes.
Způsoby nasazení
V posledních letech se v Kubernetes ustálily různé způsoby a nástroje pro nasazení:
- Na základě domácích šablon Kubernetes/Kustomize. To je nejjednodušší způsob nasazení aplikací na Kubernetes. Vývojář vytváří základní YAML soubory a aplikuje je. Aby se zbavil neustálého přepisování stejných šablon, byl vyvinut Kustomize (ten přetváří šablony Kubernetes na moduly). Pozn. přek.: Kustomize byl integrován do kubectl s .
- Helm Charts. Helm Charts umožňují vytvářet sady šablon, init kontejnery, sidecary atd., které se používají pro nasazení aplikací s flexibilnějšími možnostmi konfigurace než v přístupu založeném na šablonách. Tento přístup je založen na šablonizovaných YAML souborech. Helm je vyplňuje různými parametry a poté je posílá Tilleru — klastrové komponentě, která je nasazuje do clustru a umožňuje provádět aktualizace a návraty zpět. Důležité je, že Helm v podstatě jen vkládá potřebné hodnoty do šablon a následně je aplikuje stejně, jako se to dělá v tradičním přístupu. (více o tom, jak to všechno funguje a jak to lze použít, si přečtěte v naší — pozn. překl.). Existuje velké množství hotových Helm chartů, pokrývajících široké spektrum úkolů.
- Alternativní nástroje. Existuje mnoho alternativních nástrojů. Všechny spojuje to, že převádějí určité šablonové soubory na srozumitelné Kubernetes YAML soubory a následně je aplikují.
Ve své práci neustále používáme Helm chart pro důležité nástroje (protože v nich je již mnoho připraveno, což značně usnadňuje život) a 'čisté' YAML soubory Kubernetes pro nasazení vlastních aplikací.
Pull & Push
V jednom ze svých nedávných příspěvků na blogu jsem představil nástroj , který umožňuje commitovat šablony do Git repozitáře a aktualizovat deployment po každém commitu nebo pushi kontejneru. Moje zkušenosti ukazují, že tento nástroj je jedním z klíčových v propagaci pull přístupu, a proto se na něj budu často odkazovat. Pokud se chcete dozvědět více o tom, jak ho používat, zde je .
NB! Všechny výhody používání GitOps zůstávají pro oba přístupy.
Pull přístup
Základní myšlenka přístupu pull spočívá v tom, že všechny změny se aplikují zevnitř clusteru. Uvnitř clusteru je operátor, který pravidelně kontroluje související repozitáře Git a Docker Registry. Pokud dojde k jakýmkoli změnám, stav clusteru se aktualizuje zevnitř. Obvykle se považuje, že tento proces je poměrně bezpečný, protože žádný externí klient nemá přístup k administrátorským právům clusteru.
Plusy:
- Žádný externí klient nemá práva provádět změny v clusteru, veškeré aktualizace se provádějí zevnitř.
- Některé nástroje také umožňují synchronizaci aktualizací Helm chartů a jejich přiřazení k clusteru.
- Docker Registry lze skenovat na nové verze. Pokud se objeví nový obraz, Git repozitář a deployment se aktualizují na novou verzi.
- Pull nástroje mohou být distribuovány mezi různými jmennými prostory s různými repozitáři Git a přístupovými právy. Díky tomu lze použít multitenantní model. Například tým A může používat jmenný prostor A, tým B jmenný prostor B, a tým zabývající se infrastrukturou může používat globální prostor.
- Obecně jsou nástroje velmi lehké.
- V kombinaci s nástroji jako je operátor , mohou být tajemství uchovávána v zašifrované podobě v Git repozitáři a vytažena uvnitř clusteru.
- Není zde žádná vazba na CD pipeline, neboť nasazení probíhá uvnitř clusteru.
Nevýhody:
- Správa tajemství nasazení z Helm chartů je složitější než u běžných, protože je nejprve třeba generovat v podobě, řekněme, sealed secrets, poté je dešifrovat interním operátorem a až pak se stávají dostupnými pro pull nástroj. Poté lze spustit release v Helmu se hodnotami, které jsou již nasazeny v tajemstvích. Nejjednodušší způsob je vytvořit tajemství se všemi hodnotami Helm, které se používají pro nasazení, dešifrovat ho a zcommitovat do Gitu.
- Používáním přístupu pull jste vázáni nástroji pracujícími s pull. To omezuje možnosti přizpůsobení procesu nasazení v clusterech. Například práce s Kustomize je složitější, protože musí být provedena před tím, než konečné šablony dorazí do Gitu. Neříkám, že nemůžete používat jednotlivé nástroje, ale je obtížnější je integrovat do procesu nasazení.
Přístup na základě Push
Ve vzdáleném přístupu spouští externí systém (převážně CD pipeline) nasazení v clusteru po commitu do Git repozitáře nebo v případě úspěšného dokončení předchozího CI pipeline. V tomto přístupu má systém přístup do clusteru.
Výhody:
- Bezpečnost je určena Git repozitářem a build pipeline.
- Nasazení Helm chartů je snazší, existuje podpora pro Helm pluginy.
- Správa tajemství je snazší, protože je možné je používat v pipelines a také je uchovávat v Gitu v zašifrované podobě (v závislosti na preferencích uživatele).
- Není zde vázanost na konkrétní nástroj, protože lze použít jakýkoliv jejich typ.
- Aktualizace verzí kontejnerů mohou být iniciovány build pipeline.
Nevýhody:
- Údaje pro přístup k clustru se nacházejí uvnitř build systému.
- Aktualizace kontejnerů v nasazení jsou stále jednodušší provádět pomocí pull procesu.
- Silná závislost na CD systému, protože potřebné pipeline byly možná původně napsány pro Gitlab Runners, a poté se tým rozhodne přejít na Azure DevOps nebo Jenkins... a bude nutné migrovat velké množství build pipeline.
Shrnutí: Push nebo Pull?
Jak to obvykle bývá, každý přístup má své klady a zápory. Některé úkoly se lépe plní jedním způsobem a složitěji druhým. Zpočátku jsem prováděl nasazení ručně, ale poté, co jsem narazil na několik článků o Weave Flux, jsem se rozhodl zavést procesy GitOps pro všechny projekty. Pro základní šablony to bylo snadné, ale pak jsem začal narážet na obtíže při práci s Helm chartami. V té době Weave Flux nabízel pouze základní verzi Helm Chart Operatoru, ale i dnes jsou některé úkoly složitější kvůli nutnosti ručně vytvářet tajemství a aplikovat je. Můžete říci, že pull přístup je mnohem bezpečnější, protože přihlašovací údaje k clustru nejsou dostupné mimo něj, což zvyšuje bezpečnost natolik, že to stojí za dodatečné úsilí.
Po krátkém zamyšlení jsem dospěl k překvapivému závěru, že tomu tak není. Pokud hovoříme o komponentech, které vyžadují maximální ochranu, sem patří úložiště tajemství a CI/CD systémy, Git repositáře. Informace uvnitř nich jsou velmi zranitelné a vyžadují maximální ochranu. Kromě toho, pokud se někdo dostane do vašeho Git repositáře a bude moci pushovat kód, může nasadit vše, co si přeje (bez ohledu na to, zda je to pull nebo push), a proniknout do systémů clustru. Takže nejdůležitějšími komponenty, které potřebují ochranu, jsou Git repositář a CI/CD systémy, nikoli přihlašovací údaje k clustru. Pokud máte dobře nastavené politiky a bezpečnostní opatření pro takové systémy, a přihlašovací údaje k clustru se do pipeline dostávají pouze jako tajemství, dodatečná bezpečnost pull přístupu může být méně cenná, než se původně předpokládalo.
Pokud je tedy pull přístup pracnější a nepřináší žádné výhody z hlediska bezpečnosti, není logické používat pouze push přístup? Ale někdo by mohl říci, že v push přístupu jste příliš závislí na CD systému a možná by bylo lepší to nedělat, abyste v budoucnu usnadnili migrace.
Podle mého názoru (jako obvykle) by se mělo použít to, co nejlépe vyhovuje konkrétní situaci, nebo kombinovat obě přístupy. Osobně používám oba přístupy: Weave Flux pro deploymenty na základě pull, které většinou zahrnují naše vlastní služby, a push přístup s Helm a pluginy, což usnadňuje použití Helm chartů na cluster a umožňuje snadno vytvářet tajné klíče. Myslím, že nikdy nebude jedno univerzální řešení, které by vyhovovalo všem případům, protože existuje spousta nuancí, které se liší v závislosti na konkrétní aplikaci. Při tom důrazně doporučuji GitOps — výrazně usnadňuje život a zvyšuje bezpečnost.
Doufám, že mé zkušenosti v této oblasti pomohou určit, který přístup je pro váš typ deploymentů nejvhodnější, a rád bych se dozvěděl váš názor.
P.S. Poznámka od překladatele
Mezi nevýhodami pull modelu je bod, že je obtížné uložit v Gitu renderované manifesty, nicméně není nevýhodou, že CD pipeline v pull modelu žije odděleně od nasazení a v podstatě se stává pipeline kategorie Continuous Apply. Proto bude třeba vynaložit ještě více úsilí k tomu, aby bylo možné shromažďovat stav všech deploymentů a nějakým způsobem poskytovat přístup k logům/stavu, přičemž je žádoucí mít to napojené na CD systém.
V tomto smyslu push model umožňuje poskytnout alespoň nějaké záruky nasazení, protože životnost pipeline může být nastavena na dobu životnosti nasazení.
Otestovali jsme obě modely a došli jsme k těmto stejným závěrům jako autor článku:
- Pull model nám vyhovuje pro organizaci aktualizací systémových komponent na velkém množství clusterů (viz) ).
- Push model založený na GitLab CI je dobře přizpůsoben pro nasazení aplikací pomocí Helm chartů. Při tom je provádění deploymentů sledováno pomocí nástroje . Mimochodem, v kontextu tohoto našeho projektu jsme neustále slýchali „GitOps“, když jsme diskutovali o aktuálních problémech DevOps inženýrů na našich stáncích na KubeCon Europe’19.
P.P.S. od překladatele
Přečtěte si také náš blog:
- «»;
- «»;
- «»;
- «».
Pouze registrovaní uživatelé se mohou účastnit ankety. , prosím.
Používáte GitOps?
Ano, pull přístup
Ano, push
Ano, pull + push
Ano, něco jiného
Ne
Hlasovalo 30 uživatelů. 10 uživatelů se zdrželo.
Zdroj: habr.com
