ProHoster > Blogs > Administrācija > GitOps: vilkŔanas un stumŔanas metožu salīdzinājums

GitOps: vilkŔanas un stumŔanas metožu salīdzinājums

PiezÄ«me. tulk.: Kubernetes kopienā tendence, ko sauc par GitOps, gÅ«st acÄ«mredzamu popularitāti, kā mēs personÄ«gi esam redzējuÅ”i, apmeklējot KubeCon Europe 2019. Å is termins bija salÄ«dzinoÅ”i nesens izgudrots ko rakstÄ«jis Weaveworks vadÄ«tājs Aleksis Ričardsons, un tas nozÄ«mē izstrādātājiem pazÄ«stamu rÄ«ku (galvenokārt Git, no tā arÄ« nosaukums) izmantoÅ”anu, lai atrisinātu darbÄ«bas problēmas. Jo Ä«paÅ”i mēs runājam par Kubernetes darbÄ«bu, saglabājot tās konfigurācijas Git un automātiski ievieÅ”ot klastera izmaiņas. Å ajā rakstā Matiass Jg runā par divām pieejām Å”ai ievieÅ”anai.

GitOps: vilkŔanas un stumŔanas metožu salīdzinājums

PagājuÅ”ajā gadā, (patiesÄ«bā formāli tas notika 2017. gada augustā ā€” aptuveni tulk.) Ir jauna pieeja lietojumprogrammu izvietoÅ”anai Kubernetes. To sauc par GitOps, un tā pamatā ir pamatideja, ka izvietoÅ”anas versijas tiek izsekotas Git repozitorija droÅ”ajā vidē.

Šīs pieejas galvenās priekŔrocības ir Ŕādas::

  1. IzvietoÅ”anas versiju izveide un izmaiņu vēsture. Visa klastera stāvoklis tiek glabāts Git repozitorijā, un izvietojumi tiek atjaunināti tikai ar apņemÅ”anos. Turklāt visas izmaiņas var izsekot, izmantojot saistÄ«bu vēsturi.
  2. AtcelÅ”ana, izmantojot pazÄ«stamās Git komandas... VienkārÅ”s git reset ļauj atiestatÄ«t izmaiņas izvietojumos; pagātnes stāvokļi vienmēr ir pieejami.
  3. Gatavā piekļuves kontrole. Parasti Git sistēmā ir daudz sensitÄ«vu datu, tāpēc lielākā daļa uzņēmumu pievērÅ” Ä«paÅ”u uzmanÄ«bu to aizsardzÄ«bai. AttiecÄ«gi Ŕī aizsardzÄ«ba attiecas arÄ« uz operācijām ar izvietoÅ”anu.
  4. IzvietoÅ”anas politikas. Lielākā daļa Git sistēmu sākotnēji atbalsta politiku katrā nozarē ā€” piemēram, tikai piesaistes pieprasÄ«jumi var atjaunināt galveno, un izmaiņas ir jāpārskata un jāpieņem citam komandas dalÄ«bniekam. Tāpat kā piekļuves kontrolei, uz izvietoÅ”anas atjauninājumiem attiecas tās paÅ”as politikas.

Kā redzat, GitOps metodei ir daudz priekÅ”rocÄ«bu. Pēdējā gada laikā Ä«paÅ”u popularitāti ieguvuÅ”as divas pieejas. Viens ir balstÄ«ts uz grÅ«dienu, otrs ir balstÄ«ts uz vilkÅ”anu. Pirms to aplÅ«koÅ”anas, vispirms apskatÄ«sim, kā izskatās tipiski Kubernetes izvietojumi.

IzvietoŔanas metodes

Pēdējos gados Kubernetes ir izveidojuŔās dažādas izvietoÅ”anas metodes un rÄ«ki:

  1. Pamatojoties uz vietējām Kubernetes/Kustomize veidnēm. Tas ir vienkārŔākais veids, kā Kubernetes izvietot lietojumprogrammas. Izstrādātājs izveido pamata YAML failus un lieto tos. Lai atbrÄ«votos no nepārtrauktas vienu un to paÅ”u veidņu pārrakstÄ«Å”anas, tika izstrādāta Kustomize (tas pārvērÅ” Kubernetes veidnes moduļos). PiezÄ«me. tulk.: Kustomize ir integrēta kubectl ar Kubernetes izlaidums 1.14.
  2. StÅ«res diagrammas. StÅ«res diagrammas ļauj izveidot veidņu kopas, init konteinerus, blakusvāģus utt., ko izmanto, lai izvietotu lietojumprogrammas ar elastÄ«gākām pielāgoÅ”anas opcijām nekā uz veidnēm balstÄ«tā pieejā. Å Ä«s metodes pamatā ir veidņu YAML faili. Helm aizpilda tos ar dažādiem parametriem un pēc tam nosÅ«ta tos Tiller ā€” klastera komponentam, kas tos izvieto klasterÄ« un ļauj veikt atjauninājumus un atcelÅ”anu. SvarÄ«gi ir tas, ka Helms bÅ«tÄ«bā tikai ievieto vēlamās vērtÄ«bas veidnēs un pēc tam piemēro tās tādā paŔā veidā, kā tas tiek darÄ«ts tradicionālajā pieejā. (lasiet vairāk par to, kā tas viss darbojas un kā varat to izmantot mÅ«su Helmas raksts ā€” apm. tulk.). Ir daudz dažādu gatavu Helm diagrammu, kas aptver plaÅ”u uzdevumu klāstu.
  3. AlternatÄ«vie rÄ«ki. Ir daudz alternatÄ«vu rÄ«ku. Viņiem visiem ir kopÄ«gs tas, ka tie pārvērÅ” dažus veidņu failus Kubernetes lasāmos YAML failos un pēc tam tos izmanto.

Savā darbā mēs pastāvÄ«gi izmantojam Helm diagrammas svarÄ«giem rÄ«kiem (jo tām jau ir gatavas daudzas lietas, kas padara dzÄ«vi daudz vieglāku) un ā€œtÄ«rosā€ Kubernetes YAML failus mÅ«su paÅ”u lietojumprogrammu izvietoÅ”anai.

Vilkt stumt

Vienā no saviem nesenajiem emuāra ierakstiem es iepazÄ«stināju ar Å”o rÄ«ku Weave Flux, kas ļauj ievietot veidnes Git repozitorijā un atjaunināt izvietoÅ”anu pēc katras konteinera apstiprināŔanas vai nospieÅ”anas. Mana pieredze liecina, ka Å”is rÄ«ks ir viens no galvenajiem pievilkÅ”anas pieejas veicināŔanā, tāpēc es uz to bieži atsaukÅ”os. Ja vēlaties uzzināt vairāk par to, kā to izmantot, skatiet Å”eit saite uz rakstu.

NB! Visas GitOps lietoŔanas priekŔrocības abām pieejām paliek nemainīgas.

UzvilkŔanas pieeja

GitOps: vilkŔanas un stumŔanas metožu salīdzinājums

VilkÅ”anas pieeja ir balstÄ«ta uz faktu, ka visas izmaiņas tiek piemērotas klasterÄ«. KlasterÄ« ir operators, kas regulāri pārbauda saistÄ«tos Git un Docker reÄ£istra repozitorijus. Ja tajās notiek kādas izmaiņas, klastera stāvoklis tiek atjaunināts iekŔēji. Å is process parasti tiek uzskatÄ«ts par ļoti droÅ”u, jo nevienam ārējam klientam nav piekļuves klastera administratora tiesÄ«bām.

Plusi:

  1. Nevienam ārējam klientam nav tiesÄ«bu veikt izmaiņas klasterÄ«; visi atjauninājumi tiek ieviesti no iekÅ”puses.
  2. Daži rīki ļauj arī sinhronizēt Helm diagrammas atjauninājumus un saistīt tos ar kopu.
  3. Docker Registry var skenēt, lai atrastu jaunas versijas. Ja ir pieejams jauns attēls, Git repozitorijs un izvietoÅ”ana tiek atjaunināti uz jauno versiju.
  4. IzvilkÅ”anas rÄ«kus var izplatÄ«t dažādās nosaukumu telpās ar dažādām Git krātuvēm un atļaujām. Pateicoties tam, var izmantot vairāku Ä«rnieku modeli. Piemēram, komanda A var izmantot nosaukumvietu A, komanda B var izmantot nosaukumvietu B, bet infrastruktÅ«ras komanda var izmantot globālo telpu.
  5. Kā likums, instrumenti ir ļoti viegli.
  6. Apvienojumā ar tādiem instrumentiem kā operators Bitnami aizzÄ«mogotie noslēpumi, noslēpumus var glabāt Å”ifrētus Git repozitorijā un izgÅ«t klasterÄ«.
  7. Nav savienojuma ar CD cauruļvadiem, jo ā€‹ā€‹izvietoÅ”ana notiek klasterÄ«.

MÄ«nusi:

  1. IzvietoÅ”anas noslēpumu pārvaldÄ«ba no Helm diagrammām ir grÅ«tāka nekā parastajām, jo ā€‹ā€‹tie vispirms ir jāģenerē, piemēram, aizzÄ«mogotu noslēpumu veidā, pēc tam tie jāatÅ”ifrē iekŔējam operatoram, un tikai pēc tam tie kļūst pieejami vilkÅ”anas rÄ«kam. Pēc tam varat palaist laidienu Helmā ar vērtÄ«bām jau izvietotajos noslēpumos. VienkārŔākais veids ir izveidot noslēpumu ar visām izvietoÅ”anai izmantotajām Helm vērtÄ«bām, atÅ”ifrēt to un nodot Git.
  2. Izmantojot vilkÅ”anas pieeju, jÅ«s kļūstat piesaistÄ«ts vilkÅ”anas instrumentiem. Tas ierobežo iespēju pielāgot izvietoÅ”anas procesu klasterÄ«. Piemēram, Kustomize sarežģī fakts, ka tai ir jāpalaiž, pirms pēdējās veidnes tiek nodotas Git. Es nesaku, ka nevar izmantot atseviŔķus rÄ«kus, taču tos ir grÅ«tāk integrēt izvietoÅ”anas procesā.

UzspieŔanas pieeja

GitOps: vilkŔanas un stumŔanas metožu salīdzinājums

Izmantojot push pieeju, ārēja sistēma (galvenokārt CD konveijeri) uzsāk izvietoÅ”anu klasterÄ« pēc Git repozitorija saistÄ«bu izpildes vai ja iepriekŔējais CI konveijers ir veiksmÄ«gs. Å ajā pieejā sistēmai ir piekļuve klasterim.

Plusi:

  1. DroŔību nosaka Git repozitorijs un bÅ«vÄ“Å”anas cauruļvads.
  2. Helm diagrammu izvietoÅ”ana ir vienkārŔāka un atbalsta Helm spraudņus.
  3. Noslēpumus ir vieglāk pārvaldÄ«t, jo noslēpumus var izmantot konveijeros, un tos var arÄ« glabāt Å”ifrētā veidā Git (atkarÄ«bā no lietotāja vēlmēm).
  4. Nav savienojuma ar konkrētu rīku, jo var izmantot jebkura veida.
  5. Konteinera versijas atjauninājumus var uzsākt bÅ«vÄ“Å”anas konveijerā.

MÄ«nusi:

  1. Klastera piekļuves dati atrodas bÅ«vÄ“Å”anas sistēmā.
  2. IzvietoŔanas konteineru atjaunināŔana joprojām ir vienkārŔāka, izmantojot vilkŔanas procesu.
  3. Liela atkarÄ«ba no kompaktdisku sistēmas, jo mums nepiecieÅ”amie cauruļvadi, iespējams, sākotnēji tika rakstÄ«ti Gitlab Runners, un pēc tam komanda nolemj pāriet uz Azure DevOps vai Jenkins... un tai bÅ«s jāmigrē liels skaits bÅ«vniecÄ«bas cauruļvadu.

Rezultāti: stumt vai vilkt?

Kā parasti, katrai pieejai ir savi plusi un mÄ«nusi. Dažus uzdevumus ir vieglāk paveikt ar vienu un grÅ«tāk ar citu. Sākumā es veicu izvietoÅ”anu manuāli, bet pēc tam, kad atradu dažus rakstus par Weave Flux, es nolēmu ieviest GitOps procesus visiem projektiem. Pamata veidnēm tas bija vienkārÅ”i, bet tad man radās grÅ«tÄ«bas ar Helm diagrammām. Tolaik Weave Flux piedāvāja tikai elementāru Helm Chart Operator versiju, taču pat tagad daži uzdevumi ir grÅ«tāki, jo ir nepiecieÅ”ams manuāli izveidot noslēpumus un tos lietot. JÅ«s varētu iebilst, ka vilkÅ”anas pieeja ir daudz droŔāka, jo klastera akreditācijas dati nav pieejami ārpus klastera, padarot to tik daudz droŔāku, ka ir vērts pielikt papildu pÅ«les.

Nedaudz pārdomājot, es nonācu pie negaidÄ«ta secinājuma, ka tas tā nav. Ja mēs runājam par komponentiem, kuriem nepiecieÅ”ama maksimāla aizsardzÄ«ba, Å”ajā sarakstā bÅ«s iekļauta slepenā krātuve, CI/CD sistēmas un Git krātuves. Tajos esoŔā informācija ir ļoti neaizsargāta, un tai nepiecieÅ”ama maksimāla aizsardzÄ«ba. Turklāt, ja kāds nokļūst jÅ«su Git repozitorijā un var tur nosÅ«tÄ«t kodu, viņŔ var izvietot visu, ko vēlas (neatkarÄ«gi no tā, vai tas ir pull vai push) un iefiltrēties klastera sistēmās. Tādējādi vissvarÄ«gākie komponenti, kas ir jāaizsargā, ir Git repozitorijs un CI/CD sistēmas, nevis klastera akreditācijas dati. Ja jums ir labi konfigurētas politikas un droŔības vadÄ«klas Ŕāda veida sistēmām un klasteru akreditācijas dati tiek iegÅ«ti tikai konveijeros kā noslēpumi, papildu droŔība, ko nodroÅ”ina vilkÅ”anas pieeja, var nebÅ«t tik vērtÄ«ga, kā sākotnēji tika uzskatÄ«ts.

Tātad, ja vilkÅ”anas pieeja ir darbietilpÄ«gāka un nesniedz droŔības priekÅ”rocÄ«bas, vai nav loÄ£iski izmantot tikai push pieeju? Bet kāds varētu iebilst, ka push pieejā jÅ«s esat pārāk piesaistÄ«ts CD sistēmai, un, iespējams, labāk to nedarÄ«t, lai nākotnē bÅ«tu vieglāk veikt migrāciju.

Manuprāt (kā vienmēr) jāizmanto tas, kas ir vispiemērotākais konkrētajam gadÄ«jumam vai kombainam. PersonÄ«gi es izmantoju abas pieejas: Weave Flux izvietoÅ”anai, kas balstÄ«ta uz piesaisti, kas galvenokārt ietver mÅ«su paÅ”u pakalpojumus, un push pieeju ar Helm un spraudņiem, kas atvieglo Helm diagrammu lietoÅ”anu klasterÄ« un ļauj nemanāmi izveidot noslēpumus. Domāju, ka nekad nebÅ«s viena visiem gadÄ«jumiem piemērota risinājuma, jo vienmēr ir daudz nianses un tās ir atkarÄ«gas no konkrētā pielietojuma. To sakot, es ļoti iesaku GitOps ā€” tas ievērojami atvieglo dzÄ«vi un uzlabo droŔību.

Es ceru, ka mana pieredze par Å”o tēmu palÄ«dzēs jums izlemt, kura metode ir piemērotāka jÅ«su izvietoÅ”anas veidam, un es priecāŔos dzirdēt jÅ«su viedokli.

PS Tulkotāja piezīme

IevilkÅ”anas modeļa negatÄ«vie aspekti ir tādi, ka ir grÅ«ti ievietot Git atveidotos manifestus, taču nav negatÄ«va, ka CD konveijera izvilkÅ”anas modelÄ« darbojas atseviŔķi no izlaiÅ”anas un bÅ«tÄ«bā kļūst par kategorijas konveijeru. Nepārtraukta pieteikÅ”anās. Tāpēc bÅ«s jāpieliek vēl lielākas pÅ«les, lai apkopotu to statusu no visām izvietoÅ”anām un kaut kādā veidā nodroÅ”inātu piekļuvi žurnāliem/statusiem, vēlams, atsaucoties uz CD sistēmu.

Å ajā ziņā push modelis ļauj mums nodroÅ”ināt vismaz dažas izvērÅ”anas garantijas, jo cauruļvada kalpoÅ”anas laiku var pielÄ«dzināt izvērÅ”anas kalpoÅ”anas laikam.

Izmēģinājām abus modeļus un nonācām pie tādiem paÅ”iem secinājumiem kā raksta autors:

  1. VilkÅ”anas modelis ir piemērots, lai organizētu sistēmas komponentu atjauninājumus daudzos klasteros (sk. raksts par papildinājumu operatoru).
  2. Push modelis, kura pamatā ir GitLab CI, ir labi piemērots lietojumprogrammu izvērÅ”anai, izmantojot Helm diagrammas. Tajā paŔā laikā, izmantojot rÄ«ku, tiek uzraudzÄ«ta izvietoÅ”anas izvērÅ”ana cauruļvados werf. Starp citu, Ŕī mÅ«su projekta kontekstā mēs dzirdējām pastāvÄ«go ā€œGitOpsā€, kad savā stendā KubeCon Europe'19 apspriedām DevOps inženieru aktuālās problēmas.

PPS no tulka

Lasi arī mūsu emuārā:

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

Vai jūs izmantojat GitOps?

  • Jā, velciet pieeja

  • Jā, spiediet

  • Jā, velciet + spiediet

  • Jā, kaut kas cits

  • Nē

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

Avots: www.habr.com

Pievieno komentāru