Většina z nás, když si všimne dalšího nového termínu v IT blogosféře nebo konferenci, si dříve nebo později položí podobnou otázku: „Co je to? Jen další módní slovo, „módní slovo“ nebo něco, co opravdu stojí za pozornost, studium a příslib nových obzorů? To samé se mi stalo s termínem GitOps před nějakým časem. Vyzbrojeni mnoha existujícími články a také znalostmi kolegů z firmy , snažil jsem se přijít na to, o jakou bestii se jedná a jak by její využití mohlo vypadat v praxi.
Mimochodem, o novosti termínu GitOps Náš nedávný průzkum také říká: více než polovina dotázaných s jeho principy ještě nezačala pracovat.
Problém správy infrastruktury tedy není nový. Mnoho poskytovatelů cloudu je k dispozici široké veřejnosti už dobrých deset let a zdálo by se, že měli zjednodušit a zpřehlednit práci týmů odpovědných za infrastrukturu. Ve srovnání s procesem vývoje aplikací (kde automatizace dosahuje stále nové úrovně) však infrastrukturní projekty stále často zahrnují mnoho manuálních úkolů a vyžadují specializované znalosti a odborné znalosti, zejména s ohledem na dnešní požadavky na odolnost proti chybám, flexibilitu, škálovatelnost a elasticitu.
Cloudové služby tyto požadavky velmi úspěšně naplňovaly a byly to právě ony, kdo dal významný impuls k rozvoji přístupu IAC. To je pochopitelné. Koneckonců umožnily nakonfigurovat zcela virtuální datové centrum: neexistují žádné fyzické servery, racky ani síťové komponenty, celou infrastrukturu lze popsat pomocí skriptů a konfiguračních souborů.
Jaký je tedy přesně rozdíl? GitOps z IAC? Touto otázkou jsem začal své pátrání. Po rozhovoru s kolegy jsem byl schopen přijít s následujícím srovnáním:
GitOps
IAC
Veškerý kód je uložen v úložišti git
Verze kódu je volitelné
Popis deklarativního kódu / idempotence
Přijatelné jsou deklarativní i imperativní popisy
Změny se projeví pomocí mechanismu Požadavek na sloučení / Požadavek na stažení
Dohoda, schválení a spolupráce jsou volitelné
Proces zavádění aktualizací je automatizovaný
Proces zavádění aktualizací není standardizován (automatické, ruční, kopírování souborů, pomocí příkazového řádku atd.)
Jinými slovy GitOps se zrodilo právě aplikací principů IAC. Za prvé, infrastruktura a konfigurace mohou být nyní uloženy stejným způsobem jako aplikace. Kód lze snadno ukládat, snadno sdílet, porovnávat a používat možnosti správy verzí. Verze, větve, historie. A to vše na místě veřejně přístupném celému týmu. Proto se používání systémů pro správu verzí stalo zcela přirozeným vývojem. Zejména git, jako nejoblíbenější.
Na druhou stranu bylo možné automatizovat procesy správy infrastruktury. Nyní to lze provést rychleji, spolehlivěji a levněji. Kromě toho byly principy CI / CD již známé a oblíbené mezi vývojáři softwaru. Bylo potřeba pouze přenést a aplikovat již známé znalosti a dovednosti do nové oblasti. Tyto praktiky však šly nad rámec standardní definice infrastruktury jako kódu, tedy konceptu GitOps.
Zvědavost GitOps, samozřejmě také v tom, že se nejedná o produkt, plugin nebo platformu spojenou s jakýmkoliv dodavatelem. Je to spíše paradigma a soubor principů, podobně jako jiný termín, který známe: DevOps.
Společnost vyvinuli jsme dvě definice tohoto nového pojmu: teoretickou a praktickou. Začněme teoreticky:
GitOps je metodika, která přebírá nejlepší principy DevOps používané pro vývoj aplikací, jako je správa verzí, spolupráce, orchestrace, CI/CD, a aplikuje je na výzvy automatizace správy infrastruktury.
Všechny procesy GitOps Pracuji pomocí stávajících nástrojů. Veškerý kód infrastruktury je uložen v již známém úložišti git, změny procházejí stejným schvalovacím procesem jako jakýkoli jiný programový kód a proces zavádění je automatizovaný, což nám umožňuje minimalizovat lidské chyby, zvýšit spolehlivost a reprodukovatelnost.
Z praktického hlediska popisujeme GitOps takto:
Již jsme diskutovali o infrastruktuře jako kódu jako o jedné z klíčových součástí tohoto vzorce. Pojďme si představit zbytek účastníků.
Požadavek na sloučení (alternativní název Pull Request). Z hlediska procesu je MR požadavek na použití změn kódu a následné sloučení větví. Ale pokud jde o nástroje, které používáme, je to spíše příležitost získat úplný obrázek o všech provedených změnách: nejen kódový rozdíl shromážděný z určitého počtu odevzdání, ale také kontext, výsledky testů a konečný očekávaný výsledek. Pokud mluvíme o kódu infrastruktury, pak nás zajímá, jak přesně se infrastruktura změní, kolik nových zdrojů bude přidáno nebo odebráno, změněno. Nejlépe v nějakém pohodlnějším a lépe čitelném formátu. Pro poskytovatele cloudu je dobré vědět, jaký bude mít tato změna finanční dopad.
Ale MR je také prostředkem spolupráce, interakce a komunikace. Místo, kde do hry vstupuje systém brzd a protivah. Od jednoduchých komentářů až po formální schválení a schválení.
No a poslední komponenta: CI/CD, jak již víme, umožňuje automatizovat proces provádění změn infrastruktury a testování (od jednoduché kontroly syntaxe po složitější analýzu statického kódu). A také v následné detekci driftu: rozdíly mezi skutečným a požadovaným stavem systému. Například v důsledku neoprávněných ručních změn nebo selhání systému.
Ano, termín GitOps nepředstavuje nám nic zcela nového, nevynalézá znovu kolo, ale jednoduše aplikuje již nasbírané zkušenosti v nové oblasti. Ale právě v tom je jeho síla.
A pokud vás najednou začne zajímat, jak to všechno vypadá v praxi, zvu vás, abyste se podívali na naše , ve kterém vám krok za krokem řeknu, jak používat GitLab:
-
Implementujte základní principy GitOps
-
Vytvořte a provádějte změny v cloudové infrastruktuře (na příkladu Yandex Cloud)
-
Automatizujte detekci odchylky systému od požadovaného stavu pomocí aktivního monitorování
https://bit.ly/34tRpwZ
Zdroj: www.habr.com