Většina z nás, když si všimne nového termínu v IT blogosféře nebo na konferenci, se dříve či později ptá: „Co to je? Další módní slovo, 'buzzword', nebo skutečně něco, co stojí za pozornost, studium a slibuje nové obzory?“ To samé jsem si říkal i já ohledně termínu GitOps , který se objevil před nějakým časem. Vyzbrojen množstvím již existujících článků a také znalostí kolegů z firmy , jsem se pokusil zjistit, co to vlastně je a jak by jeho aplikace mohla vypadat v praxi.
Mimochodem, o novosti termínu GitOps rovněž svědčí nedávný průzkum, který jsme provedli: více než polovina dotázaných s jeho principy ještě nezačala pracovat.
Takže problém správy infrastruktury není nový. Množství cloudových poskytovatelů je již dobrých deset let dostupných široké veřejnosti a zdálo by se, že by měly usnadnit práci týmům odpovědným za infrastrukturu. Nicméně, v porovnání s procesem vývoje aplikací (kde úroveň automatizace dosahuje stále nových a nových obzorů), infrastrukturní projekty stále často zahrnují mnoho manuálně prováděných úkolů a vyžadují zvláštní znalosti a specialisty, zejména s ohledem na moderní požadavky na odolnost, flexibilitu, škálovatelnost a elasticitu.
Cloudové služby tyto požadavky velmi úspěšně splnily a právě ony daly významný impuls k rozvoji přístupu IaC. Není divu. Vždyť právě ony poskytly možnost konfigurovat kompletně virtuální datové centrum: žádné fyzické servery, racky, síťové komponenty, celou infrastrukturu je možné popsat pomocí skriptů a konfiguračních souborů.
Jaký je tedy vlastně rozdíl GitOps od IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:
GitOps
IaC
Celý kód je uložen v git repozitáři
Verzování kódu není povinné
Deklarativní popis kódu / Idempotentnost
Přijatelné je jak deklarativní, tak imperativní popis
Změny vstupují v platnost pomocí mechanismu Merge Request / Pull Request
Schvalování, potvrzení a spolupráce nejsou povinné
Proces nasazení aktualizací je automatizován
Proces nasazení aktualizací není standardizován (automatický, ruční, kopírování souborů, použití příkazového řádku atd.)
Jinými slovy GitOps byl vytvořen díky aplikaci principů IaC. Za prvé, infrastruktura a konfigurace mohly být nyní uchovávány stejně jako aplikace. Kód se snadno ukládá, sdílí, porovnává a využívá verzovací možnosti. Verze, větve, historie. A to vše na veřejně přístupném místě pro celý tým. Proto se logickým vývojem stalo využití systémů pro správu verzí. Zejména git jako nejpopulárnější.
Na druhé straně vznikla možnost automatizovat procesy správy infrastruktury. Nyní to lze udělat rychleji, spolehlivěji a levněji. O to víc, že principy CI/CD už byly známé a populární mezi vývojáři softwaru. Bylo potřeba pouze převést a aplikovat již známé znalosti a dovednosti do nové oblasti. Tyto praktiky však překračovaly rámec standardní definice Infrastruktury jako kódu, odtud vznikl pojem GitOps.
Zvědavost GitOps, samozřejmě, spočívá také v tom, že to není produkt, plugin nebo platforma spojená s jakýmikoli dodavateli. Je to spíše paradigma a soubor principů, podobně jako jiný známý pojem: DevOps.
Ve společnosti vytvořili jsme dvě definice tohoto nového termínu: teoretickou a praktickou. Začněme teoretickou:
GitOps je metodologie, která používá pokročilé principy DevOps, používané pro vývoj aplikací, jako je správa verzí, spolupráce, schvalování, CI/CD, a aplikuje je k řešení úkolů automatizace správy infrastruktury.
Všechny procesy GitOps fungují s již existujícími nástroji. Veškerý kód infrastruktury je uložen ve známém git repozitari, změny procházejí stejným schvalovacím procesem jako jakýkoli jiný programový kód, a nasazení je automatizováno, což minimalizuje chyby lidského faktoru, zvyšuje spolehlivost a reprodukovatelnost.
Z praktického hlediska popisujeme GitOps následujícím způsobem:
Infrastrukturu jako kód jsme již probrali jako jeden z klíčových prvků tohoto vzorce. Představme si ostatní účastníky.
Merge Request (alternativní název pro Pull Request). V rámci procesu MR je to žádost o provedení změn v kódu a následné sloučení větví. Z pohledu nástrojů, které používáme, je to spíše příležitost k získání úplného obrazu všech provedených změn: nejen code diff, shromážděný z určitého počtu commitů, ale také kontext, výsledky testů a očekávaný konečný výsledek. Pokud mluvíme o infrastrukturním kódu, zajímá nás, jak se konkrétně změní infrastruktura, kolik nových zdrojů bude přidáno nebo odstraněno, změněno. Bylo by žádoucí v nějakém přehlednějším a snadno čitelném formátu. V případě cloudových poskytovatelů by nebylo špatné vědět, jaké finanční důsledky toto změna ponese.
Ale MR je také nástroj pro spolupráci, interakci, komunikaci. To je místo, kde vstupuje do hry systém brzd a protivah. Od jednoduchých komentářů po formální schválení a potvrzení.
A poslední složka: CI/CD, jak už víme, umožňuje automatizovat proces zavádění infrastrukturních změn, testování (od jednoduché kontroly syntaxe po složitější statickou analýzu kódu). Také při následném odhalování driftingu: rozdílů 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 či selhání systémů.
Ano, termín GitOps neseznámí nás s ničím naprosto novým, nevynalézá kolo, ale pouze aplikuje již nabyté zkušenosti v nové oblasti. Ale v tom spočívá jeho síla.
A pokud vás zajímá, jak to vše vypadá v praxi, zvu vás, abyste se podívali na náš , kde krok za krokem vysvětluji, jak pomocí GitLab:
Implementovat základní principy GitOps
Vytvářet a provádět změny v cloudové infrastruktuře (na příkladu Yandex Cloud)
Automatizovat odhalení driftingu systému od požadovaného stavu pomocí aktivního monitorování
https://bit.ly/34tRpwZ
Zdroj: habr.com
