🥇Čo je to GitOps?

Pozn. prekl.: Po nedávnej publikácii materiálu o metódach pull a push v GitOps sme zaznamenali záujem o tento model ako celok, avšak v slovenčine sa objavilo veľmi málo publikácií na túto tému (na Habré ich jednoducho niet). Preto sme radi, že vám môžeme ponúknuť preklad iného článku — aj keď už takmer rok starého! — od spoločnosti Weaveworks, ktorej zakladateľ vymyslel pojem „GitOps“. V texte je vysvetlená podstata prístupu a kľúčové rozdiely od už existujúcich.

Pred rokom sme publikovali úvod do GitOps. Vtedy sme hovorili, ako tím Weaveworks spustil SaaS, ktorý je úplne založený na Kubernetes, a vyvinul súbor preskriptívnych osvedčených praktík pre nasadzovanie, správu a monitorovanie v prostredí cloud native.

Článok sa stal populárnym. O GitOps začali hovoriť iní, začali publikovať nové nástroje na git push, vývoj, tajomstvá, funkcií, nepretržitej integrácie a pod. Na našich stránkach sa objavili veľké množstvo publikácie a prípady použitia GitOps. Ale niektorí ľudia mali stále otázky. Čím sa model líši od tradičných infrastructure as code a nepretržitého dodávania (continuous delivery)? Je nutné používať Kubernetes?

Čoskoro sme pochopili, že je potrebný nový popis, ktorý ponúkne:

Veľa príkladov a príbehov;
Konkrétnu definíciu GitOps;
Porovnanie s tradičným nepretržitým dodávaním.

V tomto článku sme sa pokúsili pokryť všetky tieto témy. Nájdete v ňom aktualizovaný úvod do GitOps a pohľad na neho z pohľadu vývojárov a CI/CD. Sústredíme sa prevažne na Kubernetes, aj keď je model možné celkom zovšeobecniť.

Zoznámte sa: GitOps

Predstavte si Alisu. Riadi spoločnosť Family Insurance, ktorá ponúka poistné zmluvy na zdravotné, automobilové, nehnuteľnostné poistenie a cestovné poistenie pre ľudí, ktorí sú príliš zaneprázdnení, aby sa s detailmi zmlúv zaoberali sami. Jej podnikanie sa začínalo ako doplnkový projekt, keď Alisa pracovala v banke ako data scientist. Raz si uvedomila, že môže využiť pokročilé počítačové algoritmy na efektívnejšiu analýzu údajov a tvorbu poistných balíkov. Investori financovali projekt a teraz jej spoločnosť generuje viac ako 20 miliónov dolárov ročne a rýchlo rastie. V súčasnosti v nej pracuje 180 zamestnancov na rôznych pozíciách. Medzi nimi je aj technologický tím, ktorý sa zaoberá vývojom, údržbou webovej stránky, databázy a analýzou zákazníckych údajov. Tím s 60 členmi vedie Bob — technický riaditeľ spoločnosti.

Bobov tím nasadzuje production systémy v cloude. Ich hlavné aplikácie fungujú na GKE, pričom využívajú výhody Kubernetes v Google Cloud. Okrem toho používajú rôzne nástroje na prácu s údajmi a analýzu.

Family Insurance sa nechystala využiť kontejnery, ale nakazila sa nadšením okolo Dockera. Čoskoro špecialisti spoločnosti zistili, že GKE umožňuje nasadzovať klastre na testovanie nových funkcií jednoducho a bez námahy. Boli pridané Jenkins na CI a Quay na organizáciu registra kontajnerov, napísali sa skripty pre Jenkins, ktoré push'ovali nové kontajnery a konfigurácie do GKE.

Už uplynula nejaká doba. Alisa a Bob sa sklamali v účinnosti zvoleného prístupu a jeho vplyve na podnikanie. Implementácia kontajnerov nezvýšila výkon tak, ako tím dúfal. Niekedy nasadenia zlyhávali a nebolo jasné, či za to môžu zmeny kódu. Taktiež sa ukázalo byť ťažké sledovať zmeny v konfiguráciách. Často museli vytvoriť nový klaster a presunúť do neho aplikácie, pretože takto bolo najjednoduchšie odstrániť ten chaos, do ktorého sa systém dostal. Alisa sa bála, že situácia sa zhorší s rozvojom aplikácie (okrem toho sa blížil nový projekt založený na strojovom učení). Bob automatizoval väčšinu práce a nechápal, prečo je pipeline stále nestabilná, zle sa škáluje a občas vyžaduje ručný zásah?

Potom sa dozvedeli o GitOps. Toto riešenie sa ukázalo byť presne to, čo potrebovali na sebavedomý postup vpred.

Alisa a Bob už niekoľko rokov počuli o pracovných postupoch založených na Gite, DevOps a infraštruktúre ako kóde. Výnimočnosť GitOps spočíva v tom, že prináša množstvo osvedčených praktík — kategorizovaných a normatívnych — na implementáciu týchto ideí v kontexte Kubernetes. Toto tému neustále zdôrazňovali, vrátane blogu Weaveworks.

Rodinná poisťovňa rozhodla zaviesť GitOps. Teraz má spoločnosť automatizovaný prevádzkový model, ktorý je kompatibilný s Kubernetes a kombinujúci rýchlosť so stabilitou, pretože:

zistili, že produktivita tímu sa zdvojnásobila a nikto pritom nezošalie;
prestali spravovať skripty. Namiesto toho sa teraz môžu sústrediť na nové funkcie a zdokonaľovať inžinierske metódy — napríklad zaviesť kanárske release a zlepšiť testovanie;
vylepšili proces nasadzovania — teraz zriedka zlyháva;
získali možnosť obnovovať nasadenia po čiastočných zlyhaniach bez manuálneho zásahu;
získali väčšiu istotu v dodávkových systémoch. Alisa a Bob zistili, že tím môžu rozdeliť na skupiny, ktoré sa venujú mikroslužbám a pracujú paralelne;omôžu pridať 30-50 zmien do projektu každý deň úsilím každej skupiny a vyskúšať nové techniky;
môžu vykonať 30-50 zmien v projekte každý deň úsilím jednotlivých skupín a skúšať nové techniky;
ľahko priťahuje k projektu nových vývojárov, ktorí majú možnosť aplikovať aktualizácie na produkciu prostredníctvom pull requestov už za niekoľko hodín;
ľahko prechádzajú auditom v rámci SOC2 (na súlad poskytovateľov služieb s požiadavkami na bezpečné riadenie údajov; viac si prečítajte napríklad, tu — pozn. prekl.).

Čo sa stalo?

GitOps — to sú dve veci:

Model prevádzky pre Kubernetes a cloud native. Poskytuje súbor osvedčených praktík pre nasadenie, správu a monitorovanie klastrov a aplikácií zabalených v kontajneroch. Elegantné definovanie vo forme jedného snímku od Luis Faceira:
Cesta k vytvoreniu prostredia orientovaného na vývojárov na správu aplikácií. Používame pracovný tok Git ako pre prevádzku, tak aj pre vývoj. Upozorňujeme, že sa nejedná len o Git push, ale o organizáciu celého súboru nástrojov CI/CD a UI/UX.

Pár slov o Gite

Ak nie ste oboznámení so systémami riadenia verzií a pracovným tokom založeným na Gite, dôrazne odporúčame ich naštudovať. Na začiatku sa môže práca s vetvami a pull requestami zdať čiernou mágiou, ale výhody stoja za vložené úsilie. Tu je dobrý článok na začiatok.

Ako funguje Kubernetes

V našom príbehu Ališ a Bob sa obrátili na GitOps po niekoľkých mesiacoch práce s Kubernetes. Naozaj, GitOps úzko súvisí s Kubernetes — je to model prevádzky pre infraštruktúru a aplikácie založené na Kubernetes.

Čo Kubernetes ponúka používateľom?

Tu sú niektoré základné možnosti:

V modeli Kubernetes je možné všetko popísať v deklaratívnej forme.
API server Kubernetes prijíma túto deklaráciu ako vstupné údaje a neustále sa snaží priviesť klaster do stavu, ktorý je popísaný v deklarácii.
Deklarácie sú dostatočné na to, aby popísali a spravovali široké spektrum pracovných zaťažení — 'aplikácií'.
V dôsledku toho, zmeny v aplikácii a klastri nastávajú z dôvodu:
- zmien vo vzoroch kontajnerov;
- zmien v deklaratívnej špecifikácii;
- chýb v prostredí — napríklad, pád kontajnerov.

Úžasné schopnosti Kubernetes v oblasti konvergencie

Keď administrátor vykoná zmeny v konfigurácii, orchestrátor Kubernetes ich bude aplikovať na klaster, kým jeho stav sa nepriblíži k novej konfigurácii. Tento model funguje pre akýkoľvek Kubernetes zdroj a rozširuje sa pomocou Custom Resource Definitions (CRD). Preto majú Kubernetes deploymenty nasledujúce úžasné vlastnosti:

Automatizácia: aktualizácie Kubernetes poskytujú mechanizmus na automatizáciu procesu aplikovania zmien správne a včas.
Konvergencia: Kubernetes sa bude neustále snažiť o aktualizácie, až kým nedosiahne úspech.
Idempotencia: opakované aplikácie konvergencie vedú k rovnakému výsledku.
Determinizmus: pri dostatočnosti zdrojov závisí stav aktualizovaného klastra len od požadovaného stavu.

Ako funguje GitOps

Doteraz sme sa dozvedeli dosť o Kubernetes, aby sme mohli vysvetliť zásady fungovania GitOps.

Vráťme sa k tímom Family Insurance, ktoré súvisia s mikroslužbami. Čím sa obvykle zaoberajú? Pozrite si zoznam nižšie (ak sa vám v ňom niečo zdá divné alebo neznáme — prosím, počkajte s kritikou a zostaňte s nami). Toto sú iba príklady pracovných procesov založených na Jenkinse. Existuje aj množstvo ďalších procesov pri práci s inými nástrojmi.

Hlavné je, že vidíme, že každá aktualizácia končí zmenou v konfiguračných súboroch a repozitároch Git. Tieto zmeny v Gite vedú k tomu, že „GitOps operátor“ aktualizuje klaster:

1. Pracovný proces: „Jenkins build — vetva master».
Zoznam úloh:

Jenkins posiela tagované obrazy do Quay;
Jenkins posiela konfiguráciu a Helm grafy do bucketu master úložiska;
Cloudová funkcia kopíruje konfiguráciu a grafy z bucketu master úložiska do Git repozitára master;
GitOps operátor aktualizuje klaster.

2. Jenkins build — vetva release alebo hotfix:

Jenkins posiela netagované obrazy do Quay;
Jenkins posiela konfiguráciu a Helm grafy do bucketu staging úložiska;
Cloudová funkcia kopíruje konfiguráciu a grafy z bucketu staging úložiska do Git repozitára staging;
GitOps operátor aktualizuje klaster.

3. Jenkins build — vetva develop alebo feature:

Jenkins posiela netagované obrazy do Quay;
Jenkins posiela konfiguráciu a Helm grafy do bucketu develop úložiska;
Cloudová funkcia kopíruje konfiguráciu a grafy z bucketu develop úložiska do Git repozitára develop;
GitOps operátor aktualizuje klaster.

4. Pridanie nového klienta:

Manažér alebo administrátor (LCM/ops) spúšťa Gradle na prvotné nasadenie a konfiguráciu sieťových vyvažovačov zaťaženia (NLB);
LCM/ops posiela nový konfig na prípravu deploymentu na aktualizácie;
GitOps operátor aktualizuje klaster.

Krátky popis GitOps

Popíšte požadovaný stav celej sústavy, pomocou deklaratívnych špecifikácií pre každé prostredie (v našom príbehu tím Boba definuje celú konfiguráciu systému v Gite).
- Git repozitár je jediným zdrojom pravdy o požadovanom stave celej sústavy.
- Všetky zmeny v požadovanom stave sa realizujú prostredníctvom commitov v Gite.
- Všetky požadované parametre klastra sú tiež viditeľné v samotnom klastri. Takto môžeme určiť, či sa požadovaný a pozorovaný stav zhodujú (konvergujú, converge) alebo sa líšia (divergujú, diverge) od požadovaného a pozorovaného stavu.
Ak sa požadovaný a pozorovaný stav líšia,
- existuje mechanizmus konvergencie, ktorý skôr či neskôr automaticky synchronizuje cieľový a pozorovaný stav. V rámci klastra sa o to stará Kubernetes.
- Proces sa spustí okamžite s upozornením „change committed“.
- Po určitom nastaviteľnom časovom intervale môže byť zaslané upozornenie „diff“, ak sa stavy líšia.
Takže všetky commity v Gite spôsobujú kontrolovateľné a idempotentné aktualizácie v klastri.
- Rollback je konvergencia k predchádzajúcemu požadovanému stavu.
Konvergencia je konečná. O jej nastúpení svedčia:
- Absencia upozornení „diff“ po určitom časovom období.
- Upozornenie „converged“ (napríklad webhook, udalosť Git writeback).

Čo je to divergencia?

Opakujme ešte raz: všetky požadované vlastnosti klastra musia byť viditeľné v samotnom klastri..

Niekoľko príkladov divergencie:

Zmena v konfiguračnom súbore v dôsledku zlúčenia vetiev v Gite.
Zmena v konfiguračnom súbore v dôsledku commitu v Gite, ktorý vykonal GUI klient.
Viaceré zmeny v požadovanom stave v dôsledku PR v Gite s následnou kompiláciou obrazu kontajnera a zmenami v konfigurácii.
Zmena stavu klastra v dôsledku chyby, konfliktu zdrojov, vedúceho k „zlému správaniu“, alebo jednoducho náhodnému odklonu od pôvodného stavu.

Čo zahŕňa mechanizmus konvergencie?

Niekoľko príkladov:

Pre kontajnery a klastry mechanizmus konvergencie poskytuje Kubernetes.
Ten istý mechanizmus sa dá použiť na správu aplikácií a konštrukcií založených na Kubernetes (napríklad Istio a Kubeflow).
Mechanizmus na riadenie pracovnej interakcie medzi Kubernetes, repozitármi obrazov a Gitom poskytuje GitOps operátor Weave Flux, ktorý je súčasťou Weave Cloud.
Pre základné stroje musí byť mechanizmus konvergencie deklaratívny a autonómny. Na základe našich skúseností môžeme povedať, že Terraform je najbližšie k tomuto definovaniu, avšak stále vyžaduje kontrolu zo strany človeka. V tomto zmysle GitOps rozširuje tradície Infrastructure as Code.

GitOps spája Git s vynikajúcim mechanizmom konvergencie Kubernetes a ponúka model pre prevádzku.

GitOps nám umožňuje povedať: automatisácií a kontrole podliehajú iba tie systémy, ktoré je možné opisovať a monitorovať.

GitOps je určený pre celý cloud native stack (napríklad Terraform a podobne)

GitOps nie je len Kubernetes. Chceme, aby celý systém bol spravovaný deklaratívne a používal konvergenciu. Pod celým systémom rozumieme súbor prostredí pracujúcich s Kubernetes - napríklad „dev cluster 1“, „production“ a pod. Každé prostredie zahŕňa stroje, klastry, aplikácie a tiež rozhrania pre vonkajšie služby, ktoré zabezpečujú dáta, monitorovanie a podobne.

Všimnite si, ako je v tomto prípade Terraform dôležitý pre otázku bootstrappingu. Kubernetes musí byť niekde nasadený a použitie Terraform znamená, že môžeme uplatniť tie isté pracovné postupy GitOps na vytvorenie správcovskej vrstvy, ktorá je základom Kubernetes a aplikácií. Je to užitočná najlepšia prax.

Veľká pozornosť sa venuje aplikácii konceptov GitOps na vrstvy nad Kubernetes. V súčasnosti existujú GitOps riešenia pre Istio, Helm, Ksonnet, OpenFaaS a Kubeflow, ako aj pre Pulumi, ktoré vytvárajú vrstvu pre vývoj aplikácií pod cloud native.

Kubernetes CI/CD: porovnanie GitOps s inými prístupmi

Ako sme už spomínali, GitOps sú dve veci:

Model prevádzky pre Kubernetes a cloud native, ktorý je popísaný vyššie.
Cesta k organizácii zameranej na vývojárov pre správu aplikácií.

Pre mnohých je GitOps predovšetkým pracovný proces založený na Git pushoch. Nám sa to tiež páči. Ale to nie je všetko: poďme sa teraz pozrieť na CI/CD pipeline.

GitOps zabezpečuje kontinuálne nasadzovanie (CD) pod Kubernetes

GitOps ponúka mechanizmus kontinuálneho nasadzovania, ktorý odstraňuje potrebu samostatných "systémov správy nasadzovania". Celú prácu za vás vykonáva Kubernetes.

Aktualizácia aplikácie si vyžaduje aktualizáciu v Gite. Ide o transakčnú aktualizáciu na požadovaný stav. „Nasadenie“ sa následne vykonáva v rámci klasteru samotným Kubernetes na základe aktualizovaného popisu.
Z dôvodu špecifík fungovania Kubernetes sú tieto aktualizácie konvergentné. Zabezpečuje sa tak mechanizmus pre kontinuálne nasadenie, v ktorom sú všetky aktualizácie atomárne.
Poznámka: Weave Cloud ponúka GitOps-operator, ktorý integruje Git a Kubernetes a umožňuje realizovať CD pomocou zladenia požadovaného a aktuálneho stavu klasteru.

Bez kubectl a skriptov

Je potrebné sa vyhnúť používaniu Kubectl na aktualizáciu klasteru, a najmä skriptom na zoskupovanie príkazov kubectl. Namiesto toho môže používateľ aktualizovať svoj klaster Kubernetes prostredníctvom GitOps-pipeline.

Výhody zahŕňajú:

Správnosť. Môžeme aplikovať skupinu aktualizácií, konvergovať ich a nakoniec validovať, čo nás približuje k cieľu atomárneho nasadenia. Naopak, použitie skriptov neposkytuje žiadne záruky konvergencie (viac o tom nižšie).
Bezpečnosť. Citujúc Kelsey Hightower: „Obmedzte prístup ku klasteru Kubernetes automatizačným nástrojom a administrátorom, ktorých úlohou je jeho ladenie alebo udržiavanie prevádzky“. Pozri tiež moju publikáciu o bezpečnosti a dodržiavaní technických podmienok, ako aj článok o hackovaní Homebrew prostredníctvom krádeže prihlasovacích údajov z neprimerane zostaveného Jenkins-skriptu.
Používateľská skúsenosť. Kubectl odhaľuje mechaniku objektového modelu Kubernetes, ktorý je veľmi zložitý. Ideálne by bolo, aby používatelia interagovali so systémom na vyššej úrovni abstrakcie. Tu sa opäť odvolávam na Kelseyho a odporúčam pozrieť takéto zhrnutie.

Rozdiel medzi CI a CD

GitOps zlepšuje existujúce CI/CD modely.

Súčasný CI-server predstavuje nástroj na orchestráciu. Konkrétne je to nástroj na orchestráciu CI-pipelines. Tieto obsahujú build, test, merge do trunku a pod. CI-servery automatizujú správu zložitých viacstupňových pipelines. Bežná nástraha spočíva v tom, aby sa vytvoril skript pre súbor aktualizácií Kubernetes a vykonal sa ako súčasť pipeline na push zmien do klasteru. Skutočne, takto to robí mnoho odborníkov. Avšak to nie je optimálne a tu je dôvod.

CI by mala byť použitá na aktualizácie trunku a Kubernetes klaster by sa mal na základe týchto aktualizácií samočinne menil na riadenie CD "interné". Nazývame to modelom pull pre CD, na rozdiel od modelu push CI. CD je súčasťou runtime-orchestrácie.

Prečo by CI servery nemali vykonávať CD prostredníctvom priameho aktualizovania v Kubernetes

Nepoužívajte CI server na orchestráciu priamych aktualizácií v Kubernetes vo forme CI úloh. To je anti-pattern, o ktorom sme už písali na našom blogu.

Vráťme sa k Alice a Bobovi.

S akými problémami sa stretli? CI server Boba aplikuje zmeny na klaster, ale ak by počas toho zlyhal, Bob nebude vedieť, v akom stave sa klaster nachádza (alebo by mal byť) a ako ho opraviť. To isté platí aj v prípade úspechu.

Predpokladajme, že tím Boba zostavil nový obraz a potom upravil svoje deploymenty, aby nasadil obraz (všetko z CI pipeline).

Ak sa obraz správne zostaví, ale pipeline zlyhá, tím bude musieť zistiť:

Bolo nasadené aktualizovanie?
Spúšťame novú zostavu? Privedie to k zbytočným vedľajším účinkom – so možnosťou mať dve zostavy toho istého nemenného obrazu?
Máme počkať na ďalšiu aktualizáciu predtým, ako spustíme zostavu?
Čo presne sa pokazilo? Aké kroky treba zopakovať (a ktoré z nich je bezpečné opakovať)?

Organizácia pracovného postupu založeného na Gite nezaručuje, že tím Boba sa nespotká s týmito problémami. Môžu sa stále pomýliť s pushovaním commitu, s tagom alebo akýmkoľvek iným parametrom; avšak tento prístup je stále oveľa bližšie k explicitnému all-or-nothing.

Zhrnutie, prečo by CI servery nemali riešiť CD:

Aktualizačné skripty nie sú vždy deterministické; ľahko sa v nich robia chyby.
CI servery neprechádzajú k deklaratívnemu modelu klastru.
Je ťažké zabezpečiť idempotentnosť. Používatelia musia rozumieť hlbokej semantike systému.
Obnovenie po čiastočnom zlyhaní je ťažšie.

Poznámka o Helme: ak chcete použiť Helm, odporúčame ho spojiť s GitOps operátorom, ako je Flux-Helm. To pomôže zabezpečiť konvergenciu. Samotný Helm nie je ani deterministický, ani atomárny.

GitOps ako najlepší spôsob, ako realizovať nepretržité dodávanie pre Kubernetes

Tím Alice a Bob implementuje GitOps a zistí, že je omnoho jednoduchšie pracovať so softvérovými produktmi, udržiavať vysoký výkon a stabilitu. Poďme skončiť tento článok ilustráciami, ktoré ukazujú, ako vyzerá ich nový prístup. Berte na vedomie, že hovoríme predovšetkým o aplikáciách a službách, ale GitOps môže byť použitý na spravovanie celej platformy.

Model operácie pre Kubernetes

Pozrite sa na nasledujúci diagram. Predstavuje Git a úložisko obrazov kontajnerov ako spoločné zdroje pre dva orchestrálne životné cykly:

Pipeliny nepretržitéj integrácie, ktoré čítajú a zapisujú súbory do Gitu a môžu aktualizovať repozitár kontajnerových obrazov.
Pipeliny Runtime GitOps, ktoré kombinujú nasadenie s riadením a monitorovaním. Čítajú a zapisujú súbory do Gitu a môžu nahrávať obrazy kontajnerov.

Aké sú hlavné zistenia?

Rozdelenie problémov: Všimnite si, že oba pipeliny môžu vymieňať údaje len aktualizovaním Gitu alebo repozitára obrazov. Inými slovami, medzi CI a runtime prostredím je firewall. Nazývame ho "firewallom nemennosti" (immutability firewall), pretože všetky aktualizácie repozitárov vytvárajú nové verzie. Pre ďalšie informácie k tejto téme sa obrátte na snímky 72-87 tejto prezentácie.
Môžete použiť akýkoľvek CI- a Git-server: GitOps funguje s akýmikoľvek komponentmi. Môžete naďalej používať svoje obľúbené CI- a Git-servery, repozitáre obrazov a testovacie sady. Takmer všetky ostatné nástroje na nepretržité dodávanie na trhu vyžadujú vlastný CI/Git-server alebo úložisko obrazov. To môže byť obmedzujúcim faktorom pri vývoji cloud native. V prípade GitOps môžete používať výhodné nástroje.
Udalosti ako nástroj integrácie: Keď sú údaje v Gite aktualizované, Weave Flux (alebo operátor Weave Cloud) o tom informuje runtime. Kedykoľvek Kubernetes prijme súbor zmien, Git sa aktualizuje. To poskytuje jednoduchý model integrácie pre organizáciu pracovných tokov pre GitOps, ako je znázornené nižšie.

Záver

GitOps poskytuje silné záruky aktualizácie, potrebné pre každý moderný nástroj CI/CD:

automatizácia;
konvergencia;
idempotentnosť;
deterministickosť.

Je dôležité, pretože ponúka model prevádzky pre vývojárov v oblasti cloud native.

Tradičné nástroje na správu a monitorovanie systémov sú spojené s prevádzkovými tímami, ktoré pracujú v rámci runbooku. (súbor rutinných postupov a operácií — pozn. prekl.), viazaného na konkrétnu distribúciu.
V správe cloud native systémov je nástroj na sledovanie najlepším spôsobom, ako posúdiť výsledky nasadení, aby sa vývojový tím mohol na ne rýchlo reagovať.

Predstavte si množstvo klastrov roztrúsených po rôznych cloudoch a množstvo služieb so svojimi vlastnými tímami a plánmi nasadení. GitOps ponúka škálovateľný a invariabilný model na správu tohto bohatstva.

P.S. od prekladateľa

Prečítajte si tiež na našom blogu:

Len registrovaní používatelia sa môžu zúčastniť prieskumu. Prihláste sa, prosím.

Vedeli ste o GitOps pred týmito dvomi prekladmi na habre?

Áno, všetko som vedel(a)
Iba povrchné znalosti
Nie

Hlasovalo 35 používateľov. Zdržalo sa 10 používateľov.

Zdroj: habr.com