Mis on GitOps?

Märk. tõlge.: Pärast hiljutist avaldust materjali GitOpsi pull ja push meetodite kohta oleme näinud huvi selle mudeli vastu, kuid venekeelseid publitseeringuid sellel teemal on väga vähe (Habrast ei leia neid üldse). Seetõttu oleme rõõmsad, et saame teile pakkuda teise artikli tõlget — ehkki see on juba peaaegu aasta vana! — ettevõttelt Weaveworks, kelle juht leiutas termini „GitOps”. Artiklis selgitatakse lähenemise olemust ja peamisi erinevusi juba olemasolevatest lahendustest.

Aasta tagasi avaldasime sissejuhatuse GitOpsi. Siis rääkisime, kuidas Weaveworksi meeskond käivitas SaaS-i, mis põhineb täielikult Kubernetesel, ning töötas välja parimate praktikate komplekti, et juurutada, hallata ja jälgida pilvepõhises keskkonnas.

Artikkel osutus populaarseks. Teised inimesed hakkasid rääkima GitOpsist, ja avaldama uusi tööriistu git push, arendamiseks, saladused, funktsiooni, katkematule integreerimisele jne. Meie veebisaidile ilmus suure hulga publikatsioone ja kasutusjuhtumeid GitOpsi kohta. Kuid mõnede inimeste jaoks on siiski jäänud küsimusi. Kuidas mudel erineb traditsioonilisest infrastructure as code ja pidevast tarnimisest (continuous delivery)? Kas Kubernetes on hädavajalik?

Varsti mõistsime, et on vajalik uus kirjeldus, mis pakub:

1. Suurt hulka näiteid ja lugusid;
2. Konkreetsed määratlus GitOps'i kohta;
3. Võrdlus traditsioonilise pideva tarnimisega.

Selles artiklis püüdsime kattuda nende kõigi teemadega. Leiate uuendatud ülevaate GitOps'ist ja arendajate ning CI/CD vaatenurga. Me keskendume peamiselt Kubernetes'ele, kuigi mudelit on võimalik üldistada.

Tutvuge: GitOps

Kujutage ette Alice'i. Ta juhib Family Insurance'i, mis pakub tervise-, auto-, kinnisvara- ja reisikindlustuspolisse inimestele, kes on liiga hõivatud, et ise lepingute nüanssidega tegeleda. Tema äri algas kõrvalprojektina, kui Alice töötas pangas andmete teadlasena. Ühel päeval taipas ta, et saab kasutada tipptasemel arvutialgoritme andmete tõhusamaks analüüsimiseks ja kindlustuspakkumiste koostamiseks. Investorid finantseerisid projekti, ja nüüd teenib tema ettevõte üle 20 miljoni dollari aastas ning kasvab kiiresti. Hetkel töötab seal erinevatel ametikohtadel 180 inimest. Nende seas on tehniline meeskond, mis tegeleb veebisaidi, andmebaasi arendamise ja kliendibaasi analüüsiga. 60 inimese meeskonda juhib Bob, ettevõtte tehnoloogia direktor.

Bob'i meeskond käitab produzirimissüsteeme pilves. Nende peamised rakendused töötavad GKE-l, kasutades Kubernetes'i eeliseid Google Cloudis. Lisaks kasutavad nad erinevaid tööriistu andmete töötlemiseks ja analüüsiks.

Family Insurance ei plaaninud konteinerite kasutamist, kuid nakatus Dockerist entusiasmiga. Varsti avastas ettevõtte spetsialistid, et GKE võimaldab kergesti ja muretult juurutada klasse uute funktsioonide testimiseks. Lisati Jenkins CI jaoks ja Quay konteineriregistri haldamiseks, kirjutati Jenkinsile skripte, mis edastasid uusi konteinerite ja konfiguratsioonide GKE.

Möödus veidi aega. Alice ja Bob olid valitud lähenemise tootlikkuse ja selle mõju äbusinessist pettunud. Mahutite kasutuselevõtt ei parandanud tootlikkust nii palju, kui meeskond oli lootnud. Mõnikord läksid juurutamised katki, ja ei olnud selge, kas probleemid olid seotud koodimuudatustega. Samuti oli keeruline jälgida konfiguratsioonimuudatusi. Tihti tuli luua uus klaster ja tõsta sinna rakendused, kuna see oli ainus lihtne viis, et likvideerida segadus, milleks süsteem oli muutunud. Alice kartis, et olukord halveneb rakenduse arenedes (lisaks oli tekkimas uus masinõppe projekt). Bob oli suure osa tööst automatiseerinud ja ei mõistnud, miks torustik endiselt ebastabiilne on, halvasti skaleerub ja nõuab perioodiliselt käsitsi sekkumist?

Siis said nad teada GitOps'ist. See lahendus osutus just selleks, mida nad vajusid kindlalt edasi liikumiseks.

Aliisa ja Bob on juba aastaid kuulnud Git, DevOps ja infrastructure as code tööprotsessidest. GitOps'i eripära on see, et see toob kaasa rida parimaid praktikaid — kategoorilisi ja regulatiivseid — nende ideede elluviimiseks Kubernetes'i kontekstis. See teema on korduvalt tõstatunud, sealhulgas Weaveworks'i blogis..

Family Insurance otsustab rakendada GitOps'i. Nüüd on ettevõttel automatiseeritud töömudel, mis on kokku sobiv Kubernetes'iga ja ühendab kiiruse ja stabiilsuse, kuna nad:

• avastasid, et meeskonna tootlikkus on kahekordistunud ning keegi ei lähe seetõttu hulluks;
• on lõpetanud skriptide hooldamise. Selle asemel saavad nad nüüd keskenduda uutele funktsioonidele ja täiustada insenerimeetodeid — näiteks rakendada kanarullide väljaandeid ja parandada testimist;
• on täiustanud juurutamisprotsessi — see katkeb nüüd harva;
• on saanud võimaluse taastada juurutamisi osaliste tõrgete korral ilma käsitsi sekkumiseta;
• on saavutanud suurema kindluse tarnesüsteemides. Aliisa ja Bob avastasid, et meeskonna saab jagada rühmadesse, mis tegelevad mikroteenustega ja töötavad paralleelselt;osuuremat kindlustunnet tarnesüsteemides. Alice ja Bob avastasid, et meeskonna saab jagada gruppideks, kes tegelevad mikroteenustega ja töötavad paralleelselt;
• iga päev iga meeskonna jõududega saavad teha 30-50 muudatust projektis ja katsetada uusi tehnikaid;
• kergesti kaasavad projekti uusi arendajaid, kellel on võimalus lisada tootmisversioonile uuendusi pull request'ide kaudu juba paar tunni pärast;
• läbivad SOC2 raames auditi lihtsasti (teenusepakkujate vastavuse tagamine andmete turvalise haldamise nõuetele; lisainfot leiate näiteks siit — kt. tõlge).

Mis juhtus?

GitOps — see on kaks asja:

1. Kubernetes'e ja pilvetehnoloogia töömudel. See pakub parimate praktikate kogumit konteinerisse pakitud klastrite ja rakenduste juurutamiseks, haldamiseks ja jälgimiseks. Elegantne määratlemine ühel slaidil. üks slaid alates Luis Faceira:
2. Tee arendajakeskse keskkonna loomiseni rakenduste haldamiseks. Kasutame Git'i töövoogu nii tootmises kui ka arenduses. Pange tähele, et see ei puuduta ainult Git push'i, vaid kogu CI/CD ja UI/UX tööriistade komplekti organiseerimist.

Mõned sõnad Git-ist

Kui te pole tuttav versioonihaldussüsteemide ja Git-põhise töövooga, soovitame tungivalt neid uurida. Harjumatu on alguses töötada harude ja pull request'idega, kuid saadud kasu on vaeva väärt. Siin on hea artikkel alustamiseks.

Kuidas Kubernetes töötab

Meie loos pöördusid Alice ja Bob GitOps'i poole, pärast pikka töötamist Kubernetesega. Tõepoolest, GitOps on tihedalt seotud Kubernetesega — see on Kubernetesel põhinevate infrastruktuuri ja rakenduste haldamise mudel.

Mida Kubernetes kasutajatele pakub?

Siin on mõned põhifunktsioonid:

1. Kubernetes mudelis saab kõike kirjeldada deklaratiivsel viisil.
2. Kubernetes API-server võtab sellise deklaratsiooni sisendina ja püüab pidevalt tuua klastrit seisundisse, mis on kirjeldatud deklaratsioonis.
3. Deklaratsioonid on piisavad, et kirjeldada ja hallata laia valikut töökoormusi — 'rakendusi'.
4. Tulemusena toimub rakenduste ja klastrite muutmine järgmiste tõttu:
   • muutused konteineripiltides;
   • muutused deklaratiivses spetsifikatsioonis;
   • vead keskkonnas — näiteks konteinerite kokku kukkumised.

Kubernetes'e iseloomulikud suurepärased konvergentsi võimed

Kui haldur muudab seadistusi, rakendab Kubernetes'i orkestreerija neid klastrisse, kuni selle seisund läheneb uuele seadistusele. See mudel töötab igasuguste Kubernetes'i ressursside jaoks ja seda saab laiendada Custom Resource Definitions (CRD) abil. Seetõttu on Kubernetesi rakendustel järgmised imelised omadused:

• Automatiseerimine: Kubernetes'i uuendused pakuvad mehhanismi muutuste rakendamise protsessi automatiseerimiseks korrektselt ja õigeaegselt.
• Konvergents: Kubernetes jätkab uuenduste katsetamist, kuni need õnnestuvad.
• Idempotentsus: korduvad konvergeerimised viivad sama tulemuse juurde.
• Determinism: piisavate ressursside korral sõltub värskendatud klastriseisund ainult soovitud olekust.

Kuidas GitOps töötab

Oleme piisavalt palju teada saanud Kubernetes'ist, et selgitada GitOps'i tööpõhimõtteid.

Naasime tagasi pereliikmete kindlustusmeeskondade juurde, mis tegelevad mikroteenustega. Mida nad tavaliselt teevad? Vaadake allolevat loetelu (kui mõni punkt tundub kummaline või tundmatu, palun ärge kiirustage kriitikaga ning jääge meiega). Need on vaid näited tööprotsessidest, mis põhinevad Jenkinsil. Samuti on olemas palju muid protsesse, mis kasutavad erinevaid tööriistu.

Peamine on see, et iga värskendus lõpeb konfiguratsiooni failide ja Git repode muutmisega. Need muudatused Gitis toovad kaasa selle, et 'GitOps operaator' värskendab klastrit:

1. Tööprotsess: 'Jenkinsi ehitus — master haru».
Ülesannete loetelu:

• Jenkins push’ib märgistatud pildid Quaysse;
• Jenkins push’ib konfiguratsiooni ja Helm graafikud master-hoidla ämbri;
• Pilveteenus kopeerib konfiguratsiooni ja graafikud master-hoidla ämbrist Git reposse master;
• GitOps operaator värskendab klastrit.

2. Jenkinsi ehitus — release või hotfix haru:

• Jenkins push’ib märgistamata pildid Quaysse;
• Jenkins push’ib konfiguratsiooni ja Helm graafikud staging-hoidla ämbri;
• Pilveteenus kopeerib konfiguratsiooni ja graafikud staging-hoidla ämbrist Git reposse staging;
• GitOps operaator värskendab klastrit.

3. Jenkinsi ehitus — develop või feature haru:

• Jenkins push’ib märgistamata pildid Quaysse;
• Jenkins push'ib konfiguratsiooni ja Helm graafikud develop-hoidla anumisse;
• Pilvefunktsioon kopeerib konfiguratsiooni ja graafikud develop-hoidla anumast Git-repositsiooni develop;
• GitOps operaator värskendab klastrit.

4. Uue kliendi lisamine:

• Juhataja või administraator (LCM/ops) kutsub esile Gradle'i esialgseks paigaldamiseks ja võrgu ko-load tasakaalustajate (NLB) seadistamiseks;
• LCM/ops kommenteerib uue konfiguratsiooni, et valmistada deployment'i värskendusteks;
• GitOps operaator värskendab klastrit.

Lühike ülevaade GitOps'ist

1. Kirjeldage kogu süsteemi soovitud seisundit, kasutades deklaratiivseid spetsifikatsioone iga keskkonna jaoks (meie loos määrab Bobi meeskond kogu süsteemi konfiguratsiooni Git'is).
   • Git-repositsioon on ainus tõe allikas kogu süsteemi soovitud seisundi osas.
   • Kõik muudatused soovitud seisundisse viiakse ellu Git'isse komiteerimise teel.
   • Kõik soovitud klastriparametrid on samuti nähtavad klastris endas. Seega saame määrata, kas soovitud ja nähtud seisundid on kooskõlas (konvergivad, converge) või erinevad (diverge, diverge) soovitud ja nähtud seisunditest.
2. Kui soovitud ja nähtud seisundid erinevad, siis:
   • On olemas konvergentsimehhanism, mis sünkroniseerib sihitud ja täheldatud olekud varem või hiljem automaatselt. Klastri sees tegeleb sellega Kubernetes.
   • Protsess algab koheselt teatega "change committed".
   • Mõne konfigureeritava ajavahemiku jooksul võib saadetud olla teade "diff", kui olekud erinevad.
3. Seega põhjustavad kõik Git'i commitid kontrollitavaid ja idempotentseid uuendusi klastris.
   • Tagasiulatuv on konvergents varasema, soovitud oleku juurde.
4. Konvergents on lõplik. Selle toimumise näitajad on:
   • Teadete "diff" puudumine teatud ajavahemiku jooksul.
   • Teade "converged" (näiteks webhook, Git writeback'i sündmus).

Mis on divergeerumine?

Korratakse veel kord: kõik soovitud omadused peavad olema klastris nähtavad.

Mõned näited divergeerumisest:

• Konfiguratsioonifaili muutmine Git'i harude ühendamise tõttu.
• Konfiguratsioonifaili muutmine Git'i commit'i tõttu, mis tehti GUI-klientidega.
• Mitmed soovitud oleku muutused Git'i PR tõttu, mille järgselt ehitati konteineri pilt ja muudeti konfiguratsiooni.
• Klastri oleku muutmine vigade, ressursside konfliktide, 'halva käitumise' või lihtsalt algse oleku juhusliku kõrvalekalde tõttu.

Mis on konvergentsimehhanism?

Mõned näited:

• Konteinerite ja klastrite jaoks pakub konvergentsimehhanism Kubernetes.
• Sama mehhanismi saab kasutada rakenduste ja Kubernetesel põhinevate konstruktide haldamiseks (nt Istio ja Kubeflow).
• Töösuhete haldamise mehhanism Kubernetes'i, pildirepositoariumide ja Git'i vahel võimaldab GitOps operaator Weave Flux, mis on osa Weave Cloud.
• Baasmachines peab konvergentsimehhanism olema deklaratiivne ja autonoomne. Oma kogemuste põhjal võime öelda, et Terraform see on lähim sellele määratlemisele, siiski nõuab see siiski inimkontrolli. Selle mõttes laiendab GitOps traditsioone Infrastructure as Code.

GitOps ühendab Git'i suurepärase Kubernetes'e konvergentsimehhanismi, pakkudes ekspluateerimise mudelit.

GitOps võimaldab meil kinnitada: automaatika ja kontrollitavad on ainult need süsteemid, mida saab kirjeldada ja jälgida..

GitOps on mõeldud kogu cloud native-ökoüstele (nt Terraform jne).

GitOps ei tähenda ainult Kubernetes't. Me tahame, et kogu süsteem oleks deklareeritud juhtimise alusel ning kasutaks konvergentsi. Aluses mõistame kogu süsteemi, mis koosneb Kubernetes'ega töötavatest keskondadest — näiteks "dev cluster 1", "production" jne. Igas keskkonnas on masinad, klastrid, rakendused ning liidesed, mis ühendavad väliseid teenuseid andmete, jälgimise jne jaoks.

Pange tähele, kui oluline on Terraform antud juhul bootstrapping'i probleemi jaoks. Kubernetes peab olema kusagil juurutatud ning Terraformi kasutamine võimaldab meil rakendada samu GitOps tööprotsesse, et luua juhtimisläbilöök, mis toetab Kubernetes'e ja rakendusi. See on kasulik parim praktika.

Suurt tähelepanu pööratakse GitOps kontseptsioonide rakendamisele Kubernetes'e kohal olevates kihtides. Praegu on olemas GitOps-tüüpi lahendusi Istio, Helm, Ksonnet, OpenFaaS ja Kubeflow jaoks, samuti näiteks Pulumi, mis loovad kihtide arendamiseks cloud native.

Kubernetes CI/CD: GitOps'i ja teiste lähenemisviiside võrdlus.

Nagu varem mainitud, on GitOps kaks asja:

1. Käitamismudel Kubernetes'e ja cloud native jaoks, nagu eespool kirjeldatud.
2. Arendatud keskkonna loomine rakenduste haldamiseks arendajatele.

Paljude jaoks on GitOps peamiselt Git-push’idele põhinev töövoog. Meile meeldib see ka. Kuid see pole veel kõik: vaatame nüüd CI/CD torustikke.

GitOps tagab pideva juurutamise (CD) Kubernetes'e all.

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

• Rakenduse värskendamine nõuab värskendamist Git'is. See on tehinguline värskendus soovitud olekusse. 'Juurutamine' toimub seejärel klastris ise Kubernetes'e poolt värskendatud kirjelduse põhjal.
• Kubernetes'e tööpõhimõtete tõttu on need värskendused konvergentsed. See tagab mehhanismi pidevaks juurutamiseks, kus kõik värskendused on aatomaarne.
• Märkus: Weave Cloud pakub GitOps'i operaatorit, mis integreerib Git'i ja Kubernetes'e, võimaldades CD-d, sobitades klastris soovitud ja praegust olekut.

Ilma kubectl'i ja skriptideta.

Vältida tuleks Kubectli kasutamist klastri värskendamiseks, eriti kubectl käskude rühmitamise skripte. Selle asemel saab kasutaja GitOps torustiku kaudu oma Kubernetes klastrit Git'i kaudu uuendada.

Eelised hõlmavad:

1. Õigsus. Uuenduste gruppi saab rakendada, konvergida ja lõpuks valideerida, mis viib meid lähemale aatomse paigaldamise eesmärgile. Vastupidiselt ei paku skriptide kasutamine mingeid konvergentsi garantiisid (rohkem sellest allpool).
2. Ohutus. Tsiteerides Kelsey Hightowerit: «Piira juurdepääs Kubernetes klastri tööriistadele ja administratoridele, kellele kuulub selle tõrkeotsing või töökorras hoidmine». Vaata ka minu postitust turbe ja tehniliste nõuete täitmise kohta, samuti artiklit Homebrew´ häkkimise kohta kasutajakontode varastamise kaudu hoolimatult koostatud Jenkins skripti kaudu.
3. Kasutajakogemus. Kubectl paljastab Kubernetes objekti mudeli mehhanismi, mis on üsna keeruline. Ideaalis peaksid kasutajad süsteemiga suhtlema kõrgemal abstraktsiooni tasemel. Siin viitan taas Kelsey'le ja soovitan vaadata selline CV.

Erinevus CI ja CD vahel

GitOps parandab olemasolevaid CI/CD mudeleid.

Moodne CI-server on vahend orkestreerimiseks. Täpsemalt on see vahend CI-pipeline'ide orkestreerimiseks. Need sisaldavad ehitamist, testimist, peamisse haru liitmist jne. CI-serverid automatiseerivad keerukate mitmeastmeliste pipeline'ide haldamist. Levinud kiusatus on luua skript Kubernetes'i uuenduste komplekti jaoks ja käivitada see kui element pipeline'is muudatuste surumiseks klastrisse. Tõepoolest, paljud spetsialistid toimivad nii. Kuid see ei ole optimaalne, ja siin on miks.

CI peaks olema kasutusel muudatuste tegemiseks peaharusse, samas kui Kubernetes'i klaster peaks oma muutusi põhjal nende muudatuste alusel juhtima, et hallata CD-d "sisemiselt". Me nimetame seda cd-mudelis tõmbamise mudeliks, erinevalt CI tõukemudelidest. CD on osa runtime-orkestreerimisest.

Miks CI-serverid ei tohiks teha CD-d otseuuenduste kaudu Kubernetes's

Ärge kasutage CI-serverit, et orkestreerida otseseid uuendusi Kubernetes's CI-tööde komplekti kujul. See on anti-pattern, millest me oleme juba rääkinud oma blogis.

Na lähme tagasi Alisse ja Bobisse.

Milliste probleemidega nad silmitsi seisavad? Bobi CI-server rakendab muudatused klastrisse, kuid kui see protsessi käigus kokku kukub, ei tea Bob, millises seisundis klaster on (või peaks olema) ja kuidas seda parandada. Sama kehtib ka siis, kui jätkub edukalt.

Oletame, et Bobi meeskond on loonud uue pildi ja seejärel uuendanud oma rakendusi selle juurutamiseks (kõik see CI-protsessist).

Kui pilt koostatakse normaalselt, kuid protsess kukub kokku, peab meeskond välja selgitama:

• Kas uuendus on rakendatud?
• Kas me käivitame uut kogumist? Kas see toob kaasa soovimatuid kõrvalmõjusid — näiteks kaht erinevat sama muutumatut pilti?
• Kas peaksime ootama järgmist uuendust, enne kui käivitame kogumise?
• Mis täpselt valesti läks? Milliseid samme tuleb korrata (ja milliseid on ohutu korrata)?

Git-põhise töövoo korraldus ei taga, et Bobi meeskond ei satuks nende probleemidega silmitsi. Nad võivad endiselt komistada commit'i pushimise, sildi või mõne muu parameetri osas; siiski on see lähenemine siiski palju lähemal vaadatule kõik-ees või mitte midagi.

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

• Uuendusskriptid ei ole alati määratavad; need on kergesti eksitavad.
• CI-serverid ei konvergeeru deklareeriva klastrimudeliga.
• Isemoodulite tagamise kindel tagamine on keeruline. Kasutajad peavad olema sügava süsteemi semantika osas teadlikud.
• Osalise ebaõnnestumise korral on taastamine keerulisem.

Märkus Helm’i kohta: kui soovite kasutada Helmi, soovitame kombineerida see GitOps operaatoriga, nagu Flux-Helm. See aitab tagada konvergentsi. Üksinda Helm ei ole ei määratletud ega atomaarne.

GitOps on parim viis teostada pidevat kohaletoimetamist Kuberneteses.

Alice'i ja Bob'i meeskond rakendab GitOps'i ning avastab, et on palju lihtsam töötada tarkvaratoodetega, säilitades kõrge jõudluse ja stabiilsuse. Lõpetame selle artikli illustreerimisena, mis näitab, kuidas nende uus lähenemine välja näeb. Pidage meeles, et räägime peamiselt rakendustest ja teenustest, kuid GitOps'i saab kasutada kogu platvormi haldamiseks.

Kubernetes'e töömudel

Vaadake järgmist diagrammi. See esindab Git'i ja konteineripiltide hoidlat kui ühiseid ressursse kahele orkestreeritud elutsüklile:

• Jätkuva integreerimise töövoogu, mis loeb ja kirjutab faile Git'i ning võib värskendada konteineripiltide hoidlat.
• Runtime GitOps töövoogu, mis ühendab paigaldamise haldamise ja jälgimisega. See loeb ja kirjutab faile Git'i ning võib üles laadida konteineripilte.

Millised on peamised järeldused?

1. Probleemide eristamine: Pange tähele, et mõlemad töövood saavad andmeid vahetada, värskendades ainult Git'i või piltide hoidlat. Teisisõnu, CI ja runtime keskkonna vahel on tulemüür. Me nimetame seda "immutability firewall'iks" (immutability firewall), kuna kõik hoidlate värskendused loovad uusi versioone. Täiendava teabe saamiseks selle teema kohta vaadake slaide 72-87. selles esituses.
2. Võib kasutada kõiki CI ja Git servereid.: GitOps töötab kõigi komponentidega. Saate jätkata oma lemmik CI- ja Git-serverite, pildirepositooride ja testimistsetide kasutamist. Peaaegu kõik ülejäänud pideva toimetamise tööriistad turul nõuavad oma CI-/Git-serverit või pildihoidlat. See võib osutuda takistuseks cloud native arendamisel. GitOps-i puhul võite kasutada tuttavaid tööriistu.
3. Üritused kui integreerimisvahend: Kui andmed Git-is uuendatakse, teavitab Weave Flux (või Weave Cloud'i operaator) sellest runtime'i. Igakord, kui Kubernetes aktsepteerib muudatusi, uuendatakse Git-i. See tagab lihtsa integreerimismodelli töövoogude korraldamiseks GitOps-i jaoks, nagu on näidatud allpool.

Kokkuvõte

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

• automaatika;
• konvergents;
• idempotsents;
• determinism.

See on oluline, kuna see pakub töökorraldusmudelit arendajatele cloud native valdkonnas.

• Traditsioonilised süsteemide haldamise ja jälgimise tööriistad on seotud operatiivmeeskondadega, kes tegutsevad runbook'i raames (rutiinsete protseduuride ja toimingute komplekt — tlk.), mis selgelt seotud konkreetse deployment’iga.
• Pilv-native süsteemide haldamisel on jälgimistööriist parim viis deploymendide tulemuste hindamiseks, et arendustiim saaks kiiresti reageerida.

Kujutage ette mitmeid klastreid, mis on hajutatud erinevatesse pilvedesse ja hulganisti teenuseid, millel on omad meeskonnad ja deploymendi plaanid. GitOps pakub skaala-invariantset mudelit kogu selle külluse haldamiseks.

P.S. tõlkija märkused

Lugege ka meie blogist:

• «GitOps: Pulli ja Pushi meetodite võrdlus»;
• «Tutvustame kubedogi raamatukogu Kubernetesi ressursside jälgimiseks»;
• «Kubernetesi laiendamine ja täiendamine (ülevaade ja video ettekandest)».

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.

Kas teadsite GitOpsist enne nende kahe tõlke ilmumist Habr's?

• Jah, ma teadsin kõigest

• Ainult pinnapealselt

• Ei

Hääletas 35 kasutajat. 10 kasutajat hoidusid.

Allikas: habr.com