Märge. tõlge: Pärast hiljutist avaldamist tõmbamise ja lükkamise meetodite kohta GitOpsis nägime selle mudeli vastu üldiselt huvi, kuid venekeelseid väljaandeid sellel teemal ilmus väga vähe (Habré kohta lihtsalt pole). Seetõttu on meil hea meel pakkuda teie tähelepanu veel ühe artikli tõlkele - ehkki peaaegu aasta tagasi! - Weaveworksist, mille juht lõi termini "GitOps". Tekst selgitab lähenemisviisi olemust ja peamisi erinevusi olemasolevatest.
Aasta tagasi avaldasime . Toona jagasime, kuidas Weaveworksi meeskond käivitas täielikult Kubernetesil põhineva SaaS-i ja töötas välja ettekirjutavate parimate tavade komplekti pilvepõhises keskkonnas juurutamiseks, haldamiseks ja jälgimiseks.
Artikkel osutus populaarseks. Teised inimesed hakkasid GitOpsist rääkima ja hakkasid selle jaoks uusi tööriistu avaldama , , , , ja nii edasi. Ilmus meie veebisaidil väljaandeid ja GitOpsi kasutusjuhtumeid. Kuid mõnel inimesel on endiselt küsimusi. Mille poolest erineb mudel traditsioonilisest? ja pidev tarnimine ()? Kas Kubernetese kasutamine on vajalik?
Peagi mõistsime, et vaja on uut kirjeldust, mis pakub:
- Suur hulk näiteid ja lugusid;
- GitOpsi spetsiifiline määratlus;
- Võrdlus traditsioonilise pideva tarnega.
Selles artiklis oleme püüdnud kõiki neid teemasid käsitleda. See pakub värskendatud sissejuhatust GitOpsile ning arendaja ja CI/CD perspektiivi. Keskendume eelkõige Kubernetesele, kuigi mudelit võib üldistada.
Tutvuge GitOpsiga
Kujutage ette Alice'i. Ta juhib perekindlustust, mis pakub tervise-, auto-, kodu- ja reisikindlustust inimestele, kes on liiga hõivatud, et ise lepingute läbi ja lõhki välja mõelda. Tema äri sai alguse kõrvalprojektina, kui Alice töötas pangas andmeteadlasena. Ühel päeval mõistis ta, et suudab andmete tõhusamaks analüüsimiseks ja kindlustuspakettide koostamiseks kasutada täiustatud arvutialgoritme. Investorid rahastasid projekti ja nüüd toob tema ettevõte aastas sisse rohkem kui 20 miljonit dollarit ja kasvab kiiresti. Praegu annab see erinevatel ametikohtadel tööd 180 inimesele. See hõlmab tehnoloogiameeskonda, kes arendab, haldab veebisaiti, andmebaasi ja analüüsib kliendibaasi. 60-liikmelist meeskonda juhib ettevõtte tehniline direktor Bob.
Bobi meeskond juurutab tootmissüsteeme pilves. Nende põhirakendused töötavad GKE-s, kasutades ära Kubernetes Google Cloudis. Lisaks kasutavad nad oma töös erinevaid andme- ja analüüsitööriistu.
Perekindlustus ei hakanud konteinereid kasutama, vaid sattus Dockeri entusiasmi. Ettevõte avastas peagi, et GKE tegi klastrite juurutamise uute funktsioonide testimiseks lihtsaks ja vaevatuks. Konteinerite registri korraldamiseks lisati Jenkins for CI ja Quay, Jenkinsi jaoks kirjutati skriptid, mis lükkasid GKE-sse uued konteinerid ja konfiguratsioonid.
Mingi aeg on möödas. Alice ja Bob olid pettunud valitud lähenemisviisi toimivuses ja selle mõjus ettevõttele. Konteinerite kasutuselevõtt ei parandanud tootlikkust nii palju, kui meeskond lootis. Mõnikord katkes juurutamine ja oli ebaselge, kas koodimuudatused olid süüdi. Samuti osutus konfiguratsioonimuudatuste jälgimine keeruliseks. Tihti tuli luua uus klaster ja sinna rakendused teisaldada, kuna see oli lihtsaim viis süsteemi tekkinud jama kõrvaldamiseks. Alice kartis, et rakenduse arenedes läheb olukord hullemaks (lisaks oli valmimas uus masinõppel põhinev projekt). Bob oli suurema osa tööst automatiseerinud ega saanud aru, miks torujuhe oli endiselt ebastabiilne, ei skaleerinud hästi ja vajas perioodiliselt käsitsi sekkumist?
Siis õppisid nad GitOpsi kohta. See otsus osutus täpselt selleks, mida nad vajasid, et enesekindlalt edasi liikuda.
Alice ja Bob on juba aastaid kuulnud Gitist, DevOpsist ja infrastruktuurist kui koodi töövoogudest. GitOpsi ainulaadne on see, et see sisaldab parimaid tavasid - nii lõplikke kui ka normatiivseid - nende ideede rakendamiseks Kubernetese kontekstis. See teema , sealhulgas sisse .
Perekindlustus otsustab GitOpsi juurutada. Ettevõttel on nüüd automaatne töömudel, mis ühildub Kubernetese ja kombainidega kiirus koos stabiilsussest nad:
- leidis, et meeskonna tootlikkus kahekordistus, ilma et keegi oleks hulluks läinud;
- lõpetas skriptide teenindamise. Selle asemel saavad nad nüüd keskenduda uutele funktsioonidele ja täiustada insenerimeetodeid – näiteks juurutada kanaari levikut ja täiustada testimist;
- oleme juurutamisprotsessi täiustanud, nii et see harva katki läheb;
- sai võimaluse taastada kasutuselevõtt pärast osalisi tõrkeid ilma käsitsi sekkumiseta;
- ostetud kasutatudоSuurem usaldus tarnesüsteemide vastu. Alice ja Bob avastasid, et nad võivad jagada meeskonna paralleelselt töötavateks mikroteenuste meeskondadeks;
- oskab iga grupi jõupingutustega teha projektis 30-50 muudatust ja proovida uusi tehnikaid;
- projekti on lihtne meelitada uusi arendajaid, kellel on mõne tunni jooksul võimalus tõmbepäringute abil tootmisse värskendusi juurutada;
- kergesti läbivad auditi SOC2 raames (teenusepakkujate turvalise andmehalduse nõuete täitmiseks; loe lisaks nt. - u. tõlge.).
Mis juhtus?
GitOps on kaks asja:
- Kubernetese ja pilvepõhise rakenduse töömudel. See pakub parimate tavade kogumit konteinerite klastrite ja rakenduste juurutamiseks, haldamiseks ja jälgimiseks. Elegantne määratlus vormis pärit :
- Tee arendajakeskse rakenduste halduskeskkonna loomiseni. Rakendame Giti töövoogu nii operatsioonide kui ka arenduse jaoks. Pange tähele, et see ei puuduta ainult Git pushi, vaid kogu CI/CD ja UI/UX tööriistade komplekti korraldamist.
Paar sõna Giti kohta
Kui te pole versioonikontrollisüsteemide ja Giti-põhise töövooga tuttav, soovitame tungivalt nendega tutvuda. Okste ja tõmbetaotlustega töötamine võib alguses tunduda musta maagiana, kuid kasu on seda pingutust väärt. Siin alustama.
Kuidas Kubernetes töötab
Meie loos pöördusid Alice ja Bob GitOpsi poole pärast mõnda aega Kubernetesega koostööd. Tõepoolest, GitOps on Kubernetesiga tihedalt seotud – see on Kubernetesel põhineva infrastruktuuri ja rakenduste töömudel.
Mida Kubernetes kasutajatele annab?
Siin on mõned põhifunktsioonid.
- Kubernetese mudelis saab kõike kirjeldada deklaratiivsel kujul.
- Kubernetes API server võtab selle deklaratsiooni sisendiks ja proovib seejärel pidevalt viia klastri deklaratsioonis kirjeldatud olekusse.
- Deklaratsioonid on piisavad, et kirjeldada ja hallata mitmesuguseid töökoormusi – „rakendusi”.
- Selle tulemusena toimuvad rakenduses ja klastris muudatused järgmistel põhjustel:
- muudatused konteineri piltides;
- muudatused deklaratiivses spetsifikatsioonis;
- vead keskkonnas – näiteks konteineri kokkujooksmised.
Kubernetese suurepärased lähenemisvõimalused
Kui administraator teeb konfiguratsioonimuudatusi, rakendab Kubernetese orkestraator need klastris seni, kuni selle olek on ei jõua uuele konfiguratsioonile lähedale. See mudel töötab kõigi Kubernetese ressursside jaoks ja on laiendatav kohandatud ressursside määratlustega (CRD). Seetõttu on Kubernetese juurutustel järgmised suurepärased omadused:
- Automaatika: Kubernetese värskendused pakuvad mehhanismi muudatuste graatsiliselt ja õigeaegse rakendamise protsessi automatiseerimiseks.
- Lähenemine: Kubernetes jätkab värskenduste proovimist, kuni see õnnestub.
- Idempotentsus: Konvergentsi korduvad rakendused annavad sama tulemuse.
- Determinism: kui ressursse on piisavalt, sõltub värskendatud klastri olek ainult soovitud olekust.
Kuidas GitOps töötab
Oleme Kubernetese kohta piisavalt õppinud, et selgitada, kuidas GitOps töötab.
Tuleme tagasi perekindlustuse mikroteenuste meeskondade juurde. Mida nad tavaliselt tegema peavad? Vaadake allolevat loendit (kui mõni element selles tundub kummaline või võõras, hoidke kritiseerimisest ja jääge meie juurde). Need on vaid näited Jenkinsi töövoogudest. Muude tööriistadega töötamisel on palju muid protsesse.
Peaasi, et näeme, et iga värskendus lõpeb konfiguratsioonifailide ja Giti hoidlate muudatustega. Need Giti muudatused põhjustavad "GitOpsi operaatori" klastri värskendamise:
1. Tööprotsess: "Jenkinsi ehitus – põhiharu'.
Ülesannete nimekiri:
- Jenkins lükkab sildistatud pildid kaile;
- Jenkins lükkab konfiguratsiooni- ja Helmi diagrammid põhisalvestusämbrisse;
- Pilvefunktsioon kopeerib konfiguratsiooni ja diagrammid põhisalvestussalvest Giti põhihoidlasse;
- GitOpsi operaator värskendab klastrit.
2. Jenkinsi ehitamine – väljalaske või kiirparanduse haru:
- Jenkins lükkab märgistamata pildid kaile;
- Jenkins lükkab konfiguratsiooni- ja Helmi diagrammid lavastusliku salvestusruumi ämbrisse;
- Pilvefunktsioon kopeerib konfiguratsiooni ja diagrammid etapiviisilisest salvestusruumist Giti andmehoidlasse;
- GitOpsi operaator värskendab klastrit.
3. Jenkins build – arendada või iseloomustada haru:
- Jenkins lükkab märgistamata pildid kaile;
- Jenkins lükkab konfiguratsiooni- ja Helmi diagrammid arendussalvestuse ämbrisse;
- Pilvefunktsioon kopeerib konfiguratsiooni ja diagrammid arendussalvestussalvest Giti arendushoidlasse;
- GitOpsi operaator värskendab klastrit.
4. Uue kliendi lisamine:
- Haldur või administraator (LCM/ops) kutsub Gradle'i esmalt juurutama ja konfigureerima võrgu koormuse tasakaalustajaid (NLB-sid);
- LCM/ops rakendab värskenduste jaoks juurutamise ettevalmistamiseks uue konfiguratsiooni;
- GitOpsi operaator värskendab klastrit.
GitOpsi lühikirjeldus
- Kirjeldage kogu süsteemi soovitud olekut, kasutades iga keskkonna jaoks deklaratiivseid spetsifikatsioone (meie loos määratleb Bobi meeskond kogu süsteemi konfiguratsiooni Gitis).
- Giti hoidla on ainus tõeallikas kogu süsteemi soovitud oleku kohta.
- Kõik soovitud oleku muudatused tehakse Gitis tehtavate kohustuste kaudu.
- Kõik soovitud klastri parameetrid on vaadeldavad ka klastris endas. Sel viisil saame kindlaks teha, kas need langevad kokku (lähenevad, lähenema) või erineda (erineda, lahknema) soovitud ja vaadeldud olekud.
- Kui soovitud ja vaadeldud olekud erinevad, siis:
- On olemas konvergentsimehhanism, mis varem või hiljem automaatselt sünkroniseerib siht- ja vaadeldud olekud. Klastris teeb seda Kubernetes.
- Protsess algab kohe hoiatusega „muudatus on tehtud”.
- Pärast teatud konfigureeritavat ajavahemikku saab saata "erinevusteate", kui olekud on erinevad.
- Nii põhjustavad kõik Gitis tehtud kohustused klastri kontrollitavaid ja idempotentseid värskendusi.
- Tagasipööramine on lähenemine varem soovitud olekule.
- Ühinemine on lõplik. Selle esinemist näitavad:
- Teatud aja jooksul pole erinevusi hoiatusi.
- "konvergeeritud" hoiatus (nt veebihaak, Giti tagasikirjutussündmus).
Mis on lahknemine?
Kordame veel kord: kõik soovitud klastri omadused peavad olema klastris endas jälgitavad.
Mõned näited lahknemisest:
- Konfiguratsioonifaili muutus Giti filiaalide ühendamise tõttu.
- Konfiguratsioonifaili muudatus GUI-kliendi tehtud Git-kohustuse tõttu.
- Soovitud oleku mitu muudatust Giti PR-i tõttu, millele järgneb konteineri kujutise loomine ja konfiguratsioonimuudatused.
- Klastri oleku muutus vea tõttu, ressursikonflikt, mille tulemuseks on "halb käitumine" või lihtsalt juhuslik kõrvalekalle algsest olekust.
Mis on konvergentsi mehhanism?
Mõned näited:
- Konteinerite ja klastrite jaoks pakub lähenemismehhanismi Kubernetes.
- Sama mehhanismi saab kasutada Kubernetese-põhiste rakenduste ja kujunduste (nt Istio ja Kubeflow) haldamiseks.
- Kubernetese, pildihoidlate ja Giti vahelise interaktsiooni haldamise mehhanism pakub , mis on osa .
- Baasmasinate puhul peab konvergentsimehhanism olema deklaratiivne ja autonoomne. Omast kogemusest võime seda öelda sellele määratlusele kõige lähemal, kuid nõuab siiski inimese kontrolli. Selles mõttes laiendab GitOps infrastruktuuri kui koodi traditsiooni.
GitOps ühendab Giti Kubernetese suurepärase konvergentsimootoriga, et pakkuda kasutusmudelit.
GitOps võimaldab meil öelda: Automatiseerida ja juhtida saab vaid neid süsteeme, mida saab kirjeldada ja jälgida.
GitOps on mõeldud kogu pilve natiivse virna jaoks (näiteks Terraform jne)
GitOps pole ainult Kubernetes. Soovime, et kogu süsteemi juhitaks deklaratiivselt ja kasutataks konvergentsi. Kogu süsteemi all peame silmas Kubernetesega töötavate keskkondade kogumit – näiteks “dev cluster 1”, “production” jne. Iga keskkond sisaldab masinaid, klastreid, rakendusi, aga ka liideseid välisteenuste jaoks, mis pakuvad andmeid, jälgimist. ja jne.
Pange tähele, kui oluline on Terraform antud juhul alglaadimisprobleemi jaoks. Kubernetes tuleb kuskil juurutada ja Terraformi kasutamine tähendab, et saame rakendada samu GitOpsi töövooge, et luua Kubernetese ja rakenduste aluseks olev juhtkiht. See on kasulik parim tava.
Suur tähelepanu on GitOpsi kontseptsioonide rakendamisel Kubernetese peal asuvatele kihtidele. Hetkel on GitOps-tüüpi lahendused nii Istiole, Helmile, Ksonnetile, OpenFaaS-ile ja Kubeflow-le kui ka näiteks Pulumile, mis loovad kihi pilve native'i rakenduste arendamiseks.
Kubernetes CI/CD: GitOpsi võrdlemine teiste lähenemisviisidega
Nagu öeldud, on GitOps kaks asja:
- Ülalkirjeldatud Kubernetese ja pilvepõhise rakenduse töömudel.
- Tee arendajakeskse rakenduste halduskeskkonda.
Paljude jaoks on GitOps peamiselt Git-tõuketel põhinev töövoog. Ta meeldib meile ka. Kuid see pole veel kõik: vaatame nüüd CI/CD torujuhtmeid.
GitOps võimaldab Kubernetese jaoks pidevat juurutamist (CD).
GitOps pakub pidevat juurutusmehhanismi, mis välistab vajaduse eraldi juurutamise haldussüsteemide järele. Kubernetes teeb kogu töö teie eest ära.
- Rakenduse värskendamine nõuab Gitis värskendamist. See on tehinguvärskendus soovitud olekusse. Seejärel teostab Kubernetes värskendatud kirjelduse põhjal klastris "juurutamise".
- Kubernetese toimimise olemuse tõttu on need värskendused ühtlustuvad. See tagab pideva juurutamise mehhanismi, kus kõik värskendused on tuumakad.
- Märkus: pakub GitOpsi operaatorit, mis integreerib Giti ja Kubernetese ning võimaldab CD-d esitada, ühildades klastri soovitud ja praeguse oleku.
Ilma kubectli ja skriptideta
Peaksite vältima Kubectli kasutamist klastri värskendamiseks ja eriti vältige skriptide kasutamist kubectli käskude rühmitamiseks. Selle asemel saab kasutaja GitOpsi torujuhtmega värskendada oma Kubernetese klastrit Giti kaudu.
Hüvede hulka kuuluvad:
- Õige. Värskenduste rühma saab rakendada, koondada ja lõpuks kinnitada, viies meid lähemale tuuma kasutuselevõtu eesmärgile. Seevastu skriptide kasutamine ei anna ühtlustamise garantiid (sellest lähemalt allpool).
- turvalisus. Kelsey Hightower: "Piirdage juurdepääs oma Kubernetese klastrile automatiseerimistööriistadele ja administraatoritele, kes vastutavad selle silumise või hooldamise eest." Vaata ka ohutuse ja tehnilistele kirjeldustele vastavuse kohta, samuti varastades hooletult kirjutatud Jenkinsi stsenaariumi volikirjad.
- Kasutajakogemus. Kubectl paljastab Kubernetese objektimudeli mehaanika, mis on üsna keeruline. Ideaalis peaksid kasutajad süsteemiga suhtlema kõrgemal abstraktsioonitasemel. Siinkohal viitan taas Kelseyle ja soovitan vaadata .
Erinevus CI ja CD vahel
GitOps täiustab olemasolevaid CI/CD mudeleid.
Kaasaegne CI-server on orkestreerimistööriist. Eelkõige on see tööriist CI torujuhtmete orkestreerimiseks. Nende hulka kuuluvad ehitamine, testimine, ühendamine pagasiruumiga jne. CI-serverid automatiseerivad keerukate mitmeastmeliste torujuhtmete haldamise. Levinud kiusatus on skriptida Kubernetese värskenduste komplekt ja käivitada see konveieri osana, et viia klastris muudatused. Tõepoolest, seda teevad paljud eksperdid. Kuid see pole optimaalne ja siin on põhjus.
CI-d tuleks kasutada värskenduste edastamiseks pagasiruumi ja Kubernetese klaster peaks nende värskenduste põhjal ise muutuma, et CD-d sisemiselt hallata. Me kutsume seda , erinevalt CI push mudelist. CD on osa käitusaegne orkestratsioon.
Miks CI-serverid ei peaks Kubernetesis otsevärskenduste kaudu CD-sid tegema?
Ärge kasutage CI-serverit Kubernetese otsevärskenduste korraldamiseks CI-tööde komplektina. See on antimuster, millest me räägime oma blogis.
Lähme tagasi Alice'i ja Bobi juurde.
Milliste probleemidega nad silmitsi seisid? Bobi CI-server rakendab muudatused klastris, kuid kui see protsessi käigus kokku jookseb, ei tea Bob, mis olekus klaster on (või peaks olema) või kuidas seda parandada. Sama kehtib ka edu korral.
Oletame, et Bobi meeskond koostas uue pildi ja seejärel parandas pildi juurutamiseks oma juurutusi (kõik CI torustikust).
Kui pilt ehitatakse normaalselt, kuid torujuhe ebaõnnestub, peab meeskond välja mõtlema:
- Kas värskendus on välja lastud?
- Kas käivitame uue ehituse? Kas see toob kaasa tarbetuid kõrvalmõjusid – võimalusega saada kaks sama muutumatu kujutise konstruktsiooni?
- Kas peaksime enne ehituse käivitamist ootama järgmist värskendust?
- Mis täpselt valesti läks? Milliseid samme tuleb korrata (ja milliseid on ohutu korrata)?
Giti-põhise töövoo loomine ei garanteeri, et Bobi meeskonnal neid probleeme ei teki. Nad võivad siiski teha vea commit push, sildi või mõne muu parameetriga; see lähenemisviis on siiski palju lähemal selgesõnalisele kõik või mitte midagi lähenemisviisile.
Kokkuvõtteks võib öelda, miks CI-serverid ei peaks CD-ga tegelema:
- Värskendusskriptid ei ole alati deterministlikud; Nendes on lihtne vigu teha.
- CI-serverid ei lähe kokku deklaratiivse klastri mudeliga.
- Idempotentsust on raske garanteerida. Kasutajad peavad mõistma süsteemi sügavat semantikat.
- Osalisest ebaõnnestumisest on raskem taastuda.
Märkus Helmi kohta: kui soovite Helmi kasutada, soovitame seda kombineerida GitOpsi operaatoriga, näiteks . See aitab tagada konvergentsi. Helm ise ei ole ei deterministlik ega aatomiline.
GitOps on parim viis Kubernetese pideva edastamise juurutamiseks
Alice ja Bobi meeskond rakendab GitOpsi ja avastab, et tarkvaratoodetega töötamine, kõrge jõudluse ja stabiilsuse säilitamine on muutunud palju lihtsamaks. Lõpetame selle artikli illustratsiooniga, mis näitab, kuidas nende uus lähenemisviis välja näeb. Pidage meeles, et me räägime enamasti rakendustest ja teenustest, kuid GitOpsi saab kasutada terve platvormi haldamiseks.
Kubernetese töömudel
Vaadake järgmist diagrammi. See esitleb Giti ja konteineri kujutiste hoidlat jagatud ressurssidena kahe korraldatud elutsükli jaoks:
- Pidev integreerimiskonveier, mis loeb ja kirjutab Giti faile ning saab värskendada konteineri piltide hoidlat.
- Käitusaegne GitOpsi torujuhe, mis ühendab juurutamise haldamise ja jälgitavusega. See loeb ja kirjutab faile Giti ning saab alla laadida konteineripilte.
Millised on peamised leiud?
- Murede eraldamine: Pange tähele, et mõlemad torujuhtmed saavad suhelda ainult Giti või pildihoidla värskendamisega. Teisisõnu, CI ja käituskeskkonna vahel on tulemüür. Me nimetame seda "muutumatuse tulemüüriks" (muutmatu tulemüür), kuna kõik hoidla värskendused loovad uusi versioone. Selle teema kohta lisateabe saamiseks vaadake slaide 72–87 .
- Saate kasutada mis tahes CI- ja Git-serverit: GitOps töötab mis tahes komponendiga. Saate jätkata oma lemmik-CI- ja Git-serverite, pildihoidlate ja testkomplektide kasutamist. Peaaegu kõik muud turul olevad pideva edastamise tööriistad nõuavad oma CI/Giti serverit või pildihoidlat. See võib muutuda piiravaks teguriks pilve algallika arengus. GitOpsiga saate kasutada tuttavaid tööriistu.
- Sündmused kui integratsioonitööriist: niipea, kui Giti andmeid värskendatakse, teavitab Weave Flux (või Weave Cloudi operaator) käitusajast. Iga kord, kui Kubernetes muudatuste komplekti vastu võtab, värskendatakse Giti. See annab lihtsa integratsioonimudeli GitOpsi töövoogude korraldamiseks, nagu allpool näidatud.
Järeldus
GitOps pakub tugevaid värskendusgarantiid, mida nõuavad kõik kaasaegsed CI/CD tööriistad:
- automatiseerimine;
- lähenemine;
- idempotentsus;
- determinism.
See on oluline, kuna see pakub pilvepõhiste arendajatele töömudelit.
- Traditsioonilised süsteemide haldamise ja jälgimise tööriistad on seotud käsiraamatus töötavate operatsioonimeeskondadega (rutiinsete protseduuride ja toimingute komplekt – umbes tõlge), mis on seotud konkreetse kasutuselevõtuga.
- Pilvepõhises halduses on jälgitavuse tööriistad parim viis juurutuste tulemuste mõõtmiseks, et arendusmeeskond saaks kiiresti reageerida.
Kujutage ette paljusid klastreid, mis on hajutatud erinevates pilvedes ja paljudes teenustes, millel on oma meeskonnad ja juurutusplaanid. GitOps pakub kogu selle külluse haldamiseks mastaabis muutumatut mudelit.
PS tõlkijalt
Loe ka meie blogist:
- «";
- «";
- «'.
Küsitluses saavad osaleda ainult registreerunud kasutajad. palun.
Kas teadsite GitOpsist enne, kui need kaks tõlget Habres ilmusid?
-
Jah, ma teadsin kõike
-
Ainult pealiskaudselt
-
ei
35 kasutajat hääletas. 10 kasutajat jäi erapooletuks.
Allikas: www.habr.com