Pastaba. vert.: Po neseniai paskelbtos publikacijos apie traukimo ir stūmimo metodus GitOps, matėme susidomėjimą šiuo modeliu apskritai, tačiau publikacijų rusų kalba šia tema buvo labai mažai (ant Habré jų tiesiog nėra). Todėl džiaugiamės galėdami jūsų dėmesiui pasiūlyti kito straipsnio vertimą, nors ir beveik prieš metus! - iš „Weaveworks“, kurios vadovas sugalvojo terminą „GitOps“. Tekste paaiškinama požiūrio esmė ir pagrindiniai skirtumai nuo esamų.
Prieš metus paskelbėme . Tada pasidalijome, kaip „Weaveworks“ komanda paleido „SaaS“, visiškai pagrįstą „Kubernetes“, ir sukūrė geriausios praktikos rinkinį, skirtą diegti, tvarkyti ir stebėti debesies vietinėje aplinkoje.
Straipsnis pasirodė populiarus. Kiti žmonės pradėjo kalbėti apie „GitOps“ ir pradėjo skelbti naujus įrankius , , , , ir taip toliau. Pasirodė mūsų svetainėje publikacijos ir „GitOps“ naudojimo atvejai. Tačiau kai kuriems žmonėms vis dar kyla klausimų. Kuo modelis skiriasi nuo tradicinio? ir nuolatinis pristatymas ()? Ar būtina naudoti Kubernetes?
Netrukus supratome, kad reikia naujo aprašymo, siūlančio:
- Daug pavyzdžių ir istorijų;
- Specifinis GitOps apibrėžimas;
- Palyginimas su tradiciniu nuolatiniu pristatymu.
Šiame straipsnyje mes bandėme aprėpti visas šias temas. Jame pateikiama atnaujinta įvadas į „GitOps“ ir kūrėjo bei CI / CD perspektyva. Daugiausia dėmesio skiriame Kubernetes, nors modelį galima apibendrinti.
Susipažinkite su „GitOps“.
Įsivaizduok Alisą. Ji vadovauja šeimos draudimui, kuris siūlo sveikatos, automobilių, namų ir kelionių draudimą žmonėms, kurie yra pernelyg užsiėmę, kad patys išsiaiškintų sutarčių ypatybes. Jos verslas prasidėjo kaip šalutinis projektas, kai Alisa dirbo banke duomenų mokslininke. Vieną dieną ji suprato, kad gali naudoti pažangius kompiuterinius algoritmus, kad galėtų efektyviau analizuoti duomenis ir suformuluoti draudimo paketus. Investuotojai finansavo projektą, o dabar jos įmonė per metus atneša daugiau nei 20 milijonų dolerių ir sparčiai auga. Šiuo metu joje dirba 180 žmonių įvairiose pareigose. Tai apima technologijų komandą, kuri kuria, prižiūri svetainę, duomenų bazę ir analizuoja klientų bazę. 60 žmonių komandai vadovauja Bobas, įmonės techninis direktorius.
Bobo komanda diegia gamybos sistemas debesyje. Jų pagrindinės programos veikia GKE, pasinaudojant Kubernetes „Google Cloud“ pranašumais. Be to, savo darbe jie naudoja įvairius duomenų ir analizės įrankius.
Šeimos draudimas nesiruošė naudoti konteinerių, bet pateko į Docker entuziazmą. Netrukus bendrovė išsiaiškino, kad GKE padėjo lengvai įdiegti grupes naujoms funkcijoms išbandyti. „Jenkins for CI“ ir „Quay“ buvo įtrauktos siekiant tvarkyti konteinerių registrą, buvo parašyti „Jenkins“ scenarijai, kurie perkelia naujus konteinerius ir konfigūracijas į GKE.
Praėjo šiek tiek laiko. Alisa ir Bobas buvo nusivylę pasirinkto požiūrio rezultatais ir jo įtaka verslui. Konteinerių įdiegimas nepagerino produktyvumo taip, kaip tikėjosi komanda. Kartais diegimas nutrūkdavo ir buvo neaišku, ar dėl to kalti kodo pakeitimai. Taip pat pasirodė, kad sunku sekti konfigūracijos pakeitimus. Dažnai reikėdavo sukurti naują klasterį ir į jį perkelti programas, nes tai buvo lengviausias būdas pašalinti netvarką, kuria tapo sistema. Alisa baiminosi, kad plėtojant programą situacija pablogės (be to, buvo kuriamas naujas mašininiu mokymusi paremtas projektas). Bobas automatizavo didžiąją dalį darbo ir nesuprato, kodėl dujotiekis vis dar nestabilus, netinkamai keičiamas ir periodiškai reikia rankinio įsikišimo?
Tada jie sužinojo apie „GitOps“. Šis sprendimas buvo būtent toks, kokio jiems reikėjo, kad užtikrintai judėtų pirmyn.
Alisa ir Bobas daugelį metų girdėjo apie „Git“, „DevOps“ ir infrastruktūrą kaip kodo darbo eigą. „GitOps“ unikalumas yra tas, kad jame pateikiamos geriausios praktikos – tiek galutinių, tiek norminių – rinkinys, skirtas šioms idėjoms įgyvendinti Kubernetes kontekste. Ši tema , įskaitant į .
Šeimos draudimas nusprendžia įdiegti „GitOps“. Dabar įmonė turi automatizuotą veikimo modelį, suderinamą su Kubernetes ir kombainais greitis su stabilumasnes jie:
- pastebėjo, kad komandos produktyvumas padvigubėjo, niekam neišprotėjus;
- nustojo teikti scenarijus. Vietoj to dabar jie gali sutelkti dėmesį į naujas funkcijas ir patobulinti inžinerinius metodus, pavyzdžiui, pristatyti „canary“ diegimą ir tobulinti testavimą;
- patobulinome diegimo procesą, kad jis retai sugenda;
- gavo galimybę atkurti diegimus po dalinių gedimų be rankinio įsikišimo;
- pirktas naudotasоDidesnis pasitikėjimas pristatymo sistemomis. Alisa ir Bobas atrado, kad galėtų padalinti komandą į lygiagrečiai dirbančias mikro paslaugų komandas;
- kiekvieną dieną kiekvienos grupės pastangomis gali atlikti 30-50 projekto pakeitimų ir išbandyti naujas technikas;
- į projektą nesunku pritraukti naujų kūrėjų, kurie turi galimybę per kelias valandas įdiegti atnaujinimus gamyboje naudojant ištraukimo užklausas;
- lengvai pereiti auditą pagal SOC2 (dėl paslaugų teikėjų saugaus duomenų valdymo reikalavimų laikymosi; skaitykite daugiau, pvz. - apytiksliai vertimas.).
Kas nutiko?
„GitOps“ yra du dalykai:
- „Kubernetes“ ir „native“ debesies veikimo modelis. Jame pateikiamas geriausios praktikos rinkinys, kaip diegti, valdyti ir stebėti konteinerinius klasterius ir programas. Elegantiškas apibrėžimas formoje nuo :
- Kelias kuriant į kūrėją orientuotą programų valdymo aplinką. Git darbo eigą taikome tiek operacijoms, tiek plėtrai. Atminkite, kad tai ne tik apie „Git push“, bet ir apie viso CI / CD ir UI / UX įrankių rinkinio organizavimą.
Keletas žodžių apie Gitą
Jei nesate susipažinę su versijų valdymo sistemomis ir Git pagrindu veikiančia darbo eiga, labai rekomenduojame apie jas sužinoti. Darbas su šakomis ir traukimo užklausomis iš pradžių gali atrodyti kaip juodoji magija, tačiau nauda verta pastangų. Čia pradėti.
Kaip veikia Kubernetes
Mūsų istorijoje Alisa ir Bobas kreipėsi į „GitOps“, kurį laiką dirbę su „Kubernetes“. Iš tiesų, „GitOps“ yra glaudžiai susijęs su „Kubernetes“ – tai „Kubernetes“ pagrindu sukurtos infrastruktūros ir taikomųjų programų veikimo modelis.
Ką „Kubernetes“ suteikia vartotojams?
Štai keletas pagrindinių funkcijų:
- Kubernetes modelyje viską galima aprašyti deklaratyvia forma.
- Kubernetes API serveris priima šią deklaraciją kaip įvestį ir nuolat bando perkelti klasterį į deklaracijoje aprašytą būseną.
- Deklaracijų pakanka įvairiems darbo krūviams apibūdinti ir valdyti – „programoms“.
- Dėl to programos ir grupės pakeitimai atsiranda dėl:
- konteinerių vaizdų pakeitimai;
- deklaratyvios specifikacijos pakeitimai;
- klaidos aplinkoje – pavyzdžiui, konteinerių gedimai.
„Kubernetes“ puikios konvergencijos galimybės
Kai administratorius atlieka konfigūracijos pakeitimus, Kubernetes orkestrantas taikys juos klasteriui tol, kol jo būsena bus nepriartės prie naujos konfigūracijos. Šis modelis veikia su bet kokiu Kubernetes ištekliu ir yra išplečiamas naudojant tinkintus išteklių apibrėžimus (CRD). Todėl „Kubernetes“ diegimai turi šias nuostabias savybes:
- Automatika: „Kubernetes“ naujinimai suteikia mechanizmą, leidžiantį maloniai ir laiku automatizuoti pakeitimų taikymo procesą.
- Konvergencija: Kubernetes ir toliau bandys atnaujinti, kol pavyks.
- Idempotencija: Pakartotinis konvergencijos taikymas duoda tą patį rezultatą.
- Determinizmas: Kai išteklių pakanka, atnaujinto klasterio būsena priklauso tik nuo norimos būsenos.
Kaip veikia „GitOps“.
Sužinojome pakankamai apie „Kubernetes“, kad paaiškintume, kaip veikia „GitOps“.
Grįžkime prie Šeimos draudimo mikropaslaugų komandų. Ką jie paprastai turi daryti? Peržiūrėkite žemiau esantį sąrašą (jei kuris nors jame esantis elementas atrodo keistas ar nepažįstamas, susilaikykite nuo kritikos ir likite su mumis). Tai tik Jenkins pagrįstų darbo eigos pavyzdžiai. Yra daug kitų procesų dirbant su kitais įrankiais.
Svarbiausia, kad mes matome, kad kiekvienas atnaujinimas baigiasi konfigūracijos failų ir „Git“ saugyklų pakeitimais. Dėl šių „Git“ pakeitimų „GitOps operatorius“ atnaujina klasterį:
1. Darbo procesas: "Jenkins build – pagrindinė šaka".
Užduočių sąrašas:
- Jenkinsas siunčia pažymėtus vaizdus į krantinę;
- Jenkins stumia konfigūracijos ir Helm diagramas į pagrindinį saugojimo kibirą;
- Debesijos funkcija nukopijuoja konfigūraciją ir diagramas iš pagrindinės saugyklos į pagrindinę Git saugyklą;
- „GitOps“ operatorius atnaujina klasterį.
2. Jenkins build – išleidimo arba karštųjų pataisų šaka:
- Jenkinsas siunčia nepažymėtus vaizdus į krantinę;
- Jenkins stumia konfigūracijos ir Helm diagramas į sustojimo saugojimo kibirą;
- Debesijos funkcija nukopijuoja konfigūraciją ir diagramas iš sustojimo saugyklos į sustojimo Git saugyklą;
- „GitOps“ operatorius atnaujina klasterį.
3. „Jenkins build“ – plėtoti arba išskirti šaką:
- Jenkinsas siunčia nepažymėtus vaizdus į krantinę;
- Jenkins stumia konfigūracijos ir Helm diagramas į kūrimo saugojimo kibirą;
- Debesijos funkcija nukopijuoja konfigūraciją ir diagramas iš kūrimo saugyklos į kūrimo Git saugyklą;
- „GitOps“ operatorius atnaujina klasterį.
4. Naujo kliento pridėjimas:
- Vadovas arba administratorius (LCM/ops) iškviečia „Gradle“, kad iš pradžių įdiegtų ir sukonfigūruotų tinklo apkrovos balansavimo priemones (NLB);
- LCM/ops įpareigoja naują konfigūraciją, kad paruoštų diegimą naujinimams;
- „GitOps“ operatorius atnaujina klasterį.
Trumpas GitOps aprašymas
- Apibūdinkite norimą visos sistemos būseną naudodami deklaratyvias kiekvienos aplinkos specifikacijas (mūsų istorijoje Bobo komanda apibrėžia visą sistemos konfigūraciją Git).
- Git saugykla yra vienintelis tiesos šaltinis apie norimą visos sistemos būseną.
- Visi norimos būsenos pakeitimai atliekami per įsipareigojimus Git.
- Visi pageidaujami klasterio parametrai taip pat stebimi pačiame klasteryje. Tokiu būdu galime nustatyti, ar jie sutampa (suartėja, suartėti) arba skirtis (skirti, skirtis) norimos ir stebimos būsenos.
- Jei norima ir stebima būsena skiriasi, tada:
- Egzistuoja konvergencijos mechanizmas, kuris anksčiau ar vėliau automatiškai sinchronizuoja tikslinę ir stebimas būsenas. Klasterio viduje tai daro Kubernetes.
- Procesas iškart prasideda įspėjimu „pavyko pakeisti“.
- Po tam tikro konfigūruojamo laikotarpio gali būti išsiųstas „diff“ įspėjimas, jei būsenos skiriasi.
- Tokiu būdu visi „Git“ įsipareigojimai sukelia patikrinamus ir patikimus klasterio naujinimus.
- Atšaukimas yra konvergencija į anksčiau norimą būseną.
- Konvergencija yra galutinė. Jo atsiradimą rodo:
- Tam tikrą laikotarpį nėra įspėjimų apie skirtumus.
- „suartėjimo“ įspėjimas (pvz., „Webhook“, „Git“ atrašymo įvykis).
Kas yra divergencija?
Pakartokime dar kartą: visos norimos klasterio savybės turi būti stebimos pačiame klasteryje.
Keletas skirtumų pavyzdžių:
- Konfigūracijos failo pasikeitimas dėl Git šakų sujungimo.
- Konfigūracijos failo pakeitimas dėl GUI kliento atlikto Git įsipareigojimo.
- Keletas norimos būsenos pakeitimų dėl PR sistemoje Git, po kurio sukuriamas konteinerio vaizdas ir konfigūracijos pakeitimai.
- Klasterio būsenos pasikeitimas dėl klaidos, resursų konfliktas, dėl kurio atsiranda „blogas elgesys“ arba tiesiog atsitiktinis nukrypimas nuo pradinės būsenos.
Koks yra konvergencijos mechanizmas?
Keli pavyzdžiai:
- Konteinerių ir grupių konvergencijos mechanizmą teikia Kubernetes.
- Tą patį mechanizmą galima naudoti valdant Kubernetes pagrindu sukurtas programas ir dizainus (pvz., Istio ir Kubeflow).
- Pateikiamas „Kubernetes“, vaizdų saugyklų ir „Git“ operatyvinės sąveikos valdymo mechanizmas , kuri yra dalis .
- Bazinėms mašinoms konvergencijos mechanizmas turi būti deklaratyvus ir savarankiškas. Iš savo patirties galime tai pasakyti arčiausiai šio apibrėžimo, bet vis tiek reikalauja žmogaus kontrolės. Šia prasme „GitOps“ pratęsia infrastruktūros kaip kodo tradiciją.
„GitOps“ sujungia „Git“ su puikiu „Kubernetes“ konvergencijos varikliu, kad būtų galima naudoti modelį.
„GitOps“ leidžia mums pasakyti: Tik tas sistemas, kurias galima aprašyti ir stebėti, galima automatizuoti ir valdyti.
„GitOps“ yra skirta visam debesies vietiniam krūvui (pavyzdžiui, „Terraform“ ir kt.)
„GitOps“ nėra tik „Kubernetes“. Norime, kad visa sistema būtų valdoma deklaratyviai ir būtų naudojama konvergencija. Visa sistema turime omenyje aplinkų, veikiančių su Kubernetes, rinkinį, pvz., „1 dev cluster“, „production“ ir tt Kiekviena aplinka apima mašinas, grupes, programas, taip pat sąsajas išorinėms paslaugoms, teikiančioms duomenis, stebėjimą. ir kt.
Atkreipkite dėmesį, kokia svarbi Terraform šiuo atveju yra įkrovos problema. „Kubernetes“ turi būti kažkur įdiegta, o „Terraform“ naudojimas reiškia, kad galime taikyti tas pačias „GitOps“ darbo eigas, kad sukurtume valdymo sluoksnį, kuriuo grindžiamas „Kubernetes“ ir programos. Tai naudinga geriausia praktika.
Didelis dėmesys skiriamas „GitOps“ koncepcijų taikymui sluoksniams „Kubernetes“ viršuje. Šiuo metu yra „GitOps“ tipo sprendimai, skirti „Istio“, „Helm“, „Ksonnet“, „OpenFaaS“ ir „Kubeflow“, taip pat, pavyzdžiui, „Pulumi“, kurie sukuria sluoksnį, skirtą debesų native programoms kurti.
Kubernetes CI / CD: GitOps palyginimas su kitais metodais
Kaip minėta, „GitOps“ yra du dalykai:
- Aukščiau aprašytas „Kubernetes“ ir „Cloud native“ veikimo modelis.
- Kelias į kūrėjams skirtą programų valdymo aplinką.
Daugeliui „GitOps“ pirmiausia yra darbo eiga, pagrįsta „Git“ paspaudimais. Mums jis irgi patinka. Bet tai dar ne viskas: dabar pažvelkime į CI/CD konvejerius.
„GitOps“ įgalina nuolatinį „Kubernetes“ diegimą (CD).
„GitOps“ siūlo nuolatinį diegimo mechanizmą, kuris pašalina atskirų „diegimo valdymo sistemų“ poreikį. Kubernetes atlieka visą darbą už jus.
- Norint atnaujinti programą, reikia atnaujinti Git. Tai operacijos atnaujinimas į pageidaujamą būseną. Tada „diegimą“ klasteryje atlieka pati „Kubernetes“, remdamasi atnaujintu aprašymu.
- Dėl „Kubernetes“ veikimo pobūdžio šie atnaujinimai yra konvergentiški. Tai suteikia nuolatinio diegimo mechanizmą, kuriame visi atnaujinimai yra atominiai.
- Pastaba: siūlo „GitOps“ operatorių, kuris integruoja „Git“ ir „Kubernetes“ ir leidžia atlikti kompaktinį diską suderinant pageidaujamą ir esamą klasterio būseną.
Be kubectl ir scenarijų
Turėtumėte vengti naudoti „Kubectl“ klasteriui atnaujinti, o ypač vengti naudoti scenarijus grupuodami „kubectl“ komandas. Vietoj to, naudodamas „GitOps“ dujotiekį, vartotojas gali atnaujinti savo „Kubernetes“ klasterį per „Git“.
Privalumai:
- Teisingai. Atnaujinimų grupė gali būti pritaikyta, suvienodinta ir galiausiai patvirtinta, priartinant mus prie atominio diegimo tikslo. Priešingai, scenarijų naudojimas nesuteikia jokios konvergencijos garantijos (daugiau apie tai toliau).
- saugumas. Kelsey Hightower: „Apribokite prieigą prie savo Kubernetes klasterio automatizavimo įrankiams ir administratoriams, kurie yra atsakingi už derinimą arba priežiūrą. taip pat žr apie saugumą ir techninių specifikacijų laikymąsi, taip pat pavogęs kredencialus iš neatsargiai parašyto Jenkinso scenarijaus.
- Vartotojo patirtis. Kubectl atskleidžia Kubernetes objekto modelio mechaniką, kuri yra gana sudėtinga. Idealiu atveju vartotojai turėtų bendrauti su sistema aukštesniu abstrakcijos lygiu. Čia vėl kreipsiuosi į Kelsey ir rekomenduosiu žiūrėti .
Skirtumas tarp CI ir CD
„GitOps“ patobulina esamus CI/CD modelius.
Šiuolaikinis CI serveris yra orkestravimo įrankis. Visų pirma, tai yra CI vamzdynų orkestravimo įrankis. Tai apima kūrimą, testavimą, sujungimą su magistrale ir kt. CI serveriai automatizuoja sudėtingų kelių etapų vamzdynų valdymą. Įprasta pagunda yra parašyti „Kubernetes“ naujinimų rinkinį ir paleisti jį kaip dujotiekio dalį, kad būtų perkelti klasterio pakeitimai. Iš tikrųjų taip daro daugelis ekspertų. Tačiau tai nėra optimalu, ir štai kodėl.
CI turėtų būti naudojamas naujinimams perkelti į bagažinę, o Kubernetes klasteris turėtų pasikeisti pagal šiuos naujinimus, kad būtų galima valdyti kompaktinį diską viduje. Mes tai vadiname , skirtingai nei CI push modelis. CD yra dalis vykdymo trukmės orkestravimas.
Kodėl CI serveriai neturėtų daryti kompaktinių diskų naudodami tiesioginius Kubernetes naujinimus
Nenaudokite CI serverio tiesioginiams Kubernetes naujinimams organizuoti kaip CI užduočių rinkinį. Tai yra antimodelis, apie kurį kalbame savo tinklaraštyje.
Grįžkime prie Alisos ir Bobo.
Su kokiomis problemomis jie susidūrė? Bobo CI serveris taiko pakeitimus klasteriui, bet jei jis sugenda proceso metu, Bobas nežinos, kokios būsenos yra (ar turėtų būti) klasteris arba kaip ją ištaisyti. Tas pats pasakytina ir sėkmės atveju.
Tarkime, kad Bobo komanda sukūrė naują vaizdą, o tada pataisė savo diegimus, kad būtų įdiegtas vaizdas (visa tai iš CI dujotiekio).
Jei vaizdas sukuriamas įprastai, bet dujotiekis sugenda, komanda turės išsiaiškinti:
- Ar naujinys pasirodė?
- Ar pradedame naują statybą? Ar tai sukels nereikalingų šalutinių poveikių – su galimybe turėti dvi to paties nepakeičiamo vaizdo konstrukcijas?
- Ar prieš paleisdami kūrimą turėtume palaukti kito atnaujinimo?
- Kas tiksliai nutiko? Kokius veiksmus reikia kartoti (o kuriuos saugu kartoti)?
„Git“ pagrįstos darbo eigos nustatymas negarantuoja, kad Bobo komanda nesusidurs su šiomis problemomis. Jie vis tiek gali padaryti klaidą su commit push, žyma ar kokiu nors kitu parametru; tačiau šis metodas vis dar yra daug artimesnis aiškiam „viskas arba nieko“ požiūriui.
Apibendrinant, štai kodėl CI serveriai neturėtų dirbti su kompaktiniais diskais:
- Atnaujinimo scenarijai ne visada yra deterministiniai; Juose lengva padaryti klaidų.
- CI serveriai neprieina prie deklaratyvaus klasterio modelio.
- Idempotenciją sunku garantuoti. Vartotojai turi suprasti gilią sistemos semantiką.
- Sunkiau atsigauti po dalinio gedimo.
Pastaba apie Helm: jei norite naudoti Helm, rekomenduojame jį derinti su GitOps operatoriumi, pvz. . Tai padės užtikrinti konvergenciją. Pats Helmas nėra nei deterministinis, nei atominis.
„GitOps“ kaip geriausias būdas įdiegti „Kubernetes“ nuolatinį pristatymą
Alisos ir Bobo komanda įdiegia GitOps ir atranda, kad dirbti su programinės įrangos produktais, išlaikyti aukštą našumą ir stabilumą tapo daug lengviau. Baigkime šį straipsnį iliustracija, rodančia, kaip atrodo jų naujas požiūris. Atminkite, kad dažniausiai kalbame apie programas ir paslaugas, tačiau „GitOps“ galima naudoti visai platformai valdyti.
„Kubernetes“ veikimo modelis
Pažvelkite į šią diagramą. Jame „Git“ ir konteinerio vaizdų saugykla pateikiami kaip bendri ištekliai dviems organizuotiems gyvavimo ciklams:
- Nuolatinis integravimo vamzdynas, nuskaitantis ir įrašantis failus į Git ir galintis atnaujinti konteinerio vaizdų saugyklą.
- Vykdymo laiko GitOps dujotiekis, kuris derina diegimą su valdymu ir stebėjimu. Jis skaito ir rašo failus į Git ir gali atsisiųsti konteinerio vaizdus.
Kokios pagrindinės išvados?
- Rūpesčių atskyrimas: Atminkite, kad abu dujotiekiai gali susisiekti tik atnaujindami „Git“ arba vaizdų saugyklą. Kitaip tariant, tarp CI ir vykdymo aplinkos yra ugniasienė. Mes tai vadiname „nekintamumo ugniasiene“ (nekintamumo ugniasienė), nes visi saugyklos naujinimai sukuria naujas versijas. Daugiau informacijos šia tema rasite 72–87 skaidrėse .
- Galite naudoti bet kurį CI ir Git serverį: GitOps veikia su bet kokiu komponentu. Galite ir toliau naudoti mėgstamus CI ir Git serverius, vaizdų saugyklas ir bandymų rinkinius. Beveik visi kiti rinkoje esantys nuolatinio pristatymo įrankiai reikalauja savo CI / Git serverio arba vaizdų saugyklos. Tai gali tapti ribojančiu veiksniu plėtojant vietinę debesų sistemą. Naudodami „GitOps“ galite naudoti pažįstamus įrankius.
- Renginiai kaip integravimo įrankis: Kai tik atnaujinami „Git“ duomenys, „Weave Flux“ (arba „Weave Cloud“ operatorius) praneša vykdymo laikui. Kai „Kubernetes“ priima pakeitimų rinkinį, „Git“ atnaujinamas. Tai suteikia paprastą integravimo modelį, skirtą „GitOps“ darbo eigoms organizuoti, kaip parodyta toliau.
išvada
„GitOps“ suteikia tvirtas atnaujinimo garantijas, kurių reikalauja bet kuris modernus CI / CD įrankis:
- automatizavimas;
- konvergencija;
- idempotencija;
- determinizmas.
Tai svarbu, nes jis siūlo veikimo modelį debesies vietiniams kūrėjams.
- Tradiciniai sistemų valdymo ir stebėjimo įrankiai yra susieti su operacijų komandomis, veikiančiomis pagal „runbook“. (įprastų procedūrų ir operacijų rinkinys – apytikslis vertimas), susietas su konkrečiu diegimu.
- Naudojant vietinį debesies valdymą, stebėjimo įrankiai yra geriausias būdas įvertinti diegimo rezultatus, kad kūrimo komanda galėtų greitai reaguoti.
Įsivaizduokite daugybę grupių, išsibarsčiusių skirtinguose debesyse, ir daugybę paslaugų su savo komandomis ir diegimo planais. „GitOps“ siūlo nekintamą masto modelį, skirtą valdyti visą šią gausą.
PS iš vertėjo
Taip pat skaitykite mūsų tinklaraštyje:
- «»;
- «»;
- «".
Apklausoje gali dalyvauti tik registruoti vartotojai. , Prašau.
Ar žinojote apie „GitOps“, kol šie du vertimai pasirodė Habré?
-
Taip, aš žinojau viską
-
Tik paviršutiniškai
-
Ne
Balsavo 35 vartotojų. 10 vartotojai susilaikė.
Šaltinis: www.habr.com