Väčšina z nás, keď si všimne ďalší nový pojem v IT blogosfére alebo na konferencii, sa skôr či neskôr začíta do podobnej otázky: „Čo to je? Nové módne slovo, 'buzzword', alebo naozaj niečo, čo stojí za pozornosť, štúdium a sľubuje nové horizonty?“ Takto to prišlo aj mne s pojmom GitOps pred nejakým časom. Ozbrojený množstvom už existujúcich článkov, ako aj vedomosťami kolegov z firmy , som sa pokúsil rozlúštiť, čo to vlastne je, a ako môže jeho aplikácia vyzerať v praxi.
Mimochodom, o novosti tohto pojmu GitOps svedčí aj nedávny prieskum, ktorý sme uskutočnili: viac ako polovica respondentov ešte nezačala pracovať s jeho princípmi.
Takže problém s riadením infraštruktúry nie je nový. Množstvo poskytovateľov cloudových služieb je už viac ako desať rokov k dispozícii širokej verejnosti a zdalo by sa, že by mali zjednodušiť prácu tímov zodpovedných za infraštruktúru. Avšak pri porovnaní s procesom vývoja aplikácií (kde úroveň automatizácie dosahuje stále nové a nové horizonty) sú infraštruktúrne projekty stále častokrát spojené s mnohými úlohami vykonávanými ručne a vyžadujú si špeciálne zručnosti a odborníkov, najmä vzhľadom na súčasné požiadavky na odolnosť, flexibilitu, škálovateľnosť a elasticitu.
Cloudové služby úspešne splnili tieto požiadavky a práve oni dali významný impulz rozvoju prístupu IaC. A to je pochopiteľné. Veď oni umožnili plne konfigurovať virtuálne centrum správy údajov: žiadne fyzické servery, policové jednotky, sieťové komponenty, celú infraštruktúru je možné opísať pomocou skriptov a konfiguračných súborov.
Tak v čom spočíva rozdiel GitOps od IaC? Именно с этого вопроса я и начал свое расследование. Пообщавшись с коллегами, у меня получилось выработать следующее сравнение:
GitOps
IaC
Celý kód je uložený v git repo
Verzovanie kódu nie je povinné
Deklaratívny popis kódu / Idempotencia
Povolené sú ako deklaratívne, tak aj imperatívne popisy
Zmeny nadobúdajú účinnosť pomocou mechanizmov Merge Request / Pull Request
Súhlas, schvaľovanie a spolupráca nie sú povinné
Proces nasadzovania aktualizácií je automatizovaný
Proces nasadzovania aktualizácií nie je normovaný (automatický, manuálny, kopírovanie súborov, pomocou príkazového riadka atď.)
Inými slovami GitOps sa objavil práve vďaka aplikácii princípov IaC. Po prvé, infraštruktúru a konfigurácie bolo možné uchovávať rovnakým spôsobom ako aplikácie. Kód sa ľahko uchováva, zdieľa, porovnáva a využíva možnosti verziovania. Verzie, vetvy, história. A to všetko na verejnom mieste prístupnom pre celý tím. Preto sa používanie systémov správy verzií stalo logickým vývojom. Predovšetkým git, ako najpopulárnejší.
Na druhej strane sa objavila možnosť automatizovať procesy správy infraštruktúry. Teraz to možno urobiť rýchlejšie, spoľahlivejšie a lacnejšie. Najmä princípy CI / CD už boli známe a populárne medzi vývojármi softvéru. Bolo potrebné len preniesť a aplikovať už známe znalosti a zručnosti na novú oblasť. Tieto praktiky však presahovali rámec štandardného definovania Infraštruktúry ako kódu, odkiaľ sa zrodil pojem. GitOps.
Zvedavosť GitOps, samozrejme, spočíva aj v tom, že nejde o produkt, plugin alebo platformu spojenú s akýmikoľvek dodávateľmi. Ide skôr o paradigmu a súbor princípov, podobne ako iný známý nám termín: DevOps.
Vo firme sme vypracovali dve definície tohto nového termínu: teoretickú a praktickú. Začnime teoretickou:
GitOps je metodológia, ktorá využíva pokročilé princípy DevOps používané pri vývoji aplikácií, ako sú správa verzií, interakcia, schvaľovanie, CI / CD, a aplikuje ich na riešenie úloh automatizácie správy infraštruktúry.
Všetky procesy GitOps pracujem s použitím už existujúcich nástrojov. Všetok infraštruktúrny kód je uložený v už známej git repo, zmeny prechádzajú rovnakým procesom schválenia ako akýkoľvek iný programový kód a proces nasadenia je automatizovaný, čo umožňuje minimalizovať chyby ľudského faktora, zvýšiť spoľahlivosť a reprodukovateľnosť.
Z praktického hľadiska popisujeme GitOps nasledovne:
Infraštruktúru ako kód sme už prediskutovali ako jednu z kľúčových súčastí tejto formule. Predstavme si ostatných účastníkov.
Merge Request (alternatívny názov Pull Request). Z hľadiska procesu je MR žiadosť o aplikáciu zmien kódu a následné zlúčenie vetiev. Z hľadiska nástrojov, ktoré používame, je to skôr možnosť získať celkový prehľad všetkých vykonaných zmien: nielen code diff zostavený z množstva commitov, ale aj kontext, výsledky testov a očakávaný konečný výsledok. Ak sa rozprávame o infraštruktúrnom kóde, zaujíma nás, ako sa presne zmení infraštruktúra, koľko nových zdrojov bude pridaných alebo odstránených, zmenených. Ideálne v nejakom pohodlnejšom a ľahko čitateľnom formáte. V prípade cloudových poskytovateľov by nebolo zlé vedieť, aké finančné dôsledky prinesie táto zmena.
Ale MR je tiež prostriedkom spolupráce, interakcie, komunikácie. To miesto, kde nastupuje systém kontrol a protiváh. Od jednoduchých komentárov po formálne schválenia a potvrdenia.
A posledná zložka: CI/CD, ako už vieme, umožňuje automatizovať proces zavádzania infraštruktúrnych zmien, testovania (od jednoduchého kontrolovania syntaxe po zložitejšiu statickú analýzu kódu). A tiež následne odhaľovanie driftu: rozdiely medzi skutočným a požadovaným stavom systému. Napríklad v dôsledku nezákonných manuálnych zmien alebo zlyhania systémov.
Áno, tento termín GitOps nás nijako nezoznámi s ničím úplne novým, nevynaliezajú koleso, ale len aplikuje už nazbierané skúsenosti v novej oblasti. Ale v tom spočíva jeho sila.
A ak sa vám náhodou stane zaujímavé, ako to všetko vyzerá v praxi, pozývam vás pozrieť si náš , v ktorom krok za krokom ukazujem, ako pomocou GitLab:
Implementovať základné princípy GitOps
Vytvárať a zavádzať zmeny do cloudovej infraštruktúry (na príklade Yandex Cloud)
Automatizovať odhaľovanie driftu systému od požadovaného stavu pomocou aktívneho monitorovania
https://bit.ly/34tRpwZ
Zdroj: habr.com
