🥇Kas ir GitOps?

Piezīme:: Pēc nesen publicētā materiāla par pull un push metodēm GitOps, mēs pamanījām interesi par šo modeli kopumā, tomēr krieviski rakstītu publikāciju par šo tēmu bija pavisam maz (Habrē to vienkārši nav). Tādēļ esam priecīgi piedāvāt jums pārtulkojumā citu rakstu — lai arī jau gandrīz gada vecu! — no uzņēmuma Weaveworks, kura vadītājs izdomāja terminu „GitOps”. Tekstā tiek skaidrota pieejas būtība un galvenās atšķirības no jau eksistējošām.

Pirms gada mēs publicējām ievadu GitOps. Tajā mēs stāstījām, kā Weaveworks komanda uzsāka SaaS, kas pilnībā balstās uz Kubernetes, un izstrādāja labāko prakses noteikumu kopumu izvietošanai, pārvaldīšanai un uzraudzībai cloud native vidē.

Raksts izrādījās populārs. Citi cilvēki sāka runāt par GitOps, un sāka publicēt jaunus rīkus git push, izstrādei, noslēpumiem, funkcijām, pastāvīgai integrācijai un tamlīdzīgi. Mūsu vietnē parādījās liels daudzums publikācijas un GitOps izmantošanas piemēri. Bet dažiem cilvēkiem tomēr palika jautājumi. Kā šis modelis atšķiras no tradicionālās infrastructure as code un pastāvīgas piegādes (continuous delivery)? Vai obligāti jāizmanto Kubernetes?

Drīz vien mēs sapratām, ka nepieciešams jauns apraksts, kas piedāvā:

Lielu piemēru un stāstu daudzumu;
Konkrētu GitOps definīciju;
Salīdzinājumu ar tradicionālo continuous delivery.

Šajā rakstā mēs centāmies aptvert visas šīs tēmas. Tajā jūs atradīsiet atjauninātu ievadu GitOps un skatījumu uz to no izstrādātāju un CI/CD puses. Mēs galvenokārt koncentrējamies uz Kubernetes, lai gan modeli pilnīgi var generalizēt.

Iepazīstieties: GitOps

Iedomājieties Alisu. Viņa vada uzņēmumu Family Insurance, kas piedāvā veselības, automobiļu, nekustamā īpašuma un ceļojumu apdrošināšanas polises cilvēkiem, kuri ir pārāk aizņemti, lai paši izprastu līgumu nianses. Viņas bizness sākās kā blakusprojekts, kad Alisa strādāja bankā kā datu zinātniece. Kādu dienu viņa saprata, ka var izmantot mūsdienīgas datoralgoritmus datu analīzes un apdrošināšanas risinājumu izveidē. Investori finansēja projektu, un tagad viņas uzņēmums nopelna vairāk nekā 20 miljonus dolāru gadā un strauji aug. Patlaban tajā strādā 180 cilvēku dažādās pozīcijās. Viņu vidū ir tehnoloģiju komanda, kas nodarbojas ar mājaslapas, datu bāzes izstrādi un klientu bāzes analīzi. Komandu, kas sastāv no 60 cilvēkiem, vada Bobs — uzņēmuma tehniskais direktors.

Boba komanda izvieto produkcijas sistēmas mākoņos. Viņu galvenās lietojumprogrammas darbojas uz GKE, gūstot labumu no Kubernetes priekšrocībām Google Cloud. Turklāt viņi izmanto dažādus rīkus datu apstrādei un analītikai.

Family Insurance neplānoja izmantot konteinerus, taču viņi sajutās iedvesmoti no Docker. Drīz uzņēmuma speciālisti atklāja, ka GKE ļauj viegli un vienkārši izvietot klasterus, lai testētu jaunas funkcijas. Tika pievienota Jenkins CI un Quay konteineru reģistra organizēšanai, kā arī tika uzrakstīti skripti Jenkins, kas automātiski ielādēja jaunus konteinerus un konfigurācijas GKE.

Ir pagājis kāds laiks. Alise un Bobs vairs nebija apmierināti ar izvēlētā pieejas sniegumu un tās ietekmi uz uzņēmējdarbību. Konteineru ieviešana nepaaugstināja sniegumu tik, cik cerēja komanda. Dažreiz izvietojumi sabojājās, un bija neskaidrs, vai par iemeslu ir koda izmaiņas. Arī config maiņu izsekošana izrādījās grūta. Bieži vien nācās izveidot jaunu klasteri un pārvietot tajā lietojumprogrammas, jo tas bija visvieglākais veids, kā novērst to haosu, uz kā pārvērtās sistēma. Alise baidījās, ka situācija pasliktināsies, attīstoties lietojumprogrammai (turklāt nākamais projekts, ko plānoja, bija balstīts uz mašīnmācīšanos). Bobs automatizēja lielāko daļu darba un nesaprata, kāpēc pipeline joprojām ir nestabila, vāji skalojas un periodiski prasa roku iejaukšanos?

Tad viņi uzzināja par GitOps. Šis risinājums izrādījās tieši tas, kas viņiem bija vajadzīgs, lai droši virzītos uz priekšu.

Alise un Bobs jau vairāku gadu garumā bija dzirdējuši par Git balstītiem darba procesiem, DevOps un infrastruktūru kā kodu. GitOps unikālums ir tajā, ka tas ievieš dažas labākās prakses — kategoriskas un normatīvas — šo ideju īstenošanā Kubernetes kontekstā. Šī tēma ir atkārtoti apspriesta, tostarp arī Weaveworks emuārā..

Family Insurance nolemj ieviest GitOps. Tagad uzņēmumam ir automatizēta ekspluatācijas sistēma, kas ir saderīga ar Kubernetes un apvieno ātrums ar stabilitāti, jo viņi:

atklāja, ka komandai ražīgums divkāršojies, un neviens no tā nenoklīst prātā;
pārtrauca skriptu apkalpošanu. Tagad viņi var koncentrēties uz jaunām funkcijām un uzlabot inženiertehniskās metodes — piemēram, ieviest kanāriju izvietojumus un uzlabot testēšanu;
uzlaboja izvietojumu procesu — tagad tas reti bija bojāts;
iegūta iespēja atjaunot izvietojumus pēc daļējiem sabrukumiem bez roku iejaukšanās;
iegūtaolielāka pārliecība piegādes sistēmās. Alise un Bobs atklāja, ka var sadalīt komandu grupās, kas nodarbojas ar mikropakalpojumiem un strādā paralēli;
var katru dienu veikt 30-50 izmaiņas projektā, ko veic katra grupa, un izmēģināt jaunas tehnikas;
vieglāk piesaistīt jaunus izstrādātājus projektam, kuriem ir iespēja veikt atjauninājumus ražošanas vidē, izmantojot pull pieprasījumus jau pēc dažām stundām;
vieglāk iziet SOC2 auditu (atbilstību pakalpojumu sniedzēju prasībām attiecībā uz datu drošu pārvaldību; vairāk lasiet, piemēram, šeit — piezīme tulkotājam).

Kas notika?

GitOps — tas ir divas lietas:

Ekspluatācijas modelis Kubernetes un cloud native. Tas nodrošina labāko praksi kopumu, lai izvietotu, pārvaldītu un uzraudzītu konteineros savāktos klasterus un lietojumprogrammas. Eleganta definīcija vienas slide veidā viens slide no Luis Faceira:
Ceļš uz izstrādātājiem draudzīgas vides radīšanu lietojumprogrammu pārvaldībai. Mēs pielietojam Git darba plūsmu gan ekspluatācijā, gan izstrādē. Ņemiet vērā, ka šeit nav runa tikai par Git push, bet gan par visu CI/CD un UI/UX rīku kopuma organizēšanu.

Dažas domas par Git

Ja neesat pazīstams ar versiju kontroles sistēmām un Git balstīto darba plūsmu, mēs stingri iesakām tās izpētīt. Sākumā darbs ar zariem un pull pieprasījumiem var šķist kā melnā maģija, bet ieguvumi ir vērti ieguldītās pūles. Šeit ir laba raksts pāris padomi, lai sāktu.

Kā darbojas Kubernetes

Mūsu stāstā Alisa un Bobs pievērsās GitOps, pēc tam, kad kādu laiku strādāja ar Kubernetes. Patiesi, GitOps ir cieši saistīts ar Kubernetes — tā ir ekspluatācijas modelis infrastruktūrai un lietojumprogrammām, kas balstītas uz Kubernetes.

Ko Kubernetes piedāvā lietotājiem?

Šeit ir dažas galvenās iespējas:

Kubernetes modelī visu var aprakstīt deklaratīvā formā.
Kubernetes API serveris pieņem šādus deklarējumus kā ievadu, un tad pastāvīgi mēģina panākt, lai klastera stāvoklis atbilstu deklarācijai.
Deklarācijas ir pietiekamas, lai aprakstītu un pārvaldītu plašu darba slodzi — "lietojumprogrammas".
Tādējādi izmaiņas lietojumprogrammā un klasterī notiek sakarā ar:
- izmaiņām konteineru attēlos;
- izmaiņām deklaratīvajā specifikācijā;
- kļūdām vidē — piemēram, konteineru avārijām.

Kubernetes lieliskās konverģences spējas

Kad administrators veic izmaiņas konfigurācijā, Kubernetes orķestrators tās piemēros klasterim, līdz tā stāvoklis tuvojās jaunajai konfigurācijai. Šis modelis darbojas ar jebkuru Kubernetes resursu un paplašinās, izmantojot Custom Resource Definitions (CRDs). Tādējādi Kubernetes izvietojumiem ir šādas lieliskas īpašības:

Automatizācija: Kubernetes atjauninājumi nodrošina mehānismu izmaiņu piemērošanas procesa automatizācijai korekti un savlaicīgi.
Konvergencija: Kubernetes turpinās mēģināt atjauninājumus līdz tiek panākta veiksme.
Idempotence: atkārtoti konverģējošu piemērošanu rezultāts ir tas pats.
Determinisms: ja resursi ir pietiekami, atjauninātā klastera stāvoklis ir atkarīgs tikai no vēlamā stāvokļa.

Kā darbojas GitOps

Mēs pietiekami esam uzzinājuši par Kubernetes, lai izskaidrotu GitOps darbības principus.

Pāriesim atpakaļ pie Family Insurance komandām, kuras saistītas ar mikroservisiem. Ar ko viņām parasti nākas saskarties? Apskatiet sarakstu zemāk (ja kādi punkti šķiet sveši vai dīvaini — lūdzu, neizsaki kritiku un palieciet ar mums). Tas ir tikai piemēru darba procesi, pamatojoties uz Jenkins. Pastāv arī daudzi citi procesi, strādājot ar citām rīkiem.

Galvenais — mēs redzam, ka katrs atjauninājums beidzas ar izmaiņām konfigurations failos un Git repozitorijos. Šīs izmaiņas Git ved pie tam, ka "GitOps operators" atjaunina klasteri:

1. Darba process: "Jenkins būve — master zars».
Uzdevumu saraksts:

Jenkins nosūta tagotus attēlus uz Quay;
Jenkins nosūta konfigurāciju un Helm diagrammas uz master krātuves mapi;
Mākoņa funkcija kopē konfigurāciju un diagrammas no master krātuves uz Git repositāriju master;
GitOps operators atjaunina klasteri.

2. Jenkins būve — release vai hotfix zars:

Jenkins nosūta netagotus attēlus uz Quay;
Jenkins nosūta konfigurāciju un Helm diagrammas uz staging krātuves mapi;
Mākoņa funkcija kopē konfigurāciju un diagrammas no staging krātuves uz Git repositāriju staging;
GitOps operators atjaunina klasteri.

3. Jenkins būve — develop vai feature zars:

Jenkins nosūta netagotus attēlus uz Quay;
Jenkins nosūta konfigurāciju un Helm diagrammas uz develop krātuves mapi;
Mākoņa funkcija kopē konfigurāciju un diagrammas no develop krātuves uz Git repositāriju develop;
GitOps operators atjaunina klasteri.

4. Jauna klienta pievienošana:

Pārvaldnieks vai administrators (LCM/ops) izsauc Gradle, lai veiktu sākotnējo izvietojumu un iestatītu tīkla slodzes balansētājus (NLB);
LCM/ops apstiprina jaunu konfigurāciju, lai sagatavotu izvietojumu atjauninājumiem;
GitOps operators atjaunina klasteri.

GitOps īss apraksts

Aprakstiet vēlamo visa sistēmas stāvokli, izmantojot deklaratīvus specifikācijas katram vidē (mūsu stāstā Boba komanda nosaka visu sistēmas konfigurāciju Git).
- Git repozitorijs ir vienīgais patiesības avots attiecībā uz vispārējo sistēmas stāvokli.
- Visas izmaiņas vēlamajā stāvoklī tiek veiktas, paveicot komitus Git.
- Visi vēlamie klastera parametri ir arī novērojami pašā klasterī. Tādējādi mēs varam noteikt, vai tie sakrīt (konverģē, converge) vai atšķiras (divergē, diverge) vēlamais un novērotais stāvoklis.
Ja vēlamais un novērotais stāvoklis atšķiras, tad:
- Ir konverģences mehānisms, kas agrāk vai vēlāk automātiski sinhronizēs mērķa un novēroto stāvokli. Klastera iekšienē to nodrošina Kubernetes.
- Process tiek uzsākts nekavējoties ar paziņojumu «izmaiņas apstiprinātas».
- Pēc noteikta konfigurējama laika var tikt nosūtīts paziņojums «atšķirība», ja stāvokļi atšķiras.
Tādējādi visi komiti Git izraisa pārbaudāmus un idempotentus atjauninājumus klasterī.
- Atgriešanās ir konverģence uz iepriekšējo vēlamo stāvokli.
Konverģence ir galīga. Par tās iestāšanos liecina:
- Paziņojumu «atšķirība» trūkums noteiktā laika periodā.
- Paziņojums «konverģēts» (piemēram, webhook, Git writeback notikums).

Kas ir divergences?

Atkārtojam vēlreiz: visi vēlamie klastera īpašības ir novērojamas pašā klasterī.

Daži diversijas piemēri:

Izmaiņas konfigurācijas failā, veicot zaru apvienošanu Git.
Izmaiņas konfigurācijas failā, veicot Git komitu, izmantojot GUI klientu.
Daudzveidīgas izmaiņas vēlamajā stāvoklī, veicot PR Git ar sekojošu konteinera attēla veidošanu un izmaiņām konfigurācijā.
Klastera stāvokļa izmaiņas, kas radītas kļūdas, resursu konflikta dēļ, kas noved pie «sliktas uzvedības», vai vienkārši nejaušas novirzes no sākotnējā stāvokļa.

Kas ir konverģences mehānisms?

Daži piemēri:

Konteineriem un klasteriem konverģences mehānisms nodrošina Kubernetes.
To pašu mehānismu var izmantot, lai pārvaldītu lietojumprogrammas un struktūras, kas balstītas uz Kubernetes (piemēram, Istio un Kubeflow).
Rīcības mehānisms darba mijiedarbības pārvaldībai starp Kubernetes, attēlu krātuves un Git nodrošina GitOps operators Weave Flux, kas ir daļa no Weave Cloud.
Pamata mehānismam konverģencei jābūt deklaratīvai un autonomai. No mūsu pieredzes varam teikt, ka Terraform tuvojoties šim definīcijai, tomēr tam ir nepieciešama cilvēka kontrole. Šajā ziņā GitOps paplašina tradīcijas Infrastructure as Code.

GitOps apvieno Git ar izcilu Kubernetes konverģences mehānismu, piedāvājot modeli ekspluatācijai.

GitOps ļauj mums apgalvot: automātikai un kontrolei pakļautas ir tikai tās sistēmas, kuras var aprakstīt un novērot.

GitOps ir paredzēts visam cloud native stekam (piemēram, Terraform utt.)

GitOps nav tikai Kubernetes. Mēs vēlamies, lai visa sistēma tiktu pārvaldīta deklaratīvi un izmantotu konverģenci. Ar visu sistēmu mēs domājam vidē, kas strādā ar Kubernetes — piemēram, «dev cluster 1», «production» utt. Katra vidē ir iekļautas mašīnas, klasteri, lietojumprogrammas un interfeisi ārējiem pakalpojumiem, kas nodrošina datus, monitoringu utt.

Pievērsiet uzmanību, cik svarīgs šajā gadījumā ir Terraform bootstrapping problēmai. Kubernetes jābūt kaut kur izvietotam, un Terraform izmantošana nozīmē, ka mēs varam piemērot tos pašus GitOps darba procesus, lai izveidotu pārvaldības slāni, kas atrodas uz Kubernetes un lietojumprogrammām. Tas ir noderīgas labākās prakses piemērs.

Liela uzmanība tiek pievērsta GitOps konceptu piemērošanai slāņiem virs Kubernetes. Šobrīd ir pieejami GitOps risinājumi, kas paredzēti Istio, Helm, Ksonnet, OpenFaaS un Kubeflow, kā arī piemēram, Pulumi, kas veido slāni lietojumprogrammu izstrādei cloud native.

Kubernetes CI/CD: salīdzinājums GitOps ar citiem pieejamajiem risinājumiem

Kā jau tika minēts, GitOps ir divas lietas:

Ekspluatācijas modelis Kubernetes un cloud native, kas aprakstīts iepriekš.
Ceļš uz izstrādātājiem orientētas vides izveidi lietojumprogrammu pārvaldībai.

Daudziem GitOps vispirms ir Git push bāzēta darba plūsma. Mums arī patīk. Bet tas nav viss: tagad aplūkosim CI/CD cauruļvadus.

GitOps nodrošina nepārtrauktu izvietošanu (CD) Kubernetes ietvaros

GitOps piedāvā nepārtrauktas izvietošanas mehānismu, kas iznīcina atsevišķu «izvietošanas pārvaldības sistēmu» nepieciešamību. Visi darbi tiek veikti par jums, izmantojot Kubernetes.

Lietotnes atjaunināšana prasa atjauninājumu Git. Tas ir transakciju atjauninājums vēlamajam stāvoklim. "Izvietošana" pēc tam tiek veikta klasterī pašam Kubernetes, pamatojoties uz atjauninātu aprakstu.
Dēļ Kubernetes darba specifikas šie atjauninājumi ir konverģējoši. Tādējādi tiek nodrošināts mehānisms nepārtrauktai izvietošanai, kurā visi atjauninājumi ir atomiski.
Piezīme: Weave Cloud piedāvā GitOps operatoru, kas integrē Git un Kubernetes, un ļauj veikt CD, salīdzinot vēlamo un esošo klastera stāvokli.

Bez kubectl un skriptiem

Jāizvairās no Kubectl izmantošanas klastera atjaunināšanai, jo īpaši no skriptiem, kas grupē kubectl komandas. Tā vietā, izmantojot GitOps cauruļu sistēmu, lietotājs var atjaunināt savu Kubernetes klasteri caur Git.

Priekšrocības ietver:

Precizitāte. Atjauninājumu grupa var tikt pielietota, konverģēta un visbeidzot validēta, kas mūs tuvinā pie atomiskā izvietošanas mērķa. Savukārt skriptu izmantošana negarantē konverģenci (vairāk par to tālāk).
Drošība. Citu vārdu Kelsey Hightower: "Ierobežojiet piekļuvi Kubernetes klasterim automatizācijas rīkiem un administratoriem, kuru pienākumos ir to atkļūdot vai uzturēt darbspēju". Skatīt arī mani publikāciju par drošību un atbilstību tehniskajiem nosacījumiem, kā arī rakstu par Homebrew uzlaušanu kā rezultātā no neuzmanīgi sastādīta Jenkins skripta izkrāpjot akreditācijas datus.
Lietotāja pieredze. Kubectl atklāj Kubernetes objektu modeļa mehāniku, kas ir ļoti sarežģīta. Ideālā gadījumā lietotājiem vajadzētu mijiedarboties ar sistēmu augstākā abstrakcijas līmenī. Šeit es atkal atsaukšos uz Kelsey un ieteikšu aplūkot šādu kopsavilkumu.

Atšķirība starp CI un CD

GitOps uzlabo esošās CI/CD modeļus.

Mūsdienu CI serveris ir rīks orķestrēšanai. Īpaši tā ir rīks CI cauruļu sistēmu orķestrēšanai. Tajās ietilpst izveide, testi, saplūšana uz galvenā un t. t. CI serveri automatizē sarežģītu daudzsolīgu cauruļu vadību. Biežas kārdinājums ir izveidot skriptu Kubernetes atjauninājumu komplektam un to izpildīt kā cauruļvadu elementu izmaiņu iespiešanai klasterī. Patiesībā tā rīkojas daudz profesionāļu. Tomēr tas nav optimāli, un šeit ir iemesls.

CI jāizmanto, lai veiktu atjauninājumus trunk, un Kubernetes klasterim jāmaina sevi, pamatojoties uz šiem atjauninājumiem, lai pārvaldītu CD "iekšēji". Mēs to saucam par pull modeli CD, atšķirībā no CI push modeļa. CD ir daļa no runtime orķestrācijas..

Kāpēc CI serveriem nevajadzētu veikt CD, tieši atjauninot Kubernetes

Neizmantojiet CI serveri, lai orkestrētu tiešus atjauninājumus Kubernetes kā CI uzdevumu kopumu. Tas ir pretparaugs, par kuru mēs jau stāstījām rakstījām savā emuārā.

Atgriezīsimies pie Alises un Boba.

Ar kādām problēmām viņi saskārās? Boba CI servers piemēro izmaiņas klasterim, taču, ja viņš šajā procesā avarē, Bobs nezina, kādā stāvoklī atrodas (vai tam vajadzētu būt) klasteris un kā to labot. Tas pats attiecas uz veiksmīgu gadījumu.

Pieņemsim, ka Boba komanda ir uzbūvējusi jaunu attēlu un pēc tam ir atjauninājusi savus deploymentus, lai izvietotu attēlu (viss no CI cauruļvada).

Ja attēls tiek izveidots pareizi, bet cauruļvads avarē, komandai būs jānoskaidro:

Vai atjauninājums ir izvietots?
Vai mēs palaidām jaunu versiju? Vai tas izraisīs nevajadzīgas blakusparādības — pastāv iespēja iegūt divas versijas viena un tā paša nemainīgā attēla?
Vai mums jāgaida nākamais atjauninājums, pirms palaidām versiju?
Kas tieši nenotika pareizi? Kādi soļi jāatkārto (un kuri no tiem var droši atkārtot)?

Git bāzētā darba plūsmas organizācija negarantē, ka Boba komanda nesaskarsies ar šīm problēmām. Viņi joprojām var kļūdīties ar commit push, ar tagu vai citu parametru; tomēr šis piegājens joprojām ir daudz tuvāks skaidrai viss-vai-nothing pieejai.

Kopsavilkumā, šeit ir iemesli, kāpēc CI serveriem nevajadzētu veikt CD:

Atjauninājumu skripti nav vienmēr determinēti; tajos ir viegli pieļaut kļūdas.
CI serveri nekonverģē uz deklaratīvo klastera modeli.
Ir grūti garantēt idempotentību. Lietotājiem jāiepazīstas ar sistēmas dziļo semantiku.
Grūtāk ir veikt atjaunošanu pēc daļējas kļūmes.

Piezīme par Helm: ja vēlaties izmantot Helm, mēs iesakām to apvienot ar GitOps operatoru, piemēram, Flux-Helm. Tas palīdzēs nodrošināt konverģenci. Pats Helm nav ne determinēts, ne atomārs.

GitOps kā labākais veids, kā īstenot Continuous Delivery Kubernetes.

Alisas un Boba komanda ievieš GitOps un atklāj, ka ir daudz vieglāk strādāt ar programmatūras produktiem, uzturēt augstu veiktspēju un stabilitāti. Noslēgsim šo rakstu ar ilustrācijām, kurās parādīts, kā izskatās viņu jaunā pieeja. Ņemiet vērā, ka mēs galvenokārt runājam par lietojumprogrammām un pakalpojumiem, tomēr GitOps var izmantot, lai pārvaldītu visu platformu.

Kubernetes ekspluatācijas modelis

Paskatieties uz nākamo diagrammu. Tā attēlo Git un konteineru attēlu krātuves kā kopīgus resursus diviem koordinētiem dzīves cikliem:

Nepārtrauktas integrācijas pipeline, kas lasa un raksta failus Git un var atjaunināt konteineru attēlu repozitoriju.
Runtime GitOps pipeline, kas apvieno izvietošanu ar pārvaldību un novērojamību. Tas lasa un raksta failus Git un var augšupielādēt konteineru attēlus.

Kādi ir galvenie secinājumi?

Problēmu sadalīšana: Ņemiet vērā, ka abi pipeline var apmainīties ar datiem, tikai atjauninot Git vai attēlu repozitoriju. Citiem vārdiem sakot, starp CI un runtime vidi pastāv ugunsmūris, ko mēs saucam par „nemaināmības ugunsmūri” (immutability firewall), jo visi repozitoriju atjauninājumi rada jaunas versijas. Papildu informāciju par šo tēmu var atrast slaidos 72-87 šīs prezentācijas.
Var izmantot jebkuru CI un Git serveri: GitOps darbojas ar jebkurām komponentēm. Jūs varat turpināt izmantot savus iecienītākos CI un Git serverus, attēlu repozitorijus un testēšanas komplektus. Praktiski visi citi instrumenti nepārtrauktai piegādei tirgū pieprasa savu CI/Git serveri vai attēlu krātuvi. Tas var kļūt par ierobežojumu cloud native attīstībā. GitOps gadījumā jūs varat izmantot ierastās rīkus.
Notikumi kā integrācijas rīks: Tiklīdz dati Git tiek atjaunināti, Weave Flux (vai Weave Cloud operators) par to paziņo runtime. Katra reize, kad Kubernetes saņem izmaiņu kopumu, Git tiek atjaunināts. Tas nodrošina vienkāršu integrācijas modeli darba plūsmām GitOps, kā parādīts zemāk.

Secinājums

GitOps nodrošina svarīgas garantijas atjaunināšanai, kas nepieciešamas jebkuram modernam CI/CD rīkam:

automātika;
konverģence;
idempotentums;
determinisms.

Tas ir svarīgi, jo tas piedāvā ekspluatācijas modeli izstrādātājiem облак native jomā.

Tradicionāli rīki sistēmu pārvaldībai un uzraudzībai ir saistīti ar ekspluatācijas komandām, kas darbojas saskaņā ar runbook. (jeb rituālo procedūru un operāciju kopuma — piezīme tulkotājam.), piesaistīts konkrētajam deployment.
Cloud native sistēmu pārvaldībā uzraudzības rīki ir labākais veids, kā novērtēt deploy rezultātus, lai izstrādātāju komanda varētu ātri reaģēt.

Iedomājieties daudzus klasterus, kas izkaisīti pa dažādiem mākoņiem, un daudzus pakalpojumus ar savām komandām un deployment plāniem. GitOps piedāvā mērogam invariantu modeli, lai to visu pārvaldītu.

P.S. no tulka

Lasiet arī mūsu emuāra rakstos:

Tikai reģistrētie lietotāji var piedalīties aptaujā. Pieteikties, lūdzu.

Vai tu zināji par GitOps vēl pirms šo divu tulkojumu parādīšanās hābrē?

Jā, es visu zināju.
Tikai virspusēji.
Nē

35 lietotāji nobalsoja. 10 lietotāji atturējās.

Avots: habr.com