ProHoster > Blogs > Administrācija > Kas ir GitOps?

Kas ir GitOps?

PiezÄ«me. tulk.: Pēc nesenās publikācijas materiāls par pull un push metodēm GitOps, mēs redzējām interesi par Å”o modeli kopumā, bet krievu valodā bija ļoti maz publikāciju par Å”o tēmu (par HabrĆ© vienkārÅ”i nav). Tāpēc ar prieku piedāvājam jÅ«su uzmanÄ«bai cita raksta tulkojumu ā€“ gan jau gandrÄ«z pirms gada! ā€” no Weaveworks, kura vadÄ«tājs radÄ«ja terminu ā€œGitOpsā€. Tekstā ir izskaidrota pieejas bÅ«tÄ«ba un galvenās atŔķirÄ«bas no esoÅ”ajām.

Pirms gada publicējām ievads GitOps. Toreiz mēs dalÄ«jāmies, kā Weaveworks komanda ieviesa SaaS, kas pilnÄ«bā balstÄ«ta uz Kubernetes, un izstrādāja paraugprakses kopumu izvietoÅ”anai, pārvaldÄ«bai un uzraudzÄ«bai mākoņa vietējā 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, attÄ«stÄ«ba, noslēpumi, funkcijas, nepārtraukta integrācija un tā tālāk. ParādÄ«jās mÅ«su vietnē liels skaits publikācijas un GitOps lietoÅ”anas gadÄ«jumi. Bet dažiem cilvēkiem joprojām ir jautājumi. Kā modelis atŔķiras no tradicionālā? infrastruktÅ«ra kā kods un nepārtraukta piegāde (nepārtraukta piegāde)? Vai ir nepiecieÅ”ams lietot Kubernetes?

Drīz vien sapratām, ka nepiecieŔams jauns apraksts, piedāvājot:

  1. Liels skaits piemēru un stāstu;
  2. Specifiska GitOps definīcija;
  3. Salīdzinājums ar tradicionālo nepārtraukto piegādi.

Å ajā rakstā mēs esam mēģinājuÅ”i aptvert visas Ŕīs tēmas. Tas nodroÅ”ina atjauninātu ievadu par GitOps un izstrādātāju un CI/CD perspektÄ«vu. Mēs galvenokārt koncentrējamies uz Kubernetes, lai gan modeli var vispārināt.

Iepazīstieties ar GitOps

Iedomājies Alisi. Viņa vada Ä¢imenes apdroÅ”ināŔanu, kas piedāvā veselÄ«bas, automaŔīnu, mājas un ceļojumu apdroÅ”ināŔanu cilvēkiem, kuri ir pārāk aizņemti, lai paÅ”i izdomātu lÄ«gumu smalkumus. Viņas bizness sākās kā blakus projekts, kad Alise strādāja bankā par datu zinātnieci. Kādu dienu viņa saprata, ka var izmantot uzlabotus datoru algoritmus, lai efektÄ«vāk analizētu datus un formulētu apdroÅ”ināŔanas paketes. Investori finansēja projektu, un tagad viņas uzņēmums ienes vairāk nekā 20 miljonus dolāru gadā un strauji aug. Å obrÄ«d tajā dažādos amatos strādā 180 darbinieki. Tas ietver tehnoloÄ£iju komandu, kas izstrādā, uztur vietni, datubāzi un analizē klientu bāzi. 60 cilvēku lielu komandu vada uzņēmuma tehniskais direktors Bobs.

Boba komanda izvieto ražoÅ”anas sistēmas mākonÄ«. Viņu galvenās lietojumprogrammas darbojas GKE, izmantojot Google mākoņa Kubernetes priekÅ”rocÄ«bas. Turklāt viņi savā darbā izmanto dažādus datu un analÄ«tikas rÄ«kus.

Ä¢imenes apdroÅ”ināŔana nedomāja izmantot konteinerus, bet to aizrāva Docker entuziasms. Uzņēmums drÄ«z atklāja, ka GKE atvieglo klasteru izvietoÅ”anu, lai pārbaudÄ«tu jaunas funkcijas. Jenkins for CI un Quay tika pievienoti, lai sakārtotu konteineru reÄ£istru, tika rakstÄ«ti skripti Jenkins, kas pārsÅ«tÄ«ja jaunus konteinerus un konfigurācijas uz GKE.

Ir pagājis kāds laiks. Alise un Bobs bija vÄ«luÅ”ies par izvēlētās pieejas veiktspēju un tās ietekmi uz biznesu. Konteineru ievieÅ”ana neuzlaboja produktivitāti tik ļoti, kā komanda bija cerējusi. Dažreiz izvietoÅ”ana tika pārtraukta, un nebija skaidrs, vai vainÄ«gas bija koda izmaiņas. IzrādÄ«jās arÄ« grÅ«ti izsekot konfigurācijas izmaiņām. Bieži bija nepiecieÅ”ams izveidot jaunu klasteru un pārvietot uz to lietojumprogrammas, jo tas bija vienkārŔākais veids, kā novērst sistēmas radÄ«to nekārtÄ«bu. Alise baidÄ«jās, ka lietojumprogrammai attÄ«stoties, situācija pasliktināsies (turklāt tika gatavots jauns projekts, kas balstÄ«ts uz maŔīnmācÄ«bu). Bobs bija automatizējis lielāko daļu darba un nesaprata, kāpēc cauruļvads joprojām bija nestabils, nebija labi mērogots un periodiski bija nepiecieÅ”ama manuāla iejaukÅ”anās?

Tad viņi uzzināja par GitOps. Å is lēmums izrādÄ«jās tieÅ”i tas, kas viņiem bija nepiecieÅ”ams, lai pārliecinoÅ”i virzÄ«tos uz priekÅ”u.

Alise un Bobs gadiem ilgi ir dzirdējuÅ”i par Git, DevOps un infrastruktÅ«ru kā koda darbplÅ«smām. GitOps unikāls ir tas, ka tajā ir ietverts paraugprakses kopums ā€” gan galÄ«gs, gan normatÄ«vs ā€” Å”o ideju Ä«stenoÅ”anai Kubernetes kontekstā. Å Ä« tēma cēlās vairākkārt, tostarp iekŔā Weaveworks emuārs.

Ä¢imenes apdroÅ”ināŔana nolemj ieviest GitOps. Tagad uzņēmumam ir automatizēts darbÄ«bas modelis, kas ir savietojams ar Kubernetes un kombainiem ātrums ar stabilitātejo viņi:

  • atklāja, ka komandas produktivitāte dubultojās, nevienam nekļūstot trakam;
  • pārtrauca skriptu apkalpoÅ”anu. Tā vietā viņi tagad var koncentrēties uz jaunām funkcijām un uzlabot inženierijas metodes, piemēram, ievieÅ”ot kanārijas izlaiÅ”anu un uzlabojot testÄ“Å”anu;
  • esam uzlabojuÅ”i izvietoÅ”anas procesu, lai tas reti sabojātos;
  • ieguva iespēju atjaunot izvietoÅ”anu pēc daļējām kļūmēm bez manuālas iejaukÅ”anās;
  • pirkts lietotsŠ¾Lielāka uzticÄ“Å”anās piegādes sistēmām. Alise un Bobs atklāja, ka viņi var sadalÄ«t komandu mikropakalpojumu komandās, kas strādā paralēli;
  • katru dienu ar katras grupas pÅ«lēm var veikt 30-50 izmaiņas projektā un izmēģināt jaunas metodes;
  • projektam ir viegli piesaistÄ«t jaunus izstrādātājus, kuriem ir iespēja dažu stundu laikā ieviest atjauninājumus produkcijai, izmantojot pull pieprasÄ«jumus;
  • viegli iziet auditu SOC2 ietvaros (par pakalpojumu sniedzēju atbilstÄ«bu droÅ”as datu pārvaldÄ«bas prasÄ«bām; lasiet vairāk, piemēram, Å”eit ā€” apm. tulk.).

Kas notika?

GitOps ir divas lietas:

  1. Darbības modelis Kubernetes un mākonim. Tas nodroŔina paraugprakses kopumu konteineru klasteru un lietojumprogrammu izvietoŔanai, pārvaldībai un uzraudzībai. Eleganta definīcija formā viens slaids no Luiss Faceira:
  2. CeļŔ uz izstrādātāju orientētas lietojumprogrammu pārvaldÄ«bas vides izveidi. Mēs izmantojam Git darbplÅ«smu gan operācijām, gan attÄ«stÄ«bai. LÅ«dzu, ņemiet vērā, ka tas neattiecas tikai uz Git push, bet arÄ« par visa CI/CD un UI/UX rÄ«ku komplekta organizÄ“Å”anu.

Daži vārdi par Gitu

Ja neesat pazÄ«stams ar versiju kontroles sistēmām un uz Git balstÄ«tu darbplÅ«smu, mēs ļoti iesakām par tām uzzināt. Darbs ar zariem un vilkÅ”anas pieprasÄ«jumiem sākumā var Ŕķist melna maÄ£ija, taču ieguvumi ir pūļu vērti. Å eit labs raksts sākt.

Kā darbojas Kubernetes

MÅ«su stāstā Alise un Bobs pievērsās GitOps pēc tam, kad kādu laiku strādāja ar Kubernetes. PatieŔām, GitOps ir cieÅ”i saistÄ«ts ar Kubernetes ā€“ tas ir uz Kubernetes balstÄ«tas infrastruktÅ«ras un lietojumprogrammu darbÄ«bas modelis.

Ko Kubernetes sniedz lietotājiem?

Šeit ir dažas galvenās funkcijas:

  1. Kubernetes modelī visu var aprakstīt deklaratīvā formā.
  2. Kubernetes API serveris izmanto Å”o deklarāciju kā ievadi un pēc tam nepārtraukti mēģina nogādāt klasteru deklarācijā aprakstÄ«tajā stāvoklÄ«.
  3. Deklarācijas ir pietiekamas, lai aprakstÄ«tu un pārvaldÄ«tu dažādas darba slodzes ā€” ā€œlietojumprogrammasā€.
  4. Rezultātā izmaiņas lietojumprogrammā un klasterÄ« notiek Ŕādu iemeslu dēļ:
    • izmaiņas konteinera attēlos;
    • izmaiņas deklaratÄ«vajā specifikācijā;
    • kļūdas vidē ā€“ piemēram, konteineru avārijas.

Kubernetes lielās konverģences iespējas

Kad administrators veic konfigurācijas izmaiņas, Kubernetes orÄ·estrētājs tās piemēros klasterim, ja vien tā stāvoklis ir netuvosies jaunajai konfigurācijai. Å is modelis darbojas jebkuram Kubernetes resursam un ir paplaÅ”ināms, izmantojot pielāgotās resursu definÄ«cijas (CRD). Tāpēc Kubernetes izvietoÅ”anai ir Ŕādas brÄ«niŔķīgas Ä«paŔības:

  • Automatizācija: Kubernetes atjauninājumi nodroÅ”ina mehānismu, lai automatizētu graciozi un savlaicÄ«gu izmaiņu piemēroÅ”anas procesu.
  • KonverÄ£ence: Kubernetes turpinās mēģināt atjaunināt, lÄ«dz tas bÅ«s veiksmÄ«gs.
  • Idempotence: Atkārtoti konverÄ£ences pielietojumi rada tādu paÅ”u rezultātu.
  • 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 esam pietiekami daudz iemācÄ«juÅ”ies par Kubernetes, lai izskaidrotu, kā darbojas GitOps.

AtgriezÄ«simies pie Ä¢imenes apdroÅ”ināŔanas mikropakalpojumu komandām. Kas viņiem parasti ir jādara? Apskatiet zemāk esoÅ”o sarakstu (ja kādi vienumi tajā Ŕķiet dÄ«vaini vai nepazÄ«stami, lÅ«dzu, nekritizējiet un palieciet kopā ar mums). Å ie ir tikai Jenkins balstÄ«tu darbplÅ«smu piemēri. Strādājot ar citiem rÄ«kiem, ir daudz citu procesu.

Galvenais ir tas, ka mēs redzam, ka katrs atjauninājums beidzas ar izmaiņām konfigurācijas failos un Git krātuvēs. Šīs Git izmaiņas liek "GitOps operatoram" atjaunināt klasteru:

1. Darba process: "Dženkinsa būvē - meistara atzars'.
Uzdevumu saraksts:

  • Dženkinss nospiež atzÄ«mētos attēlus uz Quay;
  • Dženkinss nospiež konfigurācijas un Helm diagrammas uz galveno krātuves spaini;
  • Mākoņa funkcija kopē konfigurāciju un diagrammas no galvenās krātuves kausa uz galveno Git repozitoriju;
  • GitOps operators atjaunina klasteru.

2. Jenkins bÅ«vēt ā€” laidienu vai labojumfailu filiāle:

  • Dženkinss nospiež neatzÄ«mētus attēlus uz Quay;
  • Dženkinss nospiež konfigurācijas un Helm diagrammas uz inscenÄ“Å”anas krātuves spaini;
  • Mākoņa funkcija kopē konfigurāciju un diagrammas no pakāpeniskās krātuves kopas uz Git repozitoriju;
  • GitOps operators atjaunina klasteru.

3. Jenkins būvēt - attīstīt vai iezīme filiāle:

  • Dženkinss nospiež neatzÄ«mētus attēlus uz Quay;
  • Dženkinss iespiež konfigurācijas un Helm diagrammas izstrādes krātuves spainÄ«;
  • Mākoņa funkcija kopē konfigurāciju un diagrammas no izstrādes krātuves kausa uz izstrādes Git repozitoriju;
  • GitOps operators atjaunina klasteru.

4. Jauna klienta pievienoŔana:

  • Pārzinis vai administrators (LCM/ops) izsauc Gradle, lai sākotnēji izvietotu un konfigurētu tÄ«kla slodzes balansētājus (NLB);
  • LCM/ops veic jaunu konfigurāciju, lai sagatavotu izvietoÅ”anu atjauninājumiem;
  • GitOps operators atjaunina klasteru.

ÄŖss GitOps apraksts

  1. Aprakstiet visas sistēmas vēlamo stāvokli, izmantojot katras vides deklaratīvas specifikācijas (mūsu stāstā Boba komanda definē visu sistēmas konfigurāciju Git).
    • Git repozitorijs ir vienÄ«gais patiesÄ«bas avots par visas sistēmas vēlamo stāvokli.
    • Visas izmaiņas vēlamajā stāvoklÄ« tiek veiktas, izmantojot saistÄ«bas Git.
    • Visi vēlamie klastera parametri ir novērojami arÄ« paŔā klasterÄ«. Tādā veidā mēs varam noteikt, vai tie sakrÄ«t (saplÅ«st, saplÅ«st) vai atŔķirties (atŔķirties, atŔķirties) vēlamie un novērotie stāvokļi.
  2. Ja vēlamie un novērotie stāvokļi atŔķiras, tad:
    • Pastāv konverÄ£ences mehānisms, kas agrāk vai vēlāk automātiski sinhronizē mērÄ·a un novēroto stāvokļus. Klastera iekÅ”pusē Kubernetes to dara.
    • Process sākas nekavējoties ar brÄ«dinājumu par veiktajām izmaiņām.
    • Pēc kāda konfigurējama laika perioda var nosÅ«tÄ«t "atŔķirÄ«bas" brÄ«dinājumu, ja stāvokļi atŔķiras.
  3. Tādā veidā visas Git saistības rada pārbaudāmus un identiskus klastera atjauninājumus.
    • AtcelÅ”ana ir konverÄ£ence uz iepriekÅ” vēlamo stāvokli.
  4. Konverģence ir galīga. Tās raŔanos norāda:
    • Noteiktu laika periodu nav brÄ«dinājumu par atŔķirÄ«bām.
    • "konverģēts" brÄ«dinājums (piemēram, tÄ«mekļa aizÄ·ere, Git atrakstÄ«Å”anas notikums).

Kas ir diverģence?

Atkārtosim vēlreiz: visām vēlamajām klastera Ä«paŔībām jābÅ«t novērojamām paŔā klasterÄ«.

Daži atŔķirÄ«bu piemēri:

  • Izmaiņas konfigurācijas failā, jo Git tiek apvienotas filiāles.
  • Izmaiņas konfigurācijas failā GUI klienta veiktās Git saistÄ«bas dēļ.
  • Vairākas izmaiņas vēlamajā stāvoklÄ« saistÄ«bā ar PR pakalpojumā Git, kam seko konteinera attēla izveide un konfigurācijas izmaiņas.
  • Klastera stāvokļa izmaiņas kļūdas dēļ, resursu konflikts, kas izraisa "sliktu uzvedÄ«bu", vai vienkārÅ”i nejauÅ”a novirze no sākotnējā stāvokļa.

Kāds ir konverģences mehānisms?

Daži piemēri:

  • Konteineriem un klasteriem konverÄ£ences mehānismu nodroÅ”ina Kubernetes.
  • To paÅ”u mehānismu var izmantot, lai pārvaldÄ«tu uz Kubernetes balstÄ«tas lietojumprogrammas un dizainus (piemēram, Istio un Kubeflow).
  • Tiek nodroÅ”ināts mehānisms operatÄ«vās mijiedarbÄ«bas pārvaldÄ«Å”anai starp Kubernetes, attēlu krātuvēm un Git GitOps operators Weave Flux, kas ir daļa Aust Mākoni.
  • Bāzes maŔīnām konverÄ£ences mehānismam jābÅ«t deklaratÄ«vam un autonomam. No savas pieredzes mēs to varam teikt Terraform vistuvāk Å”ai definÄ«cijai, taču joprojām ir nepiecieÅ”ama cilvēka kontrole. Å ajā ziņā GitOps paplaÅ”ina infrastruktÅ«ras kā koda tradÄ«ciju.

GitOps apvieno Git ar lielisko Kubernetes konverÄ£ences dzinēju, lai nodroÅ”inātu ekspluatācijas modeli.

GitOps ļauj mums teikt: Automatizēt un kontrolēt var tikai tās sistēmas, kuras var aprakstīt un novērot.

GitOps ir paredzēts visam mākoņa steksam (piemēram, Terraform utt.)

GitOps nav tikai Kubernetes. Mēs vēlamies, lai visa sistēma tiktu vadÄ«ta deklaratÄ«vi un izmantotu konverÄ£enci. Ar visu sistēmu mēs domājam vidi kopumu, kas strādā ar Kubernetes - piemēram, ā€œdev cluster 1ā€, ā€œproductionā€ utt. Katrā vidē ietilpst maŔīnas, klasteri, lietojumprogrammas, kā arÄ« saskarnes ārējiem pakalpojumiem, kas nodroÅ”ina datus, uzraudzÄ«bu. un utt.

Ievērojiet, cik svarÄ«ga Terraform ir sāknÄ“Å”anas problēmai Å”ajā gadÄ«jumā. Kubernetes ir kaut kur jāizvieto, un, izmantojot Terraform, mēs varam lietot tās paÅ”as GitOps darbplÅ«smas, lai izveidotu kontroles slāni, kas ir Kubernetes un lietojumprogrammu pamatā. Å Ä« ir noderÄ«ga paraugprakse.

Liela uzmanÄ«ba tiek pievērsta GitOps koncepciju piemēroÅ”anai slāņiem virs Kubernetes. Å obrÄ«d ir GitOps tipa risinājumi Istio, Helm, Ksonnet, OpenFaaS un Kubeflow, kā arÄ«, piemēram, Pulumi, kas veido slāni mākoņu native aplikāciju izstrādei.

Kubernetes CI/CD: GitOps salīdzināŔana ar citām pieejām

Kā minēts, GitOps ir divas lietas:

  1. IepriekŔ aprakstītais Kubernetes un mākonis native darbības modelis.
  2. CeļŔ uz izstrādātāju orientētu lietojumprogrammu pārvaldÄ«bas vidi.

Daudziem GitOps galvenokārt ir darbplÅ«sma, kuras pamatā ir Git push. ViņŔ mums arÄ« patÄ«k. Bet tas vēl nav viss: tagad apskatÄ«sim CI/CD cauruļvadus.

GitOps nodroŔina nepārtrauktu Kubernetes izvietoŔanu (CD).

GitOps piedāvā nepārtrauktu izvietoÅ”anas mehānismu, kas novērÅ” vajadzÄ«bu pēc atseviŔķām "izvietoÅ”anas pārvaldÄ«bas sistēmām". Kubernetes dara visu darbu jÅ«su vietā.

  • Lai atjauninātu lietojumprogrammu, ir jāatjaunina Git. Å is ir darÄ«juma atjauninājums vēlamajam stāvoklim. Pēc tam "izvietoÅ”anu" klasterÄ« veic pati Kubernetes, pamatojoties uz atjaunināto aprakstu.
  • Kubernetes darbÄ«bas rakstura dēļ Å”ie atjauninājumi ir konverÄ£enti. Tas nodroÅ”ina nepārtrauktas izvietoÅ”anas mehānismu, kurā visi atjauninājumi ir kodolÄ«gi.
  • PiezÄ«me: Aust Mākoni piedāvā GitOps operatoru, kas integrē Git un Kubernetes un ļauj veikt CD, saskaņojot vēlamo un paÅ”reizējo klastera stāvokli.

Bez kubectl un skriptiem

Jums vajadzētu izvairÄ«ties no Kubectl izmantoÅ”anas, lai atjauninātu savu klasteru, un Ä«paÅ”i izvairÄ«ties no skriptu izmantoÅ”anas kubectl komandu grupÄ“Å”anai. Tā vietā, izmantojot GitOps cauruļvadu, lietotājs var atjaunināt savu Kubernetes klasteru, izmantojot Git.

Ieguvumi ietver:

  1. Pa labi. Atjauninājumu grupu var lietot, apvienot un beidzot apstiprināt, tādējādi tuvinot atomu izvietoÅ”anas mērÄ·i. Turpretim skriptu izmantoÅ”ana negarantē konverÄ£enci (vairāk par to tālāk).
  2. DroŔība. Citējot Kelsija Haitovere: ā€œIerobežojiet piekļuvi savam Kubernetes klasterim tikai automatizācijas rÄ«kiem un administratoriem, kuri ir atbildÄ«gi par tā atkļūdoÅ”anu vai uzturÄ“Å”anu.ā€ SkatÄ«t arÄ« mana publikācija par droŔību un atbilstÄ«bu tehniskajām specifikācijām, kā arÄ« raksts par uzlauÅ”anu Homebrew nozogot akreditācijas datus no neuzmanÄ«gi uzrakstÄ«ta Dženkinsa scenārija.
  3. Lietotāja pieredze. Kubectl atklāj Kubernetes objekta modeļa mehāniku, kas ir diezgan 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 Kelsiju un iesaku noskatÄ«ties tāds CV.

AtŔķirība starp CI un CD

GitOps uzlabo esoŔos CI/CD modeļus.

MÅ«sdienÄ«gs CI serveris ir orÄ·estrÄ“Å”anas rÄ«ks. Jo Ä«paÅ”i tas ir instruments CI cauruļvadu saskaņoÅ”anai. Tie ietver izveidi, testÄ“Å”anu, sapludināŔanu ar maÄ£istrāli utt. CI serveri automatizē sarežģītu daudzpakāpju cauruļvadu pārvaldÄ«bu. IzplatÄ«ts kārdinājums ir skriptēt Kubernetes atjauninājumu kopu un palaist to kā daļu no konveijera, lai veiktu izmaiņas klasterÄ«. PatieŔām, tā dara daudzi eksperti. Tomēr tas nav optimāli, un lÅ«k, kāpēc.

CI ir jāizmanto, lai nosÅ«tÄ«tu atjauninājumus uz maÄ£istrāli, un Kubernetes klasterim ir jāmainās, pamatojoties uz Å”iem atjauninājumiem, lai pārvaldÄ«tu kompaktdisku iekŔēji. Mēs to saucam pull modelis CD, atŔķirÄ«bā no CI push modeļa. CD ir daļa izpildlaika orÄ·estrÄ“Å”ana.

Kāpēc CI serveriem nevajadzētu izmantot kompaktdiskus, izmantojot tieÅ”us atjauninājumus pakalpojumā Kubernetes

Neizmantojiet CI serveri, lai organizētu tieÅ”us Kubernetes atjauninājumus kā CI darbu kopu. Å is ir anti-modelis, par kuru mēs runājam jau stāstÄ«ts savā emuārā.

Atgriezīsimies pie Alises un Boba.

Ar kādām problēmām viņi saskārās? Boba CI serveris piemēro izmaiņas klasterim, taču, ja tas Å”ajā procesā avarē, Bobs nezinās, kādā stāvoklÄ« klasteris atrodas (vai tam vajadzētu bÅ«t) vai kā to labot. Tas pats attiecas uz panākumiem.

Pieņemsim, ka Boba komanda izveidoja jaunu attēlu un pēc tam laboja savus izvietojumus, lai izvietotu attēlu (viss no CI konveijera).

Ja attēls tiek veidots normāli, bet cauruļvads neizdodas, komandai būs jāizdomā:

  • Vai atjauninājums ir izlaists?
  • Vai mēs uzsākam jaunu bÅ«vniecÄ«bu? Vai tas radÄ«s nevajadzÄ«gas blakusparādÄ«bas ā€” ar iespēju izveidot divas viena un tā paÅ”a nemainÄ«ga attēla versijas?
  • Vai mums vajadzētu gaidÄ«t nākamo atjauninājumu, pirms palaist bÅ«vējumu?
  • Kas tieÅ”i nogāja greizi? Kuras darbÄ«bas ir jāatkārto (un kuras ir droÅ”i atkārtot)?

Uz Git balstÄ«tas darbplÅ«smas izveide negarantē, ka Boba komanda nesaskarsies ar Ŕīm problēmām. Viņi joprojām var kļūdÄ«ties ar commit push, tagu vai kādu citu parametru; tomēr Ŕī pieeja joprojām ir daudz tuvāka skaidrai pieejai "visu vai neko".

Rezumējot, lūk, kāpēc CI serveriem nevajadzētu nodarboties ar CD:

  • AtjaunināŔanas skripti ne vienmēr ir deterministiski; Tajos ir viegli kļūdÄ«ties.
  • CI serveri nekonverģē uz deklaratÄ«vo klasteru modeli.
  • Ir grÅ«ti garantēt idempotenci. Lietotājiem ir jāsaprot sistēmas dziļā semantika.
  • Ir grÅ«tāk atgÅ«ties no daļējas neveiksmes.

PiezÄ«me par Helm: ja vēlaties izmantot Helm, mēs iesakām to apvienot ar GitOps operatoru, piemēram, Flux-StÅ«re. Tas palÄ«dzēs nodroÅ”ināt konverÄ£enci. Pati Helma nav ne deterministiska, ne atomiska.

GitOps kā labākais veids, kā ieviest nepārtrauktu piegādi Kubernetes

Alises un Boba komanda ievieÅ” GitOps un atklāj, ka ir kļuvis daudz vieglāk strādāt ar programmatÅ«ras produktiem, uzturēt augstu veiktspēju un stabilitāti. Beigsim Å”o rakstu ar ilustrāciju, kas parāda, kā izskatās viņu jaunā pieeja. Ņemiet vērā, ka mēs galvenokārt runājam par lietojumprogrammām un pakalpojumiem, taču GitOps var izmantot visas platformas pārvaldÄ«bai.

Kubernetes darbības modelis

Apskatiet tālāk redzamo diagrammu. Tas parāda Git un konteinera attēlu repozitoriju kā kopīgus resursus diviem organizētiem dzīves cikliem:

  • Nepārtraukts integrācijas cauruļvads, kas nolasa un ieraksta failus Git un var atjaunināt konteinera attēlu krātuvi.
  • Runtime GitOps konveijera, kas apvieno izvietoÅ”anu ar pārvaldÄ«bu un novērojamÄ«bu. Tas lasa un raksta failus Git un var lejupielādēt konteinera attēlus.

Kādi ir galvenie atklājumi?

  1. Bažu noŔķirÅ”ana: LÅ«dzu, ņemiet vērā, ka abi konveijeri var sazināties, tikai atjauninot Git vai attēlu repozitoriju. Citiem vārdiem sakot, starp CI un izpildlaika vidi ir ugunsmÅ«ris. Mēs to saucam par "nemainÄ«bas ugunsmÅ«ri" (nemaināmÄ«bas ugunsmÅ«ris), jo visi repozitorija atjauninājumi rada jaunas versijas. Papildinformāciju par Å”o tēmu skatiet 72.ā€“87. slaidos Ŕī prezentācija.
  2. Varat izmantot jebkuru CI un Git serveri: GitOps darbojas ar jebkuru komponentu. Varat turpināt izmantot savus iecienÄ«tākos CI un Git serverus, attēlu krātuves un testa komplektus. GandrÄ«z visiem citiem nepārtrauktās piegādes rÄ«kiem tirgÅ« ir nepiecieÅ”ams savs CI/Git serveris vai attēlu krātuve. Tas var kļūt par ierobežojoÅ”u faktoru mākoņdatoÅ”anas native attÄ«stÄ«bā. Izmantojot GitOps, varat izmantot pazÄ«stamus rÄ«kus.
  3. Pasākumi kā integrācijas rÄ«ks: TiklÄ«dz dati pakalpojumā Git tiek atjaunināti, Weave Flux (vai Weave Cloud operators) paziņo izpildlaiku. Ikreiz, kad Kubernetes pieņem izmaiņu kopu, Git tiek atjaunināts. Tas nodroÅ”ina vienkārÅ”u integrācijas modeli GitOps darbplÅ«smu organizÄ“Å”anai, kā parādÄ«ts tālāk.

Secinājums

GitOps nodroÅ”ina spēcÄ«gas atjaunināŔanas garantijas, kas nepiecieÅ”amas jebkuram modernam CI/CD rÄ«kam:

  • automatizācija;
  • konverÄ£ence;
  • idempotence;
  • determinisms.

Tas ir svarÄ«gi, jo tas piedāvā darbÄ«bas modeli mākoņdatoÅ”anas izstrādātājiem.

  • Tradicionālie sistēmu pārvaldÄ«bas un uzraudzÄ«bas rÄ«ki ir saistÄ«ti ar operāciju komandām, kas darbojas izpildgrāmatā (parasto procedÅ«ru un darbÄ«bu kopums - apm. tulk.), kas saistÄ«ts ar konkrētu izvietoÅ”anu.
  • Vietējā mākoņa pārvaldÄ«bā novērojamÄ«bas rÄ«ki ir labākais veids, kā izmērÄ«t izvietoÅ”anas rezultātus, lai izstrādātāju komanda varētu ātri reaģēt.

Iedomājieties, ka daudzas kopas ir izkaisÄ«tas dažādos mākoņos un daudzi pakalpojumi ar savām komandām un izvietoÅ”anas plāniem. GitOps piedāvā mēroga invariantu modeli, lai pārvaldÄ«tu visu Å”o pārpilnÄ«bu.

PS no tulka

Lasi arī mūsu emuārā:

Aptaujā var piedalīties tikai reģistrēti lietotāji. Ielogoties, lūdzu.

Vai jÅ«s zinājāt par GitOps, pirms Å”ie divi tulkojumi parādÄ«jās HabrĆ©?

  • Jā, es zināju visu

  • Tikai virspusēji

  • Nē

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

Avots: www.habr.com

Pievieno komentāru