Poznámka. přel.: V komunitě Kubernetes získává trend zvaný GitOps zjevnou popularitu, jak jsme osobně viděli, KubeCon Europe 2019. Tento termín byl relativně nedávný od šéfa Weaveworks - Alexise Richardsona - a znamená použití nástrojů známých vývojářům (především Git, odtud název) k řešení provozních problémů. Konkrétně mluvíme o fungování Kubernetes ukládáním jeho konfigurací v Gitu a automatickým zaváděním změn do clusteru. Matthias Jg v tomto článku hovoří o dvou přístupech k tomuto zavedení.
V loňském roce, (ve skutečnosti se tak formálně stalo v srpnu 2017 - cca překlad.) V Kubernetes existuje nový přístup k nasazování aplikací. Jmenuje se GitOps a je založen na základní myšlence, že verze nasazení jsou sledovány v zabezpečeném prostředí úložiště Git.
Hlavní výhody tohoto přístupu jsou následující::
- Verze nasazení a historie změn. Stav celého clusteru je uložen v úložišti Git a nasazení se aktualizují pouze prostřednictvím potvrzení. Všechny změny lze navíc sledovat pomocí historie odevzdání.
- Vrácení zpět pomocí známých příkazů Git... Prostý
git resetumožňuje resetovat změny v nasazení; minulé stavy jsou vždy k dispozici. - Připravená kontrola přístupu. Systém Git obvykle obsahuje mnoho citlivých dat, takže většina společností věnuje zvláštní pozornost jejich ochraně. V souladu s tím se tato ochrana vztahuje také na operace s nasazením.
- Zásady pro nasazení. Většina systémů Git nativně podporuje zásady pro jednotlivé větve – například pouze žádosti o stažení mohou aktualizovat hlavní server a změny musí zkontrolovat a přijmout jiný člen týmu. Stejně jako u řízení přístupu platí stejné zásady pro aktualizace nasazení.
Jak vidíte, metoda GitOps má mnoho výhod. Za poslední rok si získaly zvláštní oblibu dva přístupy. Jeden je založen na tlaku, druhý na tahu. Než se na ně podíváme, podívejme se nejprve, jak vypadají typická nasazení Kubernetes.
Metody nasazení
V posledních letech se v Kubernetes prosadily různé metody a nástroje pro nasazení:
- Na základě nativních šablon Kubernetes/Kustomize. Toto je nejjednodušší způsob nasazení aplikací na Kubernetes. Vývojář vytvoří základní soubory YAML a použije je. Abychom se zbavili neustálého přepisování stejných šablon, byl vyvinut Kustomize (proměňuje šablony Kubernetes na moduly). Poznámka. přel.: Kustomize byla integrována do kubectl s .
- Tabulka kormidla. Helm grafy umožňují vytvářet sady šablon, init kontejnerů, postranních vozíků atd., které se používají k nasazení aplikací s flexibilnějšími možnostmi přizpůsobení než v přístupu založeném na šablonách. Tato metoda je založena na šablonách souborů YAML. Helm je naplní různými parametry a poté je odešle do Tilleru, součásti clusteru, která je nasadí do clusteru a umožní aktualizace a vrácení zpět. Důležité je, že Helm v podstatě pouze vloží požadované hodnoty do šablon a poté je aplikuje stejným způsobem jako v tradičním přístupu. (přečtěte si více o tom, jak to všechno funguje a jak to můžete použít v našem - Cca. překlad.). Existuje široká škála hotových Helmových diagramů pokrývajících širokou škálu úkolů.
- Alternativní nástroje. Existuje mnoho alternativních nástrojů. Všechny mají společné to, že převádějí některé soubory šablon na soubory YAML čitelné pro Kubernetes a pak je používají.
Při naší práci neustále využíváme Helm grafy pro důležité nástroje (protože mají spoustu věcí již připravených, což značně usnadňuje život) a „čisté“ soubory Kubernetes YAML pro nasazení vlastních aplikací.
Pull & Push
V jednom ze svých nedávných příspěvků na blogu jsem tento nástroj představil , který vám umožňuje odevzdat šablony do úložiště Git a aktualizovat nasazení po každém potvrzení nebo odeslání kontejneru. Moje zkušenost ukazuje, že tento nástroj je jedním z hlavních při prosazování pull přístupu, takže na něj budu často odkazovat. Pokud se chcete dozvědět více o tom, jak jej používat, zde .
NB! Všechny výhody používání GitOps zůstávají pro oba přístupy stejné.
Pull based přístup
Přístup pull je založen na skutečnosti, že všechny změny jsou aplikovány zevnitř clusteru. Uvnitř clusteru je operátor, který pravidelně kontroluje přidružená úložiště registru Git a Docker. Pokud se u nich vyskytnou nějaké změny, stav clusteru se interně aktualizuje. Tento proces je obecně považován za velmi bezpečný, protože žádný externí klient nemá přístup k právům správce clusteru.
výhody:
- Žádný externí klient nemá práva provádět změny v clusteru, všechny aktualizace jsou zaváděny zevnitř.
- Některé nástroje také umožňují synchronizovat aktualizace grafu Helm a propojit je s clusterem.
- Docker Registry lze skenovat na nové verze. Pokud je k dispozici nový obraz, úložiště Git a nasazení se aktualizují na novou verzi.
- Pull nástroje lze distribuovat napříč různými jmennými prostory s různými repozitáři Git a oprávněními. Díky tomu lze využít multitenantský model. Například tým A může používat jmenný prostor A, tým B může používat jmenný prostor B a tým infrastruktury může používat globální prostor.
- Nástroje jsou zpravidla velmi lehké.
- V kombinaci s nástroji, jako je operátor , mohou být tajné klíče uloženy zašifrovány v úložišti Git a načteny v rámci clusteru.
- Neexistuje žádné připojení k kanálům CD, protože k nasazení dochází v rámci clusteru.
Zápory:
- Správa tajných klíčů nasazení z Helmových diagramů je obtížnější než běžných, protože je nejprve nutné vygenerovat ve formě, řekněme, zapečetěných tajných klíčů, poté je dešifruje interní operátor a teprve poté je zpřístupní nástroj pro stahování. Poté můžete spustit vydání v Helm s hodnotami v již nasazených tajných klíčích. Nejjednodušší způsob je vytvořit tajemství se všemi hodnotami Helm použitými pro nasazení, dešifrovat ho a odevzdat do Gitu.
- Když použijete tahový přístup, stanete se připoutáni k tažným nástrojům. To omezuje možnost přizpůsobit proces nasazení v clusteru. Kustomize je například komplikovaná tím, že musí běžet před tím, než jsou finální šablony odevzdány do Gitu. Neříkám, že nemůžete používat samostatné nástroje, ale je obtížnější je integrovat do vašeho procesu nasazení.
Push založený přístup
V přístupu push externí systém (hlavně kanály CD) spouští nasazení do clusteru po potvrzení do úložiště Git nebo pokud je předchozí kanál CI úspěšný. V tomto přístupu má systém přístup ke clusteru.
Pros:
- Zabezpečení je určeno úložištěm Git a kanálem sestavení.
- Nasazení grafů Helm je jednodušší a podporuje moduly plug-in Helm.
- Tajné informace se snáze spravují, protože tajné informace lze používat v kanálech a lze je také ukládat zašifrované v Gitu (v závislosti na preferencích uživatele).
- Neexistuje žádné spojení s konkrétním nástrojem, protože lze použít jakýkoli typ.
- Aktualizace verzí kontejneru mohou být iniciovány kanálem sestavení.
Zápory:
- Přístupová data clusteru jsou uvnitř systému sestavení.
- Aktualizace kontejnerů nasazení je stále jednodušší díky procesu stahování.
- Silná závislost na systému CD, protože kanály, které potřebujeme, mohly být původně napsány pro Gitlab Runners, a pak se tým rozhodne přejít na Azure DevOps nebo Jenkins... a bude muset migrovat velké množství kanálů sestavení.
Výsledky: Push nebo Pull?
Jak už to tak bývá, každý přístup má své pro a proti. Některé úkoly jsou snáze splnitelné s jedním a obtížnější s jiným. Nejprve jsem dělal nasazení ručně, ale poté, co jsem narazil na pár článků o Weave Flux, jsem se rozhodl implementovat procesy GitOps pro všechny projekty. Pro základní šablony to bylo snadné, ale pak jsem začal narážet na potíže s Helmovými diagramy. V té době Weave Flux nabízel pouze základní verzi Helm Chart Operator, ale i nyní jsou některé úkoly obtížnější kvůli nutnosti ručně vytvářet tajemství a používat je. Můžete namítnout, že přístup pull je mnohem bezpečnější, protože přihlašovací údaje clusteru nejsou přístupné mimo cluster, takže je mnohem bezpečnější, že to stojí za další úsilí.
Po chvíli přemýšlení jsem došel k nečekanému závěru, že tomu tak není. Pokud mluvíme o komponentách, které vyžadují maximální ochranu, tento seznam bude zahrnovat tajné úložiště, systémy CI/CD a úložiště Git. Informace v nich jsou velmi zranitelné a potřebují maximální ochranu. Navíc, pokud se někdo dostane do vašeho úložiště Git a může tam poslat kód, může nasadit, co chce (ať už je to pull nebo push) a infiltrovat systémy clusteru. Nejdůležitější komponenty, které je třeba chránit, jsou tedy úložiště Git a systémy CI/CD, nikoli přihlašovací údaje ke clusteru. Pokud máte dobře nakonfigurované zásady a ovládací prvky zabezpečení pro tyto typy systémů a přihlašovací údaje klastru jsou extrahovány do kanálů pouze jako tajná tajemství, nemusí být přidané zabezpečení přístupu vyžádaného přístupu tak cenné, jak se původně myslelo.
Pokud je tedy přístup tahu náročnější na pracovní sílu a neposkytuje bezpečnostní výhodu, není logické používat pouze přístup tahu? Někdo by ale mohl namítnout, že v přístupu push jste příliš svázáni se systémem CD a možná je lepší to nedělat, aby bylo v budoucnu snazší provádět migrace.
Podle mého názoru (jako vždy) byste měli použít to, co je pro konkrétní případ nebo kombinaci nejvhodnější. Osobně používám oba přístupy: Weave Flux pro nasazení založená na stahování, která většinou zahrnují naše vlastní služby, a přístup push s Helmem a pluginy, který usnadňuje aplikaci Helmových grafů na cluster a umožňuje bezproblémové vytváření tajemství. Myslím, že nikdy nebude existovat jediné řešení vhodné pro všechny případy, protože nuancí je vždy hodně a ty závisí na konkrétní aplikaci. Jak již bylo řečeno, vřele doporučuji GitOps – velmi usnadňuje život a zlepšuje zabezpečení.
Doufám, že moje zkušenosti na toto téma vám pomohou rozhodnout, která metoda je pro váš typ nasazení vhodnější, a rád si vyslechnu váš názor.
PS Poznámka od překladatele
Nevýhodou modelu stahování je to, že je obtížné umístit vykreslené manifesty do systému Git, ale neexistuje žádná nevýhoda, že kanál CD v modelu stahování žije odděleně od zavádění a v podstatě se stává kanálem kategorií. Nepřetržité použití. Proto bude zapotřebí ještě více úsilí, abychom shromáždili jejich stav ze všech nasazení a nějakým způsobem poskytli přístup k protokolům/stavu, nejlépe s odkazem na systém CD.
V tomto smyslu nám push model umožňuje poskytnout alespoň nějaké záruky rolloutu, protože životnost pipeline se může rovnat životnosti rolloutu.
Vyzkoušeli jsme oba modely a došli jsme ke stejným závěrům jako autor článku:
- Pull model je pro nás vhodný pro organizaci aktualizací systémových komponent na velkém počtu clusterů (viz. ).
- Push model založený na GitLab CI se dobře hodí pro zavádění aplikací pomocí Helmových grafů. Zároveň je pomocí nástroje monitorováno zavádění nasazení v rámci potrubí . Mimochodem, v kontextu tohoto našeho projektu jsme slyšeli neustálé „GitOps“, když jsme na našem stánku na KubeCon Europe'19 diskutovali o naléhavých problémech inženýrů DevOps.
PPS z překladače
Přečtěte si také na našem blogu:
- «";
- «";
- «";
- «".
Průzkumu se mohou zúčastnit pouze registrovaní uživatelé. , prosím.
Používáte GitOps?
-
Ano, tahový přístup
-
Ano, tlačit
-
Ano, táhnout + tlačit
-
Ano, ještě něco
-
Ne
Hlasovalo 30 uživatelů. 10 uživatelů se zdrželo hlasování.
Zdroj: www.habr.com