Väčšina z nás, ktorá si všimne ďalší nový termín v IT blogosfére alebo konferencii, si skôr či neskôr položí podobnú otázku: „Čo je to? Len ďalší módny výraz, „módne slovo“ alebo niečo, čo naozaj stojí za to venovať veľkú pozornosť, študovať a sľubovať nové obzory? To isté sa mi stalo s termínom GitOps pred nejakým časom. Vyzbrojený mnohými existujúcimi článkami, ako aj znalosťami kolegov z firmy , snažil som sa prísť na to, čo je to za šelmu a ako môže vyzerať jej využitie v praxi.
Mimochodom, o novosti termínu GitOps Aj náš nedávny prieskum hovorí: viac ako polovica opýtaných ešte nezačala pracovať s jeho princípmi.
Problém riadenia infraštruktúry teda nie je nový. Mnoho poskytovateľov cloudu je dostupných pre širokú verejnosť už dobrých tucet rokov a zdalo by sa, že mali zjednodušiť a zjednodušiť prácu tímov zodpovedných za infraštruktúru. Avšak v porovnaní s procesom vývoja aplikácií (kde automatizácia dosahuje stále nové úrovne), infraštruktúrne projekty stále často zahŕňajú veľa manuálnych úloh a vyžadujú špecializované znalosti a odborné znalosti, najmä vzhľadom na dnešné požiadavky na odolnosť voči chybám, flexibilitu, škálovateľnosť a elasticitu.
Cloudové služby tieto požiadavky veľmi úspešne splnili a boli to práve ony, kto dal významný impulz k rozvoju prístupu IaC. To je pochopiteľné. Koniec koncov, umožnili nakonfigurovať úplne virtuálne dátové centrum: neexistujú žiadne fyzické servery, stojany alebo sieťové komponenty, celá infraštruktúra sa dá popísať pomocou skriptov a konfiguračných súborov.
V čom je teda presne rozdiel? GitOps od IaC? Touto otázkou som začal svoje vyšetrovanie. Po rozhovore s kolegami som bol schopný prísť s nasledujúcim porovnaním:
GitOps
IaC
Všetok kód je uložený v úložisku git
Verzia kódu je voliteľná
Popis deklaratívneho kódu / Idempotencia
Prijateľné sú deklaratívne aj imperatívne opisy
Zmeny sa prejavia pomocou mechanizmov Merge Request / Pull Request
Dohoda, schválenie a spolupráca sú voliteľné
Proces zavádzania aktualizácie je automatizovaný
Proces zavádzania aktualizácie nie je štandardizovaný (automatické, manuálne, kopírovanie súborov, pomocou príkazového riadku atď.)
Inými slovami GitOps sa zrodilo práve aplikáciou princípov IaC. Po prvé, infraštruktúra a konfigurácie môžu byť teraz uložené rovnakým spôsobom ako aplikácie. Kód sa ľahko ukladá, ľahko sa zdieľa, porovnáva a používa sa možnosti tvorby verzií. Verzie, pobočky, história. A to všetko na mieste verejne prístupnom pre celý tím. Preto sa používanie systémov na správu verzií stalo úplne prirodzeným vývojom. Najmä git, ako najobľúbenejší.
Na druhej strane bolo možné automatizovať procesy riadenia infraštruktúry. Teraz to možno urobiť rýchlejšie, spoľahlivejšie a lacnejšie. Okrem toho boli princípy CI / CD už známe a obľúbené medzi vývojármi softvéru. Bolo potrebné len preniesť a aplikovať už známe vedomosti a zručnosti do novej oblasti. Tieto praktiky však presahovali štandardnú definíciu infraštruktúry ako kódu, teda koncept GitOps.
zvedavosť GitOps, samozrejme, aj v tom, že nejde o produkt, plugin alebo platformu spojenú s nejakým predajcom. Je to skôr paradigma a súbor princípov, podobne ako iný termín, ktorý poznáme: DevOps.
Vo firme vyvinuli sme dve definície tohto nového pojmu: teoretickú a praktickú. Začnime teoreticky:
GitOps je metodológia, ktorá preberá najlepšie princípy DevOps používané na vývoj aplikácií, ako je kontrola verzií, spolupráca, orchestrácia, CI/CD, a aplikuje ich na výzvy automatizácie správy infraštruktúry.
Všetky procesy GitOps Pracujem s využitím existujúcich nástrojov. Všetok kód infraštruktúry je uložený v známom úložisku git, zmeny prechádzajú rovnakým schvaľovacím procesom ako akýkoľvek iný softvérový kód a proces zavádzania je automatizovaný, čo minimalizuje ľudské chyby a zvyšuje spoľahlivosť a reprodukovateľnosť.
Z praktického hľadiska popisujeme GitOps takto:
Už sme diskutovali o infraštruktúre ako o kóde ako o jednej z kľúčových zložiek tohto vzorca. Predstavme ostatných účastníkov.
Požiadavka na zlúčenie (alternatívny názov Požiadavka na stiahnutie). Z hľadiska procesu je MR požiadavka na uplatnenie zmien kódu a následné zlúčenie pobočiek. Ale pokiaľ ide o nástroje, ktoré používame, je to skôr príležitosť získať úplný obraz o všetkých vykonaných zmenách: nielen rozdiel v kóde zhromaždený z určitého počtu potvrdení, ale aj kontext, výsledky testov a konečný očakávaný výsledok. Ak sa bavíme o kóde infraštruktúry, tak nás zaujíma, ako presne sa infraštruktúra zmení, koľko nových zdrojov pribudne alebo odoberie, zmení. Najlepšie v nejakom pohodlnejšom a ľahko čitateľnom formáte. Pre poskytovateľov cloudu je dobré vedieť, aký bude finančný dopad tejto zmeny.
Ale MR je tiež prostriedkom spolupráce, interakcie a komunikácie. Miesto, kde vstupuje do hry systém bŕzd a protiváh. Od jednoduchých pripomienok až po formálne schválenia a schválenia.
No a posledný komponent: CI/CD, ako už vieme, umožňuje automatizovať proces vykonávania zmien infraštruktúry a testovania (od jednoduchej kontroly syntaxe až po komplexnejšiu analýzu statického kódu). A tiež pri následnej detekcii driftu: rozdielov medzi skutočným a želaným stavom systému. Napríklad v dôsledku neoprávnených manuálnych zmien alebo zlyhania systému.
Áno, termín GitOps nám nepredstavuje nič úplne nové, neobjavuje koleso, ale jednoducho aplikuje už nazbierané skúsenosti v novej oblasti. Ale práve tu je jeho sila.
A ak vás zrazu začne zaujímať, ako to všetko vyzerá v praxi, pozývam vás pozrieť sa na naše , v ktorej vám krok za krokom poviem, ako používať GitLab:
-
Implementujte základné princípy GitOps
-
Vytvorte a vykonajte zmeny v cloudovej infraštruktúre (pomocou príkladu Yandex Cloud)
-
Automatizujte detekciu posunu systému od požadovaného stavu pomocou aktívneho monitorovania
https://bit.ly/34tRpwZ
Zdroj: hab.com