ProHoster > Blog > Administrim > ÇfarĂ« Ă«shtĂ« GitOps?

ÇfarĂ« Ă«shtĂ« GitOps?

ShĂ«n. pĂ«rkth.: Pas publikimit tĂ« fundit materialit pĂ«r metodat pull dhe push nĂ« GitOps, ne vĂ«mĂ« re njĂ« interes pĂ«r kĂ«tĂ« model nĂ« pĂ«rgjithĂ«si, megjithatĂ«, publikimet nĂ« gjuhĂ«n ruse mbi kĂ«tĂ« temĂ« ishin shumĂ« tĂ« pakta (nĂ« Habra thjesht nuk kishte asnjĂ«). Prandaj, jemi tĂ« gĂ«zuar t'ju ofrojmĂ« pĂ«rkthimin e njĂ« artikulli tjetĂ«r — ndonĂ«se tashmĂ« pothuajse njĂ« vit i vjetĂ«r! — nga kompania Weaveworks, kreu i sĂ« cilĂ«s shpiku termin «GitOps». NĂ« tekst shpjegohet thelbi i qasjes dhe dallimet kryesore nga ato ekzistuese.

Një vit më parë ne publikoi një hyrje në GitOps. Atëherë ne treguam se si ekipi i Weaveworks lansoi një SaaS, tërësisht të ndërtuar mbi Kubernetes, dhe zhvilloi një set praktikash më të mira për implementimin, menaxhimin dhe monitorimin në një mjedis cloud native.

Artikulli u bë popullor. Të tjerë filluan të flasin për GitOps, të publikojnë mjete të reja për git push, zhvillimin, e sekretëve, funksione, integrimit të vazhdueshëm etj. Në faqen tonë u shfaq një numër i madh publikimesh dhe rasteve të përdorimit të GitOps. Por disa njerëz vazhdojnë të kenë pyetje. Si ndryshon modeli nga infrastruktura tradicionale si kod infrastructure as code dhe dorëzimi i vazhdueshëm (continuous delivery)? A është e domosdoshme të përdorim Kubernetes?

Së shpejti ne kuptuam se nevojitet një përshkrim i ri, që ofron:

  1. Një numër të madh shembujsh dhe historish;
  2. Një definicion të saktë të GitOps;
  3. Krahasimi me dorëzimin tradicional të vazhdueshëm.

Në këtë artikull ne përpiqemi të mbulojmë të gjitha këto tema. Në të do të gjeni një hyrje të përditësuar në GitOps dhe një rreze për të nga perspektiva e zhvilluesve dhe CI/CD. Ne jemi kryesisht të orientuar drejt Kubernetes, megjithatë, modeli padyshim që mund të përhapet.

Njoftohuni: GitOps

Imagjinoni Alice. Ajo menaxhon kompaninë Family Insurance, e cila ofron politika për sigurimin e shëndetit, automjeteve, pronave dhe sigurim udhëtimi për ata që janë shumë të zënë për të u marrë me hollësitë e kontratave vetë. Biznesi i saj nisi si një projekt anësor, kur Alice punonte në një bankë si data scientist. Një ditë ajo e kuptoi se mund të përdorë algoritme kompjuterike të avancuara për një analizë më efektive të të dhënave dhe për formimin e pakove të sigurimit. Investitorët financuan projektin, dhe tani kompania e saj gjeneron më shumë se 20 milion dollarë në vit dhe po rritet me shpejtësi. Aktualisht, në të punojnë 180 persona në pozita të ndryshme. Në mesin e tyre është ekipi teknologjik, i cili merret me zhvillimin, mirëmbajtjen e uebsajtit, bazës së të dhënave dhe analizën e bazës së klientëve. Ekipa prej 60 personash udhëhiqet nga Bob - drejtor teknologjik i kompanisë.

Ekipa e Bobit po zbaton sistemet production në cloud. Aplikacionet e tyre kryesore funksionojnë në GKE, duke përfituar nga avantazhet e Kubernetes në Google Cloud. Për më tepër, ata përdorin një sërë mjetesh për punë me të dhënat dhe analitikë.

Family Insurance nuk kishte planifikuar të përdorte kontejnerët, por u infektua nga entuziazmi për Docker. Së shpejti specialistët e kompanisë zbuluan se GKE lejonte që të vendosnin klasterë për testimin e funksionaliteteve të reja lehtësisht dhe pa mundim. U shtuan Jenkins për CI dhe Quay për organizimin e regjistrit të kontejnerëve, dhe u shkruan skriptet për Jenkins, të cilat dërgonin kontejnerët dhe konfigurimet e reja në GKE.

Ka kaluar një kohë. Alisa dhe Bobi ishin zhgënjyer nga performanca e qasjes së zgjedhur dhe ndikimi i saj në biznes. Zbatimi i kontejnerëve nuk e përmirësoi performancën aq sa ndjente ekipi. Ndonjëherë, deploymet prisnin dhe nuk ishte e qartë nëse fajin e kishte ndryshimi i kodit. Po ashtu, ishte e vështirë të ndjekeshin ndryshimet e konfigurations. Shpesh ishin të detyruar të krijonin një grup të ri dhe të zhvendosnin aplikacionet në të, pasi ishte më e thjeshtë të likuidohej ai kaos në të cilin kishte përfunduar sistemi. Alisa kishte frikë se situata do të përkeqësohej me zhvillimin e aplikacionit (për më tepër, një projekt i ri po afrohej që kishte lidhje me mësimin automatike). Bobi kishte automatizuar pjesën më të madhe të punës dhe nuk e kuptonte pse pipeline-i ende ishte i paqëndrueshëm, i papërshtatshëm dhe herë pas here kërkonte ndërhyrje manuale?

Më pas ata morën vesh për GitOps. Ky zgjidhje doli të ishte pikërisht ajo që u duhej për të ecur përpara me besim.

Alisa dhe Bobi kishin dĂ«gjuar pĂ«r vite tĂ« tĂ«ra pĂ«r proceset e bazuara nĂ« Git, DevOps dhe infrastruktura si kod. UnikĂ«sia e GitOps qĂ«ndron nĂ« faktin se ai sjell njĂ« sĂ«rĂ« praktikash mĂ« tĂ« mira — kategorike dhe rregullatore — pĂ«r realizimin e kĂ«tyre ideve nĂ« kontekstin e Kubernetes. Ky temĂ« ka ardhur shpesh nĂ« diskutim, pĂ«rfshirĂ« nĂ« blogun Weaveworks.

Familia Insurance po vendos të zbatojë GitOps. Tani kompania ka një model të automatizuar operativ që është në përputhje me Kubernetes dhe kombinon shpejtësinë për CustomResources; me qëndrueshmërinë, pasi ata:

  • zbuluan se produktiviteti i ekipit u dyfishua dhe askush nuk po çmendej;
  • ndaluan shĂ«rbimin e skripteve. NĂ« vend tĂ« kĂ«saj, ata tani mund tĂ« pĂ«rqendrohen nĂ« funksionalitete tĂ« reja dhe pĂ«rmirĂ«simin e metodave inxhinierike — pĂ«r shembull, tĂ« zbatojnĂ« lançimet kanarinĂ« dhe tĂ« pĂ«rmirĂ«sojnĂ« testimin;
  • pĂ«rmirĂ«suan procesin e deployment-it — tani ai rrallĂ« prishet;
  • morrĂ«n mundĂ«sinĂ« tĂ« rikuperonin deploymet pas dĂ«shtimeve pjesore pa ndihmĂ«n manuale;
  • fituan mĂ« shumĂ« besim nĂ« sistemet e dorĂ«zimit. Alisa dhe Bobi zbuluan se mund tĂ« ndanin ekipin nĂ« grupe qĂ« merreshin me mikrosherbime dhe punonin paralelisht;omund tĂ« bĂ«nin nga 30-50 ndryshime nĂ« projekt çdo ditĂ« pĂ«rmes pĂ«rpjekjeve tĂ« secilĂ«s grup dhe tĂ« provonin teknika tĂ« reja;
  • mund tĂ« bĂ«jnĂ« 30-50 ndryshime nĂ« projekt çdo ditĂ« nĂ«pĂ«rmjet pĂ«rpjekjeve tĂ« secilĂ«s grup dhe tĂ« provojnĂ« teknika tĂ« reja;
  • lehtĂ«sisht tĂ«rheqin zhvillues tĂ« rinj nĂ« projekt, tĂ« cilĂ«t kanĂ« mundĂ«sinĂ« tĂ« implementojnĂ« pĂ«rditĂ«sime nĂ« production pĂ«rmes pull request’ave brenda disa orĂ«sh;
  • lehtĂ«sisht kalojnĂ« auditorinĂ« nĂ« kuadĂ«r tĂ« SOC2 (nĂ« pĂ«rputhje me kĂ«rkesat e ofruesve tĂ« shĂ«rbimeve pĂ«r menaxhimin e sigurt tĂ« tĂ« dhĂ«nave; lexoni mĂ« shumĂ«, pĂ«r shembull, kĂ«tu — shĂ«n. pĂ«rkth.).

ÇfarĂ« ndodhi?

GitOps — kjo Ă«shtĂ« dy gjĂ«ra:

  1. Modeli i operimit për Kubernetes dhe cloud native. Ai ofron një grup praktikash më të mira për implementimin, menaxhimin dhe monitorimin e klasterëve dhe aplikacioneve të mbledhura në kontejnerë. Një përkufizim elegant në formën e një diapozitivi nga Luis Faceira:
  2. Rruga për krijimin e një ambienti të orientuar ndaj zhvilluesve për menaxhimin e aplikacioneve. Ne aplikojmë procesin e punës Git si për operimin ashtu edhe për zhvillimin. Vërejtje, kjo nuk është thjesht për Git push, por për organizimin e gjithë grupit të mjeteve CI/CD dhe UI/UX.

Një fjalë për Git

NĂ«se nuk jeni tĂ« njohur me sistemet e kontrollit tĂ« versioneve dhe procesin e punĂ«s tĂ« bazuar nĂ« Git, ne ju rekomandojmĂ« qĂ« ta studioni atĂ«. Fillimisht, puna me degĂ« dhe pull request’ave mund tĂ« duket si magji e zezĂ«, por pĂ«rfitimet e saj ia vlejnĂ« pĂ«rpjekjeve. Ja njĂ« artikull i shkĂ«lqyer pĂ«r tĂ« filluar.

Si funksionon Kubernetes

NĂ« historinĂ« tonĂ«, Alice dhe Bob iu drejtuan GitOps, pas njĂ« kohe tĂ« caktuar duke punuar me Kubernetes. Me tĂ« vĂ«rtetĂ«, GitOps Ă«shtĂ« ngushtĂ«sisht i lidhur me Kubernetes — kjo Ă«shtĂ« njĂ« model operimi pĂ«r infrastrukturĂ«n dhe aplikacionet e bazuara nĂ« Kubernetes.

ÇfarĂ« iu ofron Kubernetes pĂ«rdoruesve?

Ja disa nga funksionalitetet kryesore:

  1. Në modelin e Kubernetes, gjithçka mund të përshkruhet në mënyrë deklarative.
  2. API-server-i i Kubernetes pranon këtë deklaratë si të dhëna hyrëse, dhe më pas përpiqet vazhdimisht ta çojë klasterin në gjendjen e përshkruar në deklaratë.
  3. Deklaratat janĂ« tĂ« mjaftueshme pĂ«r tĂ« pĂ«rshkruar dhe menaxhuar njĂ« shumĂ«llojshmĂ«ri tĂ« madhe tĂ« ngarkesave tĂ« punĂ«s — 'aplikacioneve'.
  4. Si rezultat, ndryshimet në aplikacion dhe klaster ndodhin për shkak të:
    • ndryshimeve nĂ« imazhet e kontejnerĂ«ve;
    • ndryshimeve nĂ« specifikimin deklarativ;
    • gabimeve nĂ« mjedis — pĂ«r shembull, rĂ«nies sĂ« kontejnerĂ«ve.

Aftësitë e mrekullueshme të Kubernetes për konvergjencë

Kur një administrator bën ndryshime në konfigurim, orkestra Kubernetes do t'i aplikojë ato në klaster derisa gjendja e tij të afrohet me konfigurimin e ri.. Kjo model funksionon për çdo burim Kubernetes dhe zgjeron me anë të Custom Resource Definitions (CRDs). Prandaj, deployment-et e Kubernetes kanë këto veçori të mrekullueshme:

  • Automatizimi: azhurnimet e Kubernetes ofrojnĂ« njĂ« mekanizĂ«m pĂ«r automatizimin e proceseve tĂ« aplikimit tĂ« ndryshimeve nĂ« mĂ«nyrĂ« korrekte dhe nĂ« kohĂ«.
  • Konvergjenca: Kubernetes do tĂ« vazhdojĂ« tĂ« pĂ«rpiqet pĂ«r azhurnime deri sa tĂ« arrihet sukses.
  • Idempotenca: ripĂ« tĂ« aplikimet e konvergjencĂ«s çojnĂ« nĂ« tĂ« njĂ«jtin rezultat.
  • Determinizmi: me mjaft burime, gjendja e klasterit tĂ« azhurnuar varet vetĂ«m nga gjendja e dĂ«shiruar.

Si funksionon GitOps

Kemi mësuar mjaft rreth Kubernetes për të shpjeguar parimet e funksionimit të GitOps.

Le tĂ« kthehemi te ekipet e Family Insurance qĂ« lidhen me mikroshĂ«rbimet. ÇfarĂ« duhet tĂ« bĂ«jnĂ« ata zakonisht? Shihni listĂ«n mĂ« poshtĂ« (nĂ«se disa pika duken tĂ« çuditshme ose tĂ« panjohura, ju lutemi prisni me kritikĂ«n dhe qĂ«ndroni me ne). KĂ«to janĂ« thjesht shembuj tĂ« proceseve tĂ« punĂ«s nĂ« bazĂ« tĂ« Jenkins. Ka shumĂ« procese tĂ« tjera qĂ« lidhen me mjete tĂ« tjera.

Pika kryesore është se ne shohim që çdo azhurnim përfundohet me ndryshime në skedarët e konfigurimit dhe në repositorët Git. Këto ndryshime në Git bëjnë që 'operatori GitOps' të azhurnojë klasterin:

1. Procesi i punĂ«s: ‘NdĂ«rtojeni Jenkins - dega master».
Lista e detyrave:

  • Jenkins dĂ«rgon imazhet e etiketuar nĂ« Quay;
  • Jenkins dĂ«rgon konfigurimin dhe diagramet Helm nĂ« bucket-in master-storage;
  • Funksioni cloud kopjon konfigurimin dhe diagramet nga bucket-i master-storage nĂ« repositorin Git master;
  • Operatori GitOps azhurnon klasterin.

2. Ndërtojeni Jenkins - dega release ose hotfix:

  • Jenkins dĂ«rgon imazhet e paetiketuar nĂ« Quay;
  • Jenkins dĂ«rgon konfigurimin dhe diagramet Helm nĂ« bucket-in staging-storage;
  • Funksioni cloud kopjon konfigurimin dhe diagramet nga bucket-i staging-storage nĂ« repositorin Git staging;
  • Operatori GitOps azhurnon klasterin.

3. Ndërtojeni Jenkins - dega develop ose feature:

  • Jenkins dĂ«rgon imazhet e paetiketuar nĂ« Quay;
  • Jenkins dĂ«rgon konfigurimin dhe diagramet Helm nĂ« bucket-in develop-storage;
  • Funksioni cloud kopjon konfigurimin dhe diagramet nga bucket-i develop-storage nĂ« repositorin Git develop;
  • Operatori GitOps azhurnon klasterin.

4. Shtimi i klientit të ri:

  • Menaxheri ose administratori (LCM/ops) thĂ«rret Gradle pĂ«r pĂ«rgatitjen fillestare dhe konfigurimin e balancuesve tĂ« ngarkesĂ«s (NLB);
  • LCM/ops bĂ«n commit tĂ« konfigurimit tĂ« ri pĂ«r tĂ« pĂ«rgatitur deployment-in pĂ«r azhurnime;
  • Operatori GitOps azhurnon klasterin.

Përshkrimi i shkurtër i GitOps

  1. Përshkruani gjendjen e dëshiruar të gjithë sistemit duke përdorur specifikime deklarative për çdo mjedis (në historinë tonë, ekipi i Bobit definon tërë konfigurimin e sistemit në Git).
    • Repoja Git Ă«shtĂ« burimi i vetĂ«m i sĂ« vĂ«rtetĂ«s nĂ« lidhje me gjendjen e dĂ«shiruar tĂ« gjithĂ« sistemit.
    • TĂ« gjitha ndryshimet nĂ« gjendjen e dĂ«shiruar realizohen pĂ«rmes komiteteve nĂ« Git.
    • TĂ« gjitha parametrat e dĂ«shiruar tĂ« klasterit gjithashtu janĂ« tĂ« observable nĂ« vetĂ« klasterin. KĂ«shtu, ne mund tĂ« pĂ«rcaktojmĂ« nĂ«se (konvergojnĂ«, converge) ose dallojnĂ« (divergojnĂ«, diverge) gjendjet e dĂ«shiruara dhe tĂ« observable.
  2. Nëse gjendjet e dëshiruara dhe të observable dallojnë, atëherë:
    • Ekziston njĂ« mekanizĂ«m konvergjence, i cili do tĂ« sinkronizojĂ« automatikisht gjendjen e synuar dhe atĂ« tĂ« observable. Brenda klasterit, kĂ«tĂ« e bĂ«n Kubernetes.
    • Procesi aktivizohet menjĂ«herĂ« me njoftimin 'ndryshimi u konfirmua'.
    • PĂ«rmes njĂ« intervali tĂ« caktuar tĂ« cilin mund ta pĂ«rshtatni, mund tĂ« dĂ«rgohet njĂ« njoftim 'dallim' nĂ«se gjendjet dallojnĂ«.
  3. Kështu, të gjitha komitetet në Git shkaktojnë përditësime të verifikueshme dhe idempotente në klaster.
    • Rivendosja Ă«shtĂ« njĂ« konvergjencĂ« nĂ« njĂ« gjendje tĂ« dĂ«shiruar mĂ« parĂ«.
  4. Konvergjenca është përfundimtare. Shenja e saj është:
    • Mungesa e njoftimeve 'dallim' pĂ«r njĂ« periudhĂ« tĂ« caktuar kohore.
    • Njoftimi 'konverguar' (p.sh., webhook, ngjarje e shkruar nĂ« Git).

ÇfarĂ« Ă«shtĂ« divergjenca?

Të shqyrtojmë përsëri: të gjitha vetitë e dëshiruara të klasterit duhet të jenë observable në vetë klasterin..

Disa shembuj të divergjencës:

  • Ndryshimi nĂ« dosjen e konfigurimit pĂ«r shkak tĂ« bashkimit tĂ« degĂ«ve nĂ« Git.
  • Ndryshimi nĂ« dosjen e konfigurimit pĂ«r shkak tĂ« njĂ« komiti nĂ« Git, tĂ« bĂ«rĂ« nga njĂ« klient GUI.
  • Ndryshime tĂ« shumta nĂ« gjendjen e dĂ«shiruar pĂ«r shkak tĂ« PR nĂ« Git me ndihmĂ«n e ndĂ«rtimit tĂ« njĂ« imazhi kontejneri dhe ndryshimeve tĂ« konfigurimit.
  • Ndryshimi i gjendjes sĂ« klasterit pĂ«r shkak tĂ« njĂ« gabimi, konfliktit tĂ« burimeve qĂ« çon nĂ« 'sjellje tĂ« keqe', ose thjesht anashkalim i rastĂ«sishĂ«m nga gjendja origjinale.

ÇfarĂ« pĂ«rbĂ«n mekanizmi i konvergjencĂ«s?

Disa shembuj:

  • PĂ«r kontejnerĂ«t dhe klasterĂ«t, mekanizmi i konvergjencĂ«s ofrohet nga Kubernetes.
  • TĂ« njĂ«jtin mekanizĂ«m mund tĂ« pĂ«rdorim pĂ«r menaxhimin e aplikacioneve dhe ndĂ«rtimeve tĂ« bazuara nĂ« Kubernetes (p.sh., Istio dhe Kubeflow).
  • Mekanizmi pĂ«r menaxhimin e bashkĂ«punimit tĂ« punĂ«s ndĂ«rmjet Kubernetes, depove tĂ« imazheve dhe Git-it ofron Operatori GitOps Weave Flux, i cili Ă«shtĂ« njĂ« pjesĂ« e Weave Cloud.
  • PĂ«r makinat bazike, mekanizmi i konvergjencĂ«s duhet tĂ« jetĂ« deklarativ dhe autonom. Nga pĂ«rvoja jonĂ« mund tĂ« themi se Terraform Ă«shtĂ« mĂ« afĂ«r kĂ«tij pĂ«rkufizimi, megjithatĂ« ende kĂ«rkon kontroll nga njeriu. NĂ« kĂ«tĂ« kuptim, GitOps zgjeron traditat e InfrastrukturĂ«s si Kod.

GitOps bashkon Git me mekanizmin e shkëlqyer të konvergjencës së Kubernetes, duke ofruar një model për operacionin.

GitOps na lejon të deklarojmë: automatikës dhe kontrollit i nënshtrohen vetëm ato sisteme që mund të përshkruhen dhe të vëzhgohen.

GitOps është i dizajnuar për gjithë grumbullin cloud native (p.sh., Terraform, etj.)

GitOps — nuk Ă«shtĂ« vetĂ«m Kubernetes. Ne duam qĂ« e gjithĂ« sistemi tĂ« menaxhohet nĂ« mĂ«nyrĂ« deklarative dhe tĂ« pĂ«rdorĂ« konvergjencĂ«n. Nga e gjithĂ« sistemi kuptojmĂ« grupin e mjediseve qĂ« punojnĂ« me Kubernetes — pĂ«r shembull, 'dev cluster 1', 'produksioni' etj. NĂ« çdo mjedis pĂ«rfshihen makinat, klasterĂ«t, aplikacionet, si dhe ndĂ«rfaqet pĂ«r shĂ«rbime tĂ« jashtme qĂ« ofrojnĂ« tĂ« dhĂ«na, monitorim etj.

Vini re se sa e rëndësishme është Terraform për problemin e bootstrap-it. Kubernetes duhet të jetë i vendosur diku, dhe përdorimi i Terraform do të thotë se mund të aplikojmë të njëjtat procese pune GitOps për të krijuar shtresën menaxhuese që qëndron në themel të Kubernetes dhe aplikacioneve. Kjo është një praktikë e mirë.

Vlen të theksohet se po i jepet shumë rëndësi aplikimit të koncepteve GitOps në shtresat mbi Kubernetes. Deri tani, ekzistojnë zgjidhje të tipit GitOps për Istio, Helm, Ksonnet, OpenFaaS dhe Kubeflow, si dhe për Pulumi, që krijojnë një shtresë për zhvillimin e aplikacioneve për cloud native.

Kubernetes CI/CD: krahasimi i GitOps me qasje të tjera

Siç u tha, GitOps është dy gjëra:

  1. Një model operacional për Kubernetes dhe cloud native, siç u përmend më parë.
  2. Një rrugë drejt organizatës me orientim për zhvilluesit për menaxhimin e aplikacioneve.

Për shumë, GitOps është para së gjithësh një proces pune bazuar në git push. Ne gjithashtu e duam atë. Por nuk është e gjitha: le të shohim tani tubat CI/CD.

GitOps ofron implementim të vazhdueshëm (CD) për Kubernetes

GitOps ofron një mekanizëm për implementim të vazhdueshëm, duke eliminuar nevojën për 'sistemet e menaxhimit të implementimeve' të veçanta. Të gjithë punën e bën për ju Kubernetes.

  • PĂ«rditĂ«simi i aplikacionit kĂ«rkon njĂ« pĂ«rditĂ«sim nĂ« Git. Ky Ă«shtĂ« njĂ« pĂ«rditĂ«sim transaksional nĂ« gjendjen e dĂ«shiruar. "Zhvillimi" pastaj realizohet brenda klasterit nga Kubernetes bazuar nĂ« pĂ«rshkrimin e pĂ«rditĂ«suar.
  • PĂ«r shkak tĂ« specifikave tĂ« funksionimit tĂ« Kubernetes, kĂ«to pĂ«rditĂ«sime janĂ« konvergjente. Kjo siguron njĂ« mekanizĂ«m pĂ«r zhvillim tĂ« vazhdueshĂ«m, ku tĂ« gjitha pĂ«rditĂ«simet janĂ« atomike.
  • VĂ«rejtje: Weave Cloud ofron njĂ« operator GitOps, qĂ« integrohet me Git dhe Kubernetes dhe lejon realizimin e CD pĂ«rmes pajtimit tĂ« gjendjes sĂ« dĂ«shiruar dhe asaj aktuale tĂ« klasterit.

Pa kubectl dhe skripte

Duhet tĂ« shmanget pĂ«rdorimi i Kubectl pĂ«r tĂ« pĂ«rditĂ«suar klasterin, dhe veçanĂ«risht − skripte pĂ«r grupimin e komandave kubectl. NĂ« vend tĂ« kĂ«saj, pĂ«rmes njĂ« procesi GitOps, pĂ«rdoruesi mund tĂ« pĂ«rditĂ«sojĂ« klasterin e tij Kubernetes pĂ«rmes Git.

Avantazhet përfshijnë:

  1. Saktësia. Një grup përditësimesh mund të aplikohen, konvergjohen dhe në fund të vërtetohen, duke na afruar më afër qëllimit të zhvillimit atomik. Në të kundërt, përdorimi i skripteve nuk jep asnjë garanci konvergjence (më shumë për këtë më poshtë).
  2. Siguria. Duke cituar Kelsey Hightower: "Shfrytëzoni qasje në klasterin Kubernetes vetëm për mjete automatizimi dhe administratorë, të cilët kanë obligimin e diagnosticimit ose mbajtjes në punë të tij." Shih gjithashtu postimin tim për sigurinë dhe përputhshmërinë me specifikimet teknike, si dhe artikullin mbi sulmin në Homebrew nëpërmjet grabitjes së kredencialeve nga një skript Jenkins i përgatitur keq.
  3. Përvoja e përdoruesit. Kubectl zbulon mekanikën e modelit objekor të Kubernetes, i cili është mjaft kompleks. Idealisht, përdoruesit duhet të ndërveprojnë me sistemin në një nivel më të lartë të abstraksionit. Këtu do të citoj përsëri Kelsey dhe do të rekomandoj të shikoni një përmbledhje të tillë.

Dallimi mes CI dhe CD

GitOps përmirëson modelet ekzistuese CI/CD.

Një server modern CI është një mjet për orkestrimin. Në veçanti, është një mjet për orkestrimin e proceseve CI. Këto përfshijnë build, test, bashkimin me trunk dhe kështu me radhë. Serverët CI automatizojnë menaxhimin e proceseve të komplikuara me shumë hapa. Një tundim i zakonshëm është të krijosh një skript për një grup përditësimesh Kubernetes dhe ta ekzekutosh atë si një element të procesit për të pushuar ndryshimet në klaster. Realisht, kështu veprojnë shumë specialistë. Megjithatë, kjo nuk është optimale, dhe këtu është arsyeja pse.

CI duhet të përdoret për të bërë përditësime në trunk, dhe klusteri Kubernetes duhet të ndryshojë bazuar në këto përditësime, për të menaxhuar CD "brenda". Ne e quajmë këtë modelin pull për CD, në dallim nga modeli push i CI. CD është pjesë e orkestracionit runtime..

Pse CI-serverët nuk duhet të bëjnë CD përmes përditësimeve direkte në Kubernetes

Mos e përdorni CI-serverin për të orkestruar përditësime direkte në Kubernetes në formën e një sërëdetyrash CI. Ky është një anti-model, për të cilin ne më parë kemi folur në blogun tonë.

Le t'i kthehemi Alisës dhe Bobit.

Me çfarë probleme janë përballur ata? CI-serveri i Bobit aplikon ndryshimet në kluster, por nëse gjate procesit ai dështon, Bobi nuk do të dijë se në cilin gjendje është (ose duhet të jetë) klusteri dhe si ta rregullojë atë. E njëjta gjë vlen edhe në rastin e suksesit.

Le të supozojmë se ekipi i Bobit ka ndërtuar një imazh të ri dhe më pas ka përditësuar deployment-et e tyre për të vendosur imazhin (të gjitha këto nga pipeline-i i CI).

Nëse imazhi ndërtrohet normalisht, por pipeline-i dështon, ekipi do të duhet të zbulojë:

  • A Ă«shtĂ« vendosur pĂ«rditĂ«simi?
  • A po zbatojmĂ« njĂ« ndĂ«rtim tĂ« ri? A do tĂ« sjellĂ« kjo efekte anĂ«sore tĂ« padĂ«shiruara - me mundĂ«sinĂ« pĂ«r tĂ« marrĂ« dy ndĂ«rtime tĂ« njĂ«jti imazhi tĂ« pandryshuar?
  • A ja vlen tĂ« presim pĂ«r njĂ« ndĂ«rrim tjetĂ«r para se tĂ« zbatojmĂ« ndĂ«rtimin?
  • ÇfarĂ« saktĂ«sisht shkoi keq? Cilat hapa duhet tĂ« pĂ«rsĂ«riten (dhe cilat janĂ« tĂ« sigurta pĂ«r t'u pĂ«rsĂ«ritur)?

Organizimi i një procesi pune të bazuar në Git nuk garanton që ekipi i Bobit nuk do të hasë këto probleme. Ata akoma mund të bëjnë gabime me push-in e commit-it, me tag-un ose ndonjë parametr tjetër; megjithatë, ky qasje është ende shumë më afër një modeli të qartë të gjithçkaje ose asgjë.

Përmbledhur, ja pse CI-serverët nuk duhet të angazhohen në CD:

  • Skripti i pĂ«rditĂ«simeve nuk Ă«shtĂ« gjithmonĂ« i qartĂ«; Ă«shtĂ« e lehtĂ« tĂ« bĂ«hen gabime.
  • CI-serverĂ«t nuk konvergojnĂ« nĂ« modelin deklarativ tĂ« klusterit.
  • ËshtĂ« e vĂ«shtirĂ« tĂ« garantosh idempotencĂ«n. PĂ«rdoruesit duhet tĂ« kuptojnĂ« semantikĂ«n e thellĂ« tĂ« sistemit.
  • ËshtĂ« mĂ« e komplikuar tĂ« kryhet rikuperimi pas njĂ« dĂ«shtimi tĂ« pjesshĂ«m.

Shënim mbi Helm: nëse dëshiron të përdorësh Helm, ne rekomandojmë ta kombinosh atë me një operator GitOps, si Flux-Helm. Kjo do të ndihmojë në sigurimin e konvergjencës. Vetëm Helm nuk është as i qartë as atomik.

GitOps si mënyra më e mirë për të realizuar Continuous Delivery për Kubernetes.

Ekipi i Alice dhe Bob po implementon GitOps dhe vëren se është bërë shumë më e lehtë të punosh me produktet software, duke ruajtur një performancë dhe stabilitet të lartë. Le të përfundojmë këtë artikull me ilustrime që tregojnë se si duket qasja e tyre e re. Mbani në mend se ne po flasim kryesisht për aplikacione dhe shërbime, megjithatë GitOps mund të përdoret për menaxhimin e gjithë platformës.

Modeli i funksionimit për Kubernetes

Shikoni diagramin në vijim. Ai paraqet Git dhe depozitën e imazheve të kontejnerëve si burime të përbashkëta për dy ciklet e orkestruara të jetës:

  • Pipeline e integrimit tĂ« vazhdueshĂ«m, e cila lexon dhe shkruan skedarĂ« nĂ« Git dhe mund tĂ« pĂ«rditĂ«sojĂ« depozitĂ«n e imazheve tĂ« kontejnerĂ«ve.
  • Pipeline Runtime GitOps, i cili kombinon pĂ«rhapjen me menaxhimin dhe monitorimin. Ai lexon dhe shkruan skedarĂ« nĂ« Git dhe mund tĂ« ngarkojĂ« imazhe kontejnerĂ«sh.

Cilat janë përfundimet kryesore?

  1. Ndara e problemeve: Vëreni se të dyja pipeline-t mund të ndajnë të dhëna, vetëm duke përditësuar Git-a ose depozitën e imazheve. Me fjalë të tjera, ekziston një firewall midis CI dhe mjedisit runtime. Ne e quajmë atë "firewall të pandryshueshmërisë" (immutability firewall), pasi të gjitha përditësimet e depozitave krijojnë versione të reja. Për informacion të mëtejshëm mbi këtë temë, referohuni slides 72-87. këtë prezantim.
  2. Mund të përdorni çdo CI dhe server Git: GitOps punon me çdo komponent. Ju mund të vazhdoni të përdorni serverët tuaj të preferuar CI dhe Git, depozitë imazhesh dhe grupe testesh. Pothuajse të gjitha mjetet e tjera për Continuous Delivery në treg kërkojnë serverin e tyre CI/Git ose depozitën e imazheve. Kjo mund të bëhet një kufizim në zhvillimin cloud native. Në rastin e GitOps, ju mund të përdorni mjetet që jeni mësuar.
  3. Ngjarjet si një mjet integrimi: Sa herë që të dhënat në Git përditësohen, Weave Flux (ose operatori Weave Cloud) e informon runtime. Sa herë që Kubernetes merr një grup ndryshimesh, Git përditësohet. Kjo siguron një model të thjeshtë integrimi për organizimin e proceseve për GitOps, siç tregohet më poshtë.

PĂ«rfundim

GitOps ofron garanci të qëndrueshme për përditësim, të nevojshme për çdo mjet modern CI/CD:

  • automatikĂ«;
  • konvergjencĂ«;
  • idempotentĂ«si;
  • determinist.

Kjo është e rëndësishme, pasi ofron një model funksionimi për zhvilluesit në fushën cloud native.

  • Mjetet tradicionale pĂ«r menaxhimin dhe monitorimin e sistemeve janĂ« tĂ« lidhura me ekipet e operacioneve qĂ« veprojnĂ« brenda njĂ« runbook-u. (grup tĂ« procedurave dhe operacioneve rutinĂ« — shĂ«n. pĂ«rk.)., e lidhur me njĂ« deployment tĂ« caktuar.
  • NĂ« menaxhimin e sistemeve cloud native, mjetet pĂ«r vĂ«zhgim janĂ« mĂ«nyra mĂ« e mirĂ« pĂ«r tĂ« vlerĂ«suar rezultatet e implementimeve, nĂ« mĂ«nyrĂ« qĂ« ekipi i zhvilluesve tĂ« mund tĂ« reagojĂ« nĂ« kohĂ«.

Imagjinoni shumë klastera të shpërndara nëpër cloud-e të ndryshme dhe shumë shërbime me ekipet e tyre dhe planet e tyre të implementimit. GitOps ofron një model invariant të shkallëzueshëm për të menaxhuar gjithë këtë pasuri.

P.S. nga përkthyesi

Lexoni gjithashtu në blogun tonë:

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, ju lutem.

A e dinit për GitOps para se të dilnin këto dy përkthime në habr?

  • Po, e dija.

  • VetĂ«m sipĂ«rfaqĂ«sisht.

  • Jo

35 përdorues votuan. 10 përdorues u abstenuan.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster