🥇Mis on GitOps?

Märkus tõlke kohta.: Pärast hiljutist avaldust materjalist GitOpsi pull- ja push-meetodite kohta nägime huvi selle mudeli vastu üldiselt, kuid venekeelseid avaldusi sellel teemal oli äärmiselt vähe (Habrés pole neid praktiliselt üldse). Seetõttu oleme rõõmsad, et saame teile pakkuda tõlget teisest artiklist — olgu see või peaaegu aastatagune! — Weaveworksilt, kelle juht mõtles välja termini „GitOps“. Tekst selgitab lähenemise olemust ja peamisi erinevusi juba olemasolevatest.

Aasta tagasi avaldasime sissejuhatus GitOpsi. Sel ajal rääkisime, kuidas Weaveworksi meeskond käivitas täielikult Kubernetesel põhineva SaaS-i ja töötas välja hulga parimaid praktikaid juurutamiseks, haldamiseks ja monitoorimiseks cloud native keskkonnas.

Artikkel osutus populaarseks. Teised inimesed hakkasid rääkima GitOpsist, hakati avaldama uusi tööriistu git push, arendamiseks, saladuste, funktsioonide, jätkuva integreerimise jne. Meie saidile ilmus suure hulga publikatsioone ja GitOpsi kasutusjuhtumeid. Kuid mõnedel inimestel jäi endiselt küsimusi. Kuidas see mudel erineb traditsioonilisest infrastruktuuri kui koodi ja pidevast tarnimist (continuous delivery)? Kas Kubernetes on vajalik?

Varsti mõistsime, et on vaja uut määratlust, mis pakuks:

Suure hulga näiteid ja lugusid;
Konkreetsed määratlust GitOpsile;
Võrdlus traditsioonilise continuous delivery'ga.

Selles artiklis püüdsime katta kõik need teemad. Siit leiate värskendatud sissejuhatuse GitOpsi ja arendajate ning CI/CD vaatepildi sellele. Keskendume peamiselt Kubernetesile, kuigi mudelit on täiesti võimalik üldistada.

Tere tulemast: GitOps

Kujutage ette Alisat. Ta juhib ettevõtet Family Insurance, mis pakub tervise-, auto-, kinnisvara- ja reisikindlustuse poliise inimestele, kes on liiga hõivatud, et ise lepingute nüanssidega vaeva näha. Tema äri alustas kõrvalprojekti raames, kui Alisa töötas pangas andmete teadlasena. Ühel hetkel taipas ta, et saab kasutada arenenud arvuti algoritme, et andmete analüüsi ja kindlustuspakkumiste koostamise efektiivsust suurendada. Investorid rahastasid projekti ja nüüd toob tema ettevõte üle 20 miljoni dollari aastas ning kasvab kiiresti. Praegu töötab selles erinevates ametites 180 inimest. Nende seas on tehnoloogia meeskond, mis tegeleb veebisaidi, andmebaasi arendamise ja kliendibaasi analüüsiga. 60-liikmelist meeskonda juhib Bob – ettevõtte tehnoloogiadirektor.

Bobi meeskond juurutab tootmisüsteeme pilves. Nende peamised rakendused töötavad GKE-l, kasutades Google Cloudi Kubernetesest saadavaid eeliseid. Lisaks kasutavad nad oma töös erinevaid andmete ja analüütika tööriistu.

Family Insurance ei plaaninud konteinerite kasutamist, kuid nakatus Dockerist tuleneva entusiasmiga. Varsti avastas ettevõtte spetsialistid, et GKE võimaldab klastreid uute funktsioonide testimiseks lihtsasti ja mugavalt juurutada. Lisati Jenkins CI-sks ja Quay konteineriregistri korraldamiseks, kirjutati Jenkinsile skriptid, mis push’ivad uusi konteinerite ja konfiguratsioonide GKE-sse.

Möödus mõnda aega. Alice ja Bob olid pettunud valitud lähenemise jõudluses ja selle mõjus ärile. Konteinerite kasutuselevõtt ei suurendanud jõudlust nii palju, kui meeskond lootsis. Mõnikord purunesid juurutamised ja ei olnud selge, kas süüdi olid koodimuudatused. Samuti oli keeruline jälgida konfiguratsioonide muudatusi. Tihti tuli luua uus klaster ja kolida sinna rakendused, kuna see oli kõige lihtsam viis olukorra korrastamiseks, mille süsteem oli muutunud. Alice kartis, et olukord halveneb rakenduse arengu käigus (lisaks tekkis uus projekt masinõppe põhjal). Bob automatiseeris suure osa tööst ja ei saanud aru, miks torustik endiselt stabiilne ei olnud, halvasti skaleerus ja korduvaid käsitöötunde nõudis?

Siis kuulsid nad GitOpsist. See lahendus osutus just selliseks, mida nad vajasid kindlaks edasiviimiseks.

Alice ja Bob olid juba pikka aega kuulnud Git-põhistest töövoogudest, DevOpsist ja infrastruktuurist kui koodist. GitOpsi ainulaadsus seisneb selles, et see toob kaasa rida parimaid praktikaid — kategoorilisi ja regulatiivseid — nende ideede elluviimiseks Kubernetes kontekstis. See teema on korduvalt tõstatatud, sealhulgas Weaveworks'i blogis.

Family Insurance otsustab GitOpsi rakendada. Nüüd on ettevõttel automatiseeritud käitamisring mudel, mis on ühilduv Kubernetesiga ja ühendab kiirus koos stabiilsusega, kuna nad:

avastasid, et meeskonna tootlikkus on kahekordistunud ja keegi ei kaota sellega pead;
on lõpetanud skriptide haldamise. Selle asemel saavad nad nüüd keskenduda uutele funktsioonidele ja täiustada insenerimeetodeid — näiteks rakendada kanarbikuvõtteid ja parandada testimist;
on täiustanud juurutamisprotsessi — nüüd puruneb see harva;
on saanud võimaluse taastada juurutamised osaliste rikete korral ilma käsitööte sekkumiseta;
on omandanud bilotkasuurema kindluse tarnesüsteemides. Alice ja Bob avastasid, et meeskonna saab jagada rühmadesse, mis tegelevad mikroteenustega ja töötavad paralleelselt;
saavad iga rühma jõupingutuste abil projekti lisada 30-50 muudatust iga päev ja proovida uusi tehnikaid;
kergesti kaasavad projekti uusi arendajaid, kellel on võimalik teha muutusi tootmine keskkonnas pull request'ide abil juba mõne tunni jooksul;
kergesti läbivad SOC2 auditi (teenusepakkujate vastavuse kontrollimine andmete turvalise haldamise nõuetele; loe lähemalt näiteks siin — toimetaja märkus).

Mis juhtus?

GitOps — see on kaks asja:

Kubernetes'e ja pilvepõhine tegevusmudel. See pakub parimate praktikate kogumit konteinerites kokku kogutud klastrite ja rakenduste juurutamiseks, haldamiseks ja jälgimiseks. Elegantne määratlemine ühe slaidi kujul ühe slaidi alates Luis Faceira:
Teekond arendajate keskse keskkonna loomiseks rakenduste haldamiseks. Me rakendame Git töövooge nii tegevuses kui arenduses. Pange tähele, et see ei tähenda lihtsalt Git push'i, vaid kogu CI/CD ja UI/UX tööriistade kompleksi korraldamist.

Mõned sõnad Gitist

Kui te pole tuttav versioonihalduse süsteemide ja Git-põhiste töövoogudega, soovitame tungivalt neid uurida. Alguses võib harjutamine haru ja pull request'idega tunduda musta maagiana, kuid eelised on kulutatud pingutusi väärt. Siin on hea artikkel alguseks.

Kuidas Kubernetes töötab

Meie loos pöördusid Alice ja Bob GitOps'i poole, olles töötanud Kubernetes'ega mõnda aega. Tõepoolest, GitOps on tihedalt seotud Kubernetes'ega — see on tegevusmudel Kubernetes'e põhiste infrastruktuuride ja rakenduste jaoks.

Mida Kubernetes kasutajatele annab?

Siin on mõned peamised omadused:

Kubernetes'e mudelis on kõik võimalik kirjeldada deklareerivas vormis.
Kubernetes'e API-server aktsepteerib sellist deklareerimist sisendina ja seejärel üritab pidevalt tuua klastrit deklareerimisega kirja pandud olekusse.
Deklareeringud on piisavad, et kirjeldada ja hallata suurt hulka töökoormusi — "rakendusi".
Seega toimub rakenduse ja klastrite muutmine järgmiste tõttu:
- muutused konteineri piltides;
- muutused deklareerivas spetsifikatsioonis;
- keskkonna vigade tõttu — näiteks konteinerite krahh.

Kubernetes'e suurepärased konvergentsivõimed

Kui administraator teeb muudatusi konfiguratsioonis, rakendab Kubernetes'e orkestrator neid klastrisse seni kuni selle olek läheneb uuele konfiguratsioonile. See mudel töötab igasuguste Kubernetes'i ressursside jaoks ja seda saab laiendada Custom Resource Definitions (CRD) abil. Seetõttu omavad Kubernetes'i deploymid järgmisi suurepäraseid omadusi:

Automatiseerimine: Kubernetes'e uuendused pakuvad mehhanismi muudatuste rakendamise protsessi automatiseerimiseks korrektselt ja õigeaegselt.
Konvergents: Kubernetes jätkab uuenduste proovimist, kuni see õnnestub.
Idempotentsus: korduvad konvergentsi rakendused toovad sama tulemuse.
Determinism: piisava ressursside olemasolu korral sõltub uuendatud klastrite olek ainult soovitud olekust.

Kuidas GitOps töötab

Oleme piisavalt õppinud Kubernetes'est, et selgitada GitOps'i töö põhimõtteid.

Naaseme peretihedate kindlustusmeeskondade juurde, mis on seotud mikroteenustega. Mida nad tavaliselt teevad? Vaadake allolevat nimekirja (kui mõni punkt tundub kummaline või tundmatu – palun pidage meeles kriitikat ja jääge meie juurde). Need on lihtsalt Jenkins'i põhised töövood. On ka palju teisi protsesse erinevate tööriistade kasutamisel.

Peamine on see, et me näeme, et iga uuendus lõppeb muudatuste tegemisega konfiguratsioonifailides ja Git'i hoidlates. Need muudatused Git'is põhjustavad, et „GitOps operaator“ uuendab klastrit:

1. Töövoog: „Jenkins'i ehitus – master haru».
Ülesannete nimekiri:

Jenkins saadab sildiga pildid Quay'sse;
Jenkins saadab konfi ja Helm'i graafikud master-hoidla ämbrisse;
Pilvefunktsioon kopeerib konfi ja graafikud master-hoidla ämbrist Git'i hoidla masterisse;
GitOps operaator uuendab klastrit.

2. Jenkins'i ehitus – release või hotfix haru:

Jenkins saadab sildita pilte Quay'sse;
Jenkins saadab konfi ja Helm'i graafikud staging-hoidla ämbrisse;
Pilvefunktsioon kopeerib konfi ja graafikud staging-hoidla ämbrist Git'i hoidla stagingusse;
GitOps operaator uuendab klastrit.

3. Jenkins'i ehitus – develop või feature haru:

Jenkins saadab sildita pilte Quay'sse;
Jenkins saadab konfi ja Helm'i graafikud develop-hoidla ämbrisse;
Pilvefunktsioon kopeerib konfi ja graafikud develop-hoidla ämbrist Git'i hoidla developisse;
GitOps operaator uuendab klastrit.

4. Uue kliendi lisamine:

Juhendaja või administraator (LCM/ops) kutsub Gradle'i välja esialgseks juurutamiseks ja võrgu koormuse tasakaalustajate (NLB) seadistamiseks;
LCM/ops kohandab uut konfi, et valmistada juurutamine uuendusteks;
GitOps operaator uuendab klastrit.

GitOps'i lühike ülevaade

Kirjeldage soovitud süsteemi seisu, kasutades deklareerivaid spetsifikatsioone iga keskkonna jaoks (meie loos määrab Bobi meeskond kogu süsteemi konfiguratsiooni Git'is).
- Git-repositoorium on ainus tõe allikas kogu süsteemi soovitud seisu kohta.
- Kõik muudatused soovitud seisu saavutatakse Git'i commit'ide kaudu.
- Kõik soovitud klastriparameetrid on samuti jälgitavad klastris. Seega saame määrata, kas need on ühtsed (konvergents), converge) või erinevad (divergens) diverge) soovitud ja jälgitava olukorra vahel.
Kui soovitud ja jälgitav seis on erinevad, siis:
- Eksisteerib konvergentsimehhanism, mis lõpuks automaatselt sünkroniseerib siht- ja jälgitavad olekud. Klastris tegeleb sellega Kubernetes.
- Protsess algatatakse kohe koos teatega "muutus kinnitatud".
- Mõne konfigureeritava ajavahemiku pärast võib saata teate "diff", kui olekud on erinevad.
Seega kutsuvad kõik commit'id Git'is esile kontrollitavad ja idempotentsed uuendused klastris.
- Tagasiminek on konvergents varasemasse soovitud seisu.
Konvergents on lõplik. Selle toimumise tõenditeks on:
- Teatavate ajavahemike jooksul "diff" teadete puudumine.
- Teade "konvergeeritud" (näiteks webhook, Git'i kirjutamise üritus).

Mis on divergents?

Korrake veel kord: kõik soovitud klastriparameetrid peaksid olema jälgitavad klastris.

Mõned divergentsi näited:

Konfigureerimisfaili muutmine, mis tuleneb Git'i harude ühendamisest.
Konfigureerimisfaili muutmine, mis tuleneb Git'i commit'ist, tehtud GUI-klientide kaudu.
Mitmed muudatused soovitud seisus Git'i PR kaudu koos konteineripildi koostamise ja konfi muutustega.
Klastri oleku muutmine vea, ressursside konflikti tõttu, mis põhjustab "halba käitumist", või lihtsalt juhuslik kõrvalekalle algsest seisust.

Mis on konvergentsimehhanism?

Mõned näited:

Konteinerite ja klastrite jaoks pakub konvergentsimehhanismi Kubernetes.
Sama mehhanismi saab kasutada rakenduste ja Kubernetes'e alusel ehitatud struktuuride haldamiseks (näiteks Istio ja Kubeflow).
Mehhanism tööprotsesside haldamiseks Kubernetes'i, pildirepositooriumide ja Git'i vahel pakub GitOps-operator Weave Flux, mis on osa Weave Cloud.
Tavamasinate puhul peab konvergentsimehhanism olema deklareeritav ja autonoomne. Oma kogemustest võime öelda, et Terraform on sellele määratlusele kõige lähemal, kuid siiski vajab inimkontrolli. Sel mõeldes laiendab GitOps traditsioone Infrastructure as Code.

GitOps ühendab Giti suurepärase Kubernetes'i konvergentsimehhanismiga, pakkudes mudelit töösse rakendamiseks.

GitOps lubab meil väita: automatisatsioon ja kontroll on võimalik vaid nende süsteemide osas, mida saab kirjeldada ja jälgida.

GitOps on mõeldud kogu cloud native-virnale (nt Terraform jne)

GitOps ei tähenda ainult Kubernetes'i. Soovime, et kogu süsteem oleks deklareeritavalt hallatav ja kasutaks konvergentsi. Kogu süsteem hõlmab erinevaid keskkondi, mis töötavad Kubernetes'ega — näiteks "dev cluster 1", "production" jms. Iga keskkond sisaldab masinaid, klustreid, rakendusi ja ka liideseid väliste teenustega, mis tagavad andmed, jälgimise jne.

Pange tähele, kui oluline on Terraform bootstrapping-probleemi puhul. Kubernetes peab kuskil olema juurutatud ja Terraform'i kasutamine tähendab, et saame rakendada samu GitOps'i tööprotsesse Kubernetesi ja rakenduste aluskihtide loomiseks. See on kasulik parim praktika.

Suur rõhk on asetatud GitOps'i kontseptsioonide rakendamisele Kubernetes'ele järgnevatel kihtidel. Praegu on olemas GitOps-tüüpi lahendusi Istio, Helm, Ksonnet, OpenFaaS ja Kubeflow, samuti näiteks Pulumi jaoks, mis loovad arendusse kihti cloud native'i jaoks.

Kubernetes CI/CD: GitOps'i võrdlemine teiste lähenemistega

Nagu mainitud, on GitOps kaks asja:

Töömudel Kubernetes'i ja cloud native'i jaoks, nagu eelpool kirjeldatud.
Teekond arendajate keskse keskkonna loomiseks rakenduste haldamiseks.

Paljude jaoks on GitOps eeskätt tööprotsess, mis põhineb Git push'idel. Meile meeldib see samuti. Kuid see ei ole kõik: vaatame nüüd CI/CD-toru.

GitOps tagab pideva juurutamise (CD) Kubernetes'ile

GitOps pakub pideva juurutamise mehhanismi, mis kõrvaldab vajaduse eraldi 'juurutamissüsteemide' järele. Kogu töö teeb teie eest Kubernetes.

Rakenduse värskendamine nõuab värskendust Git’is. See on tehinguline värskendus soovitud olekusse. "Kasutuselevõtt" toimub seejärel klastris Kubernetes’e enda poolt värskendatud kirjelduse alusel.
Kubernetes’e töö eripära tõttu on need värskendused konvergeerivad. See tagab mehhanismi pidevaks kasutuselevõtuks, kus kõik värskendused on aatomilised.
Märkus: Weave Cloud pakub GitOps operaatorit, mis integreerib Git’i ja Kubernetes’e, võimaldades teostada CD-d soovitud ja praeguse klastriseisundi vastavusse viimise kaudu.

Ilma kubectl’i ja skripte.

Tuleb vältida Kubectl’i kasutamist klastrite värskendamiseks, eriti skripte kubectl’i käskude rühmitamiseks. Selle asemel saab kasutaja GitOps torustiku abil värskendada oma Kubernetes’e klastrit läbi Giti.

Eelised on järgmised:

Õigsus.. Uuendusgruppi saab rakendada, konvergeerida ja lõpuks valideerida, mis viib meid lähemale aatomilise kasutuselevõtu eesmärgile. Vastupidiselt sellele ei anna skriptide kasutamine mingeid konvergentsi garantiisid (põhjalikumalt allpool).
Turvalisus. Tsiteerides Kelsey Hightower: "Piirake juurdepääsu Kubernetes’e klastrile automatiseerimise tööriistadele ja administraatoritele, kelle kohustuseks on selle tõrkeotsing või töökindluse tagamine." Vaata ka minu postitust turvalisusest ja tehniliste nõuete järgimisest, samuti artiklit Homebrew’i häkkimisest kontode andmete varguse kaudu halvasti koostatud Jenkins’i skripti kaudu.
Kasutajakogemus. Kubectl paljastab Kubernetes’e objekti mudeli mehhanika, mis on üsna keeruline. Ideaalis peaksid kasutajad süsteemiga suhtlema kõrgemal abstraktsiooni tasemel. Siinkohal viitan taas Kelsey’le ja soovitan vaadata sellist kokkuvõtet.

Erinevus CI ja CD vahel.

GitOps täiustab olemasolevaid CI/CD mudeleid.

Kaasaegne CI-server on orkestreerimise tööriist. Eelkõige on see tööriist CI torustike orkestreerimiseks. Need hõlmavad endas ehitamist, testimist, trunk’iga sulandumist jne. CI-serverid automatiseerivad keeruliste mitmeastmeliste torustike haldamist. Levinud kiusatus on luua skript Kubernetes’e värskenduste kogumiseks ja käitada seda torustiku elemendina muudatuste klastrisse edastamiseks. Tõepoolest, nii käituvad paljud spetsialistid. Kuid see ei ole optimaalne ja siin on miks.

CI-d tuleb kasutada trunk'i värskendamiseks, ja Kubernetes'i klaster peaks muutma iseennast nende värskenduste põhjal, et hallata CD 'sisemiselt'. Me nimetame seda pull-mudeliks CD jaoks, erinevalt CI push-mudelist. CD on osa runtime-orchestratsioonist.

Miks CI-serverid ei peaks CD-d tegema otse värskendusi Kubernetes'i kaudu

Ärge kasutage CI-serverit otse värskenduste orkestreerimiseks Kubernetes'is CI-ülesannete komplekti kujul. See on antipatter, millest me oleme juba rääkinud oma blogis.

Lähme tagasi Alisse ja Bobi juurde.

Millistele probleemidele nad silmitsi seisavad? Bobi CI-server rakendab muudatused klastrisse, kuid kui protsessi käigus see kokku kukub, ei tea Bob, mis seisundis klaster on (või peaks olema) ja kuidas seda taastada. Sama kehtib ka juhul, kui kõik sujub.

Oletame, et Bobi meeskond koostas uue pildi ja seejärel patšeeris oma deployment'id, et juurutada pilti (kõik see CI-pipe'i kaudu).

Kui pilt koostatakse korralikult, kuid pipeline kukub kokku, peab meeskond välja selgitama:

Kas värskendus juurutati?
Kas me tõstame uusi ehitusi? Kas see toob kaasa soovimatuid kõrvaltoimeid – näiteks, et meil on kaks sama muutumatut pilti?
Kas peaksime ootama järgmise värskenduse saabumist, enne kui käivitame ehituse?
Mis täpselt läks valesti? Milliseid samme tuleb korrata (ja milliseid neist on turvaline korrata)?

Git'i põhjalise tööprotsessi korraldamine ei garanteeri, et Bobi meeskond ei seisaks silmitsi nende probleemidega. Nad võivad siiski teha vigu commit'i push'imisel, sildistamisel või mõnel muul parameetril; kuid see lähenemine on siiski palju lähemal selge kõik- või-mitte-midagi printsiibile.

Kokkuvõtteks, siin on põhjused, miks CI-serverid ei tohiks tegeleda CD-ga:

Uuenduste skriptid ei ole alati deterministlikud; neis on lihtne eksida.
CI-serverid ei konvergentsi deklaratiivse klastrimudeli suunas.
Idempotentsuse tagamine on keeruline. Kasutajad peavad süvenema süsteemi sügissemaatikasse.
Osalise ebaõnnestumise korral taastamine on keerulisem.

Märkus Helmi kohta: kui soovite kasutada Helmi, soovitame seda kombineerida GitOps-operaatoriga, nagu Flux-Helm. See aitab tagada konvergentsi. Üksik Helmi ei ole ei deterministlik ega aatomaarne.

GitOps kui parim viis Kubernetes'i jaoks pidevaks kohaletoimetamiseks

Alice'i ja Bobi meeskond rakendab GitOps'i ning avastab, et tarkvaratoodetega on nüüd palju lihtsam töötada ning tagada kõrge jõudlus ja stabiilsus. Lõpetame selle artikli joonistega, mis näitavad, milline välja näeb nende uus lähenemine. Pidage meeles, et räägime peamiselt rakendustest ja teenustest, kuid GitOps'i saab kasutada ka kogu platvormi haldamiseks.

Kubernetes'e töömudel

Vaadake järgmist diagrammi. See esindab Giti ja konteineripiltide hoidlat kui ühiseid ressursse kahe orkestreeritud elutsükli jaoks:

Pideva integreerimise toru, mis loeb ja kirjutab faile Gitis ning suudab värskendada konteineripiltide hoidlat.
Runtime'i GitOps toru, mis ühendab juurutamise, haldamise ja jälgimise. See loeb ja kirjutab faile Gitis ning suudab laadida konteineripilte.

Millised on peamised järeldused?

Probleemide jaotamine: Pange tähele, et mõlemad torud saavad andmeid vahetada ainult Giti või piltide hoidla värskendamise kaudu. Teisisõnu, CI ja runtime keskkonna vahel on tulemüür. Me nimetame seda 'muutumatuse tulemüüriks' (immutability firewall), kuna kõik hoidla värskendused loovad uusi versioone. Täiendava teabe saamiseks vaadake slaide 72–87 selles esitluses.
Võib kasutada igasuguseid CI- ja Git-serve: GitOps töötab igasuguste komponentidega. Võite jätkata oma lemmik CI- ja Git-serverite, piltide hoidlate ja testikomplektide kasutamist. Peaaegu kõik teised pideva kohaletoimetamise tööriistad turul nõuavad oma CI- / Git-serverit või piltide hoidlat. See võib osutuda takistuseks cloud native arendamiseks. GitOps'i puhul saate kasutada tuttavaid tööriistu.
Sündmused kui integreerimise tööriist: Kui andmed Gitis uuendatakse, teavitab Weave Flux (või Weave Cloud'i operaator) sellega seotud runtime'i. Iga kord, kui Kubernetes aktsepteerib muudatusi, uuendatakse Giti. See tagab lihtsa integreerimismudeli GitOps'i töövoogude korraldamiseks, nagu on näidatud allpool.

Kokkuvõte

GitOps pakub olulisi uuenduse garantiisid, mis on vajalikud igale kaasaegsele CI/CD tööriistale:

automaatika;
konvergents;
idempotentsus;
determinism.

See on oluline, kuna see pakub pilvepõhiste arendajate jaoks töökorralduse mudelit.

Traditsioonilised süsteemihalduse ja jälgimise tööriistad on seotud operatsioonitegevustega, mis toimivad runbook'i raames. (rutiinsete protseduuride ja operatsioonide kogum — tõlk.), mis on seotud konkreetse väljatootmisega.
Pilvepõhiste süsteemide haldamisel on jälgimise tööriistade kasutamine parim viis väljaande tulemuste hindamiseks, et arendajate meeskond saaks kiiresti reageerida.

Kujutage ette paljusid klustreid, mis on hajutatud erinevatesse pilvedesse, ja palju teenuseid, millel on oma meeskonnad ja väljastusplaanid. GitOps pakub ulatuslikku invarianti mudelit kogu selle külluse haldamiseks.