GitOps çi ye?

Not. werger.: Piştî weşaneke dawî materyal di derbarê awayên kişandin û pêxistinê de di GitOps de, me eleqeya vê modelê bi gelemperî dît, lê li ser vê mijarê weşanên bi zimanê rûsî pir hindik bûn (li ser Habré bi tenê tune). Ji ber vê yekê, em kêfxweş in ku wergerek gotarek din pêşkêşî we dikin - her çend hema salek berê! - ji Weaveworks, serê ku têgeha "GitOps" çêkir. Metn cewherê nêzîkbûnê û cûdahiyên sereke ji yên heyî rave dike.

Salek berê me çap kir danasîna GitOps. Dûv re, me parve kir ku tîmê Weaveworks çawa SaaSek bi tevahî li ser Kubernetes-ê bingeha xwe da destpêkirin û komek pratîkên çêtirîn pêşniyarî ji bo bicihkirin, rêvebirin û çavdêrîkirina li hawîrdorek xwecî ya ewr pêşxist.

Gotar derket ku populer bû. Kesên din dest bi axaftinê li ser GitOps kirin û dest bi weşandina amûrên nû kirin git push, pêşveçûnî, veşartî, karûbaran, entegrasyona berdewam wate ya vê çîye. Di malpera me de xuya bû hejmareke mezin ji weşan û dozên karanîna GitOps. Lê hin kes hîn jî pirs hene. Çawa modela ji ya kevneşopî cuda ye? binesazî wekî kod û şandina berdewam (radestkirina domdar)? Ma hewce ye ku Kubernetes bikar bînin?

Me zû fêm kir ku ravekirinek nû hewce ye, ku pêşkêşî dike:

  1. Hejmarek mezin ji mînak û çîrokan;
  2. Pênaseya taybetî ya GitOps;
  3. Bi radestkirina domdar a kevneşopî re berhev bikin.

Di vê gotarê de me hewl da ku van hemî mijaran veşêre. Ew danasînek nûvekirî ya GitOps û pêşdebir û perspektîfek CI/CD peyda dike. Em di serî de balê dikişînin ser Kubernetes, her çend model dikare were gelemperî kirin.

Bi GitOps re hevdîtin bikin

Bifikirin Alice. Ew Bîmeya Malbatê dimeşîne, ku bîmeya tenduristî, oto, mal, û rêwîtiyê pêşkêşî mirovên ku pir mijûl in ku bi xwe guheztinên peymanan fam bikin. Karsaziya wê wekî projeyek alî dest pê kir dema ku Alice li bankek wekî zanyarek daneyê dixebitî. Rojekê wê fêm kir ku ew dikare algorîtmayên pêşkeftî yên komputerê bikar bîne da ku daneyan bi bandortir analîz bike û pakêtên bîmeyê formule bike. Veberhêneran proje fînanse kir, û naha pargîdaniya wê salê zêdetirî 20 mîlyon dolar qezenc dike û bi lez mezin dibe. Niha 180 kes di cihên cuda de kar dikin. Ev yek tîmek teknolojiyê ya ku malper, databasê pêş dixe, diparêze, û bingeha xerîdar analîz dike. Tîma ji 60 kesan pêk tê ji aliyê rêvebirê teknîkî yê şirketê Bob ve tê birêvebirin.

Tîma Bob pergalên hilberînê di ewr de bi cih dike. Serlêdanên wan ên bingehîn li ser GKE-yê dimeşînin, ku ji Kubernetes li Google Cloud sûd werdigirin. Wekî din, ew di xebata xwe de amûrên cûrbecûr dane û analîtîk bikar tînin.

Bîmeya Malbatê dest pê nekir ku konteyneran bikar bîne, lê ket nav dilşewatiya Docker. Pargîdanî zû kifş kir ku GKE ji bo ceribandina taybetmendiyên nû sazkirina koman hêsan kir. Jenkins ji bo CI û Quay hatin zêdekirin da ku tomara konteynerê birêxistin bikin, ji bo Jenkins senaryo hatin nivîsandin ku konteynir û mîhengên nû ber bi GKE ve dikişand.

Demek derbas bû. Alice û Bob ji performansa nêzîkatiya xwe ya bijartî û bandora wê ya li ser karsaziyê xemgîn bûn. Danasîna konteyneran bi qasî ku tîmê hêvî dikir hilberîneriyê baştir nekir. Carinan veqetandin têk diçû, û ne diyar bû ka guhertinên kodê sûcdar in. Di heman demê de derket holê ku şopandina guherînên mîhengê jî dijwar e. Bi gelemperî hewce bû ku komek nû were afirandin û serîlêdanan jê re were veguheztin, ji ber ku ev awayê herî hêsan bû ji bo rakirina tevliheviya ku pergalê bûye. Alice ditirsiya ku her ku serîlêdanê pêş ket dê rewş xirabtir bibe (digel vê yekê, projeyek nû ya li ser bingeha fêrbûna makîneyê çêdibe). Bob piraniya kar otomatîze kiribû û fêm nedikir çima boriyê hîn ne aram bû, baş pîvaz nedikir, û pêdivî bi destwerdana destanî bi periyodîk hebû?

Dûv re ew li ser GitOps fêr bûn. Ev biryar derket holê ku tam tiştê ku ji wan re hewce bû ku bi pêbawerî pêşde biçin.

Alice û Bob bi salan li ser Git, DevOps, û binesaziyê wekî tevgerên kodê dibihîzin. Tiştê ku di derbarê GitOps-ê de bêhempa ye ev e ku ew ji bo pêkanîna van ramanan di çarçoweya Kubernetes de komek pratîkên çêtirîn - hem teqez û hem jî normatîf- tîne. Ev mijar çend caran rabû, di nav de Weaveworks blog.

Bîmeya Malbatê biryar dide ku GitOps bicîh bîne. Pargîdanî nuha xwedan modelek xebitandinê ya otomatîk e ku bi Kubernetes re hevaheng e û berhev dike speed re nehejîji ber ku ew:

  • dît ku berhemdariya tîmê bêyî ku kes dîn bibe duqat bûye;
  • xizmeta senaryoyan rawestand. Di şûna wê de, ew naha dikarin bala xwe bidin ser taybetmendiyên nû û rêbazên endezyariyê baştir bikin - mînakî, danasîna kanaranan û başkirina ceribandinê;
  • me pêvajoya bicihkirinê baştir kiriye da ku ew kêm caran têk diçe;
  • firsend peyda kir ku piştî têkçûnên qismî bêyî destwerdana destan bicîhkirinan sererast bike;
  • kirîn bikaranînоBaweriya mezintir di pergalên radestkirinê de. Alice û Bob keşif kirin ku ew dikarin tîmê li tîmên mîkroxizmetê yên ku paralel dixebitin veqetînin;
  • dikare bi hewldanên her komê her roj 30-50 guhertinan li projeyê bike û teknîkên nû biceribîne;
  • hêsan e ku meriv pêşdebirên nû bikişîne ser projeyê, yên ku di nav çend demjimêran de xwedan fersendê ne ku nûvekirinên hilberînê bi karanîna daxwazên kişandinê derxînin;
  • di çarçoveya SOC2 de bi hêsanî kontrolê derbas bikin (ji bo lihevhatina pêşkêşkerên karûbarê bi daxwazên ji bo rêveberiya daneya ewledar; bêtir bixwînin, mînakî, vir - nêzîkî. werger.).

Çi qewimî?

GitOps du tişt e:

  1. Modela xebitandinê ji bo Kubernetes û xwecî cloudê. Ew ji bo bicihkirin, rêvebirin û şopandina kom û sepanên konteynirkirî komek pratîkên çêtirîn peyda dike. pênase Elegant di formê de yek slide ji Luis Faceira:
  2. Rêya afirandina hawîrdorek rêveberiya serîlêdanê ya pêşdebir-navendî. Em karûbarê Git hem ji bo operasyon û hem jî ji bo pêşveçûnê bicîh dikin. Ji kerema xwe not bikin ku ev ne tenê di derbarê Git push de ye, lê di derbarê organîzekirina tevahî amûrên CI/CD û UI/UX de ye.

Çend gotin li ser Git

Heke hûn bi pergalên kontrolkirina guhertoyê û xebata xebata Git-based nizanin, em bi tundî pêşniyar dikin ku li ser wan fêr bibin. Karkirina bi şaxan û daxwazên kişandinê re dibe ku di destpêkê de wekî sêrbaziya reş xuya bike, lê feydeyên hêjayî hewildanê ne. Vir gotara baş dest pê kirin.

Kubernetes çawa dixebite

Di çîroka me de, Alice û Bob piştî ku demekê bi Kubernetes re xebitîn berê xwe dan GitOps. Bi rastî, GitOps ji nêz ve bi Kubernetes re têkildar e - ew ji bo binesaziyê û serîlêdanên li ser Kubernetes-ê modelek xebitandinê ye.

Kubernetes çi dide bikarhêneran?

Li vir çend taybetmendiyên sereke hene:

  1. Di modela Kubernetes de, her tişt dikare di forma ragihandinê de were vegotin.
  2. Pêşkêşkara Kubernetes API vê danezanê wekî têketinê digire û dûv re bi domdarî hewl dide ku komê bîne rewşa ku di danezanê de hatî destnîşan kirin.
  3. Daxuyan ji bo ravekirin û birêvebirina cûrbecûr barkêşên xebatê - "serlêdan" bes in.
  4. Wekî encamek, guhertinên di serîlêdanê û komê de ji ber:
    • guhertinên di wêneyên konteynerê de;
    • Guhertinên taybetmendiya ragihandinê;
    • xeletiyên di hawîrdorê de - ji bo nimûne, konteynir diqewime.

Kapasîteyên Hevgirtinê yên Mezin ên Kubernetes

Gava ku rêveberek guheztinên vesazkirinê çêdike, orkestratorê Kubernetes dê wan li komê bicîh bike heya ku rewşa wê hebe. dê nêzî veavakirina nû nebe. Ev model ji bo her çavkaniyek Kubernetes dixebite û bi pênaseyên Çavkaniyên Xweser (CRD) ve tê berfireh kirin. Ji ber vê yekê, bicîhkirina Kubernetes xwedî taybetmendiyên ecêb ên jêrîn e:

  • Otomasyonê: Nûvekirinên Kubernetes mekanîzmayek peyda dike ku prosesa sepandina guheztinan bi xweş û di wextê xwe de bixweber bike.
  • Convergence: Kubernetes heta ku serketî be dê hewldana nûvekirinê bidomîne.
  • Idempotency: Serîlêdanên dubare yên lihevhatinê dibin sedema heman encamê.
  • Determînîzm: Dema ku çavkanî bes in, rewşa koma nûvekirî tenê bi rewşa xwestî ve girêdayî ye.

GitOps çawa dixebite

Me di derbarê Kubernetes de têra xwe fêr kir ku rave bike ka GitOps çawa dixebite.

Ka em vegerin tîmên mîkroxizmetên Bîmeya Malbatê. Divê ew bi gelemperî çi bikin? Li navnîşa jêrîn binihêrin (heke tiştên tê de xerîb an nenas xuya dikin, ji kerema xwe li ser rexnekirinê bisekinin û bi me re bimînin). Vana tenê mînakên tevgerên xebatê yên Jenkins in. Dema ku bi amûrên din re dixebitin gelek pêvajoyên din hene.

Ya sereke ev e ku em dibînin ku her nûvekirin bi guhertinên pelên mîhengê û depoyên Git bi dawî dibe. Van guhertinên Git dibe sedem ku "operatorê GitOps" komê nûve bike:

1. Pêvajoya xebatê: "Jenkins build - şaxê master".
Lîsteya peywiran:

  • Jenkins wêneyên etîketkirî li Quay dihêle;
  • Jenkins nexşeyên mîhengê û Helmê dixe ber kepçeya hilanînê ya sereke;
  • Fonksiyona ewr konfigurasyon û nexşeyan ji kelek hilanînê ya sereke li depoya masterê Git kopî dike;
  • Operatorê GitOps komê nûve dike.

2. Jenkins build - berdan an şaxek çareserkirinê:

  • Jenkins wêneyên bêtagkirî ber bi Quay ve dikişîne;
  • Jenkins nexşeyên mîhengê û Helm dişoxilîne ser kepçeya hilanînê;
  • Fonksiyona ewr konfigurasyon û nexşeyan ji kepçeya hilanînê ya stasyonê ber bi depoya Git-ê ve kopî dike;
  • Operatorê GitOps komê nûve dike.

3. Jenkins ava dike - şaxek pêşve an taybetmendiyê:

  • Jenkins wêneyên bêtagkirî ber bi Quay ve dikişîne;
  • Jenkins nexşeyên mîheng û Helmê dixe nav keviya hilanînê ya pêşdebiran;
  • Fonksiyona ewr konfigurasyon û nexşeyan ji kepçeya hilanînê ya pêşvebirinê berbi depoya Git-ê ya pêşvebirinê kopî dike;
  • Operatorê GitOps komê nûve dike.

4. Zêdekirina xerîdarek nû:

  • Rêvebir an rêveber (LCM / ops) gazî Gradle dike ku di destpêkê de balansên barkirina torê (NLB) saz bike û mîheng bike;
  • LCM/ops mîhengek nû pêk tîne da ku bicîhkirinê ji nûvekirinê re amade bike;
  • Operatorê GitOps komê nûve dike.

Danasîna kurt a GitOps

  1. Rewşa xwestî ya tevahiya pergalê bi karanîna taybetmendiyên daxuyandî ji bo her hawîrdorê rave bikin (di çîroka me de, tîmê Bob tevahiya veavakirina pergalê di Git de diyar dike).
    • Depoya Git di derbarê rewşa xwestî ya tevahiya pergalê de çavkaniya yekane ya rastiyê ye.
    • Hemî guheztinên rewşa xwestî bi navgîniya peywirên li Git têne çêkirin.
    • Hemî pîvanên komê yên xwestî di heman komê de jî têne dîtin. Bi vî awayî em dikarin diyar bikin ka ew li hev dikevin an na (hev, lihevhatin) an jî cûda dibin (cuda dibin, ji hev vediqetin) dewletên xwestî û dîtin.
  2. Ger dewletên xwestin û çavdêrî ji hev cuda bin, wê hingê:
    • Mekanîzmayek hevgirtinê heye ku zû an dereng bixweber dewletên armanc û çavdêriyê hevdem dike. Di hundurê komê de, Kubernetes vê yekê dike.
    • Pêvajo tavilê bi hişyariya "guhertin pêk hatiye" dest pê dike.
    • Piştî demekê mîhengkirî, heke dewlet cûda bin, hişyariyek "cuda" dikare were şandin.
  3. Bi vî rengî, hemî peywirên di Git-ê de dibin sedema nûvekirinên verastkirî û bêhêz ên komê.
    • Rollback lihevhatina bi rewşek berê ya xwestî ye.
  4. Hevbûn dawî ye. Bûyera wê bi vî rengî tê destnîşan kirin:
    • Ji bo demek diyarkirî hişyariyên cûda tune.
    • Hişyariya "tevhev" (mînak webhook, bûyera vegerandina Git).

Cûdahî çi ye?

Ka em dîsa dubare bikin: Pêdivî ye ku hemî taybetmendiyên komê yên xwestin di komê bixwe de bêne dîtin.

Çend mînakên cudabûnê:

  • Guhertina pelê vesazkirinê ji ber yekbûna şaxên li Git.
  • Guhertinek di pelê vesazkirinê de ji ber peywirek Git ku ji hêla muwekîlê GUI ve hatî çêkirin.
  • Ji ber PR-ê di Git-ê de gelek guheztinên rewşa xwestinê li dûv avakirina wêneya konteynerê û guhertinên mîhengê.
  • Guhertinek di rewşa komê de ji ber xeletiyek, nakokiya çavkaniyê ya ku dibe sedema "tevgera xirab", an jî bi tenê veqetîna rasthatî ji rewşa bingehîn.

Mekanîzmaya hevgirtinê çi ye?

Çend mînak:

  • Ji bo konteynir û koman, mekanîzmaya hevgirtinê ji hêla Kubernetes ve tê peyda kirin.
  • Heman mekanîzma dikare were bikar anîn ji bo birêvebirina serîlêdan û sêwiranên bingehîn ên Kubernetes (wek Istio û Kubeflow).
  • Mekanîzmayek ji bo birêvebirina pêwendiya xebitandinê ya di navbera Kubernetes, depoyên wêneyê û Git de peyda dike Operatorê GitOps Weave Flux, ku beşek e Weave Cloud.
  • Ji bo makîneyên bingehîn, mekanîzmaya hevgirtinê divê ragihandin û xweser be. Ji tecrûbeya xwe em dikarin bibêjin Terraform herî nêzî vê pênaseyê ye, lê dîsa jî kontrola mirovan hewce dike. Di vê wateyê de, GitOps kevneşopiya Binesaziyê wekî Kodê dirêj dike.

GitOps Git-ê bi motora lihevhatina hêja ya Kubernetes re dike yek da ku modelek ji bo îstismarkirinê peyda bike.

GitOps destûrê dide me ku em bibêjin: Tenê ew pergalên ku dikarin bêne şirovekirin û çavdêr kirin dikarin bêne otomatîk û kontrol kirin.

GitOps ji bo tevahiya stacka xweya cloudê tête armanc kirin (mînak, Terraform, hwd.)

GitOps ne tenê Kubernetes e. Em dixwazin ku hemû sîstem bi awayekî ragihandinê bimeşe û hevgirtinê bikar bîne. Mebesta me bi tevahî pergalê berhevokek hawîrdorên ku bi Kubernetes re dixebitin - wek nimûne, "dev koma 1", "hilberîn", hwd. Her hawîrdor makîne, kom, sepanan, û her weha navbeynkarên karûbarên derveyî yên ku daneyan, çavdêriyê peyda dikin, vedihewîne. û hwd.

Bala xwe bidinê ka Terraform di vê rewşê de ji bo pirsgirêka bootstrapping çiqas girîng e. Pêdivî ye ku Kubernetes li deverek were bicîh kirin, û karanîna Terraform tê vê wateyê ku em dikarin heman gerokên xebatê yên GitOps bicîh bikin da ku qata kontrolê ya ku Kubernetes û serîlêdanan dişoxilîne biafirînin. Ev pratîkek çêtirîn kêrhatî ye.

Li ser sepandina têgînên GitOps li qatên li ser Kubernetes-ê balek xurt heye. Heya nuha, çareseriyên celebê GitOps ji bo Istio, Helm, Ksonnet, OpenFaaS û Kubeflow, û her weha, mînakî, ji bo Pulumi hene, ku ji bo pêşkeftina serîlêdanên ji bo xwecihiya cloudê qatek diafirîne.

Kubernetes CI/CD: berhevdana GitOps bi nêzîkatiyên din re

Wekî ku hate gotin, GitOps du tişt e:

  1. Modela xebitandinê ji bo Kubernetes û xwecî cloudê ku li jor hatî destnîşan kirin.
  2. Rêya berbi hawîrdorek rêveberiya serîlêdanê ya pêşdebir-navendî.

Ji bo pir kesan, GitOps di serî de karek e ku li ser bingeha pêlên Git-ê ye. Em jî ji wî hez dikin. Lê ew ne hemî ye: em niha li boriyên CI/CD binêrin.

GitOps ji bo Kubernetes vekirina domdar (CD) çalak dike

GitOps mekanîzmayek birêkûpêkkirina domdar pêşkêşî dike ku hewcedariya "pergalên rêveberiya veqetandinê" yên cihêreng ji holê radike. Kubernetes hemî karan ji bo we dike.

  • Nûvekirina serîlêdanê nûvekirina li Git hewce dike. Ev nûvekirinek danûstendinê ya rewşa xwestî ye. Dûv re "dabeşkirin" di nav komê de ji hêla Kubernetes bixwe ve li ser bingeha danasîna nûvekirî tête kirin.
  • Ji ber cewherê ku Kubernetes çawa dixebite, ev nûvekirin hevûdu ne. Ev mekanîzmayek ji bo bicîhkirina domdar peyda dike ku tê de hemî nûvekirin atomî ne.
  • Têbînî: Weave Cloud operatorek GitOps pêşkêşî dike ku Git û Kubernetes dike yek û dihêle ku CD bi lihevanîna rewşa xwestî û heyî ya komê were kirin.

Bê kubectl û nivîsar

Divê hûn ji karanîna Kubectl dûr bixin da ku koma xwe nûve bikin, û nemaze ji karanîna nivîsarên ji bo komkirina fermanên kubectl dûr bisekinin. Di şûna wê de, bi lûleya GitOps re, bikarhênerek dikare koma xwe ya Kubernetes bi Git nûve bike.

Feydeyên wê hene:

  1. Rast. Komek nûvekirin dikare were sepandin, hevgirtin û di dawiyê de were pejirandin, ku me nêzikî armanca bicîhkirina atomê dike. Berevajî vê, karanîna nivîsan garantiyek hevgirtinê peyda nake (li ser vê yekê li jêr).
  2. Ewlekariyê. Quoting Kelsey Hightower: "Gihîştina koma xweya Kubernetes ji amûrên otomasyonê û rêvebirên ku berpirsiyar in ji xeletîkirin an domandina wê re sînordar bikin." jî bibînin weşana min li ser ewlekarî û pabendbûna bi taybetmendiyên teknîkî, û her weha gotara li ser hackkirina Homebrew bi dizîna pêbaweriyên ji senaryoyek Jenkins a bi xemsarî hatî nivîsandin.
  3. Tecrûbeya Bikarhêner. Kubectl mekanîka modela objektê ya Kubernetes, ku pir tevlihev in, eşkere dike. Bi îdeal, bikarhêner divê bi pergalê re di astek bilindtir a abstraction de têkilî daynin. Li vir ez ê dîsa behsa Kelsey bikim û temaşekirinê pêşniyar bikim resume wisa.

Cûdahiya di navbera CI û CD de

GitOps modelên heyî yên CI/CD çêtir dike.

Pêşkêşkarek CI ya nûjen amûrek orkestrasyonê ye. Bi taybetî, ew amûrek ji bo organîzekirina boriyên CI ye. Di nav wan de çêkirin, ceribandin, yekbûna bi trunk, hwd. Pêşkêşkerên CI-yê rêveberiya lûleyên pir-gavekî yên tevlihev otomatîk dikin. Ceribandinek hevpar ev e ku meriv komek nûvekirinên Kubernetes binivîsîne û wê wekî beşek boriyê bimeşîne da ku guheztinan li komê bikişîne. Bi rastî, ev tiştê ku gelek pispor dikin. Lêbelê, ev ne çêtirîn e, û li vir çima ye.

Pêdivî ye ku CI were bikar anîn da ku nûvekirinên li qurmê bikişîne, û komika Kubernetes divê xwe li ser bingeha wan nûvekirinan biguhezîne da ku CD-yê hundurîn birêve bibe. Em jê re dibêjin modela bikişîne ji bo CD, berevajî modela CI push. CD beşek e orkestrasyona runtime.

Çima Pêşkêşkerên CI Divê CD-yan bi Nûvekirinên Rasterê li Kubernetes-ê nekin

Pêşkêşkarek CI-ê bikar neynin da ku nûvekirinên rasterast ên Kubernetes wekî komek karên CI-yê organîze bikin. Ev dij-patterna ku em behs dikin ev e berê gotiye li ser bloga xwe.

Ka em vegerin ser Alice û Bob.

Bi kîjan pirsgirêkan re rû bi rû man? Pêşkêşkara CI ya Bob guheztinan li komê bicîh tîne, lê heke ew di pêvajoyê de têk biçe, Bob dê nizane kom di çi rewşê de ye (an jî divê be) an çawa wê rast bike. Di rewşa serkeftinê de jî wisa ye.

Ka em bihesibînin ku tîmê Bob wêneyek nû ava kir û dûv re veguheztinên xwe ji bo bicîhkirina wêneyê (hemû ji xeta CI) vekir.

Ger wêne bi gelemperî çêdibe, lê boriyê têk diçe, tîmê pêdivî ye ku fêhm bike:

  • Nûvekirin derketiye?
  • Ma em avahiyek nû didin destpêkirin? Ma ev ê bibe sedema bandorên aliyî yên nehewce - bi îhtîmala hebûna du avahîyên heman wêneyê neguhêrbar?
  • Ma divê em li benda nûvekirina paşîn bisekinin berî ku çêkirinê bimeşînin?
  • Bi rastî çi xelet çû? Kîjan gav hewce ne ku bêne dubare kirin (û kîjan ji dubarekirinê ewle ne)?

Sazkirina xebatek-based Git garantî nake ku tîmê Bob bi van pirsgirêkan re rû bi rû nemîne. Ew hîn jî dikarin bi commit push, tag, an hin pîvanek din re xeletiyek bikin; lebê, ev nêzîkatî hê jî pir nêzîktir ji nêzîkatiya eşkere hemû-an-tişt e.

Bi kurtasî, li vir çima serverên CI divê bi CD-yê re mijûl nebin:

  • Nivîsarên nûvekirinê her gav diyarker ne; Di wan de xeletî kirin hêsan e.
  • Pêşkêşkerên CI bi modela komê ya daxuyandî re nagihin hev.
  • Zehmet e ku meriv bêhêziyê garantî bike. Divê bikarhêner semantîka kûr a pergalê fam bikin.
  • Sazkirina ji têkçûnek qismî dijwartir e.

Nîşe di derbarê Helm de: Heke hûn dixwazin Helm bikar bînin, em pêşniyar dikin ku wê bi operatorek GitOps re wek mînak bikin. Flux-Helm. Ev ê alîkariyê bide hevgirtinê. Helm bixwe ne diyarker û ne jî atomî ye.

GitOps wekî awayê çêtirîn ku ji bo Kubernetes Radestkirina Berdewam bicîh tîne

Tîma Alice û Bob GitOps bicîh tîne û kifş dike ku ew pir hêsantir bûye ku bi hilberên nermalavê re bixebite, performansa bilind û aramiyê biparêze. Werin em vê gotarê bi nîgarek biqedînin ku nîşan dide ka nêzîkatiya wan a nû çawa xuya dike. Bînin bîra xwe ku em bi piranî li ser serîlêdan û karûbaran diaxivin, lê GitOps dikare were bikar anîn da ku tevahî platformek birêve bibe.

Modela xebitandinê ji bo Kubernetes

Li diagrama jêrîn binêrin. Ew Git û depoya wêneya konteynerê wekî çavkaniyên hevpar ji bo du çerxên jiyanê yên organîzekirî pêşkêşî dike:

  • Xetek entegrasyonê ya domdar ku pelan li Git dixwîne û dinivîse û dikare depoyek wêneyên konteynerê nûve bike.
  • Xetek Runtime GitOps ku bicîhkirinê bi rêveberî û çavdêriyê re dike yek. Ew pelan li Git dixwîne û dinivîse û dikare wêneyên konteynerê dakêşîne.

Encamên sereke çi ne?

  1. Veqetandina fikaran: Ji kerema xwe bala xwe bidin ku her du hêlîn tenê dikarin bi nûvekirina Git an depoya wêneyê re têkilî daynin. Bi gotinek din, di navbera CI û hawîrdora xebitandinê de dîwarek agir heye. Em jê re dibêjin "agirê dîwarê neguhêrbar" (Firewallê neguhêrbar), ji ber ku hemî nûvekirinên depoyê guhertoyên nû diafirînin. Ji bo bêtir agahdarî li ser vê mijarê, serî li slaytên 72-87 bidin vê pêşkêşiyê.
  2. Hûn dikarin her serverek CI û Git bikar bînin: GitOps bi her pêkhateyê re dixebite. Hûn dikarin berdewam bikin ku hûn serverên xweyên CI û Git, depoyên wêneyê, û komikên ceribandinê bikar bînin. Hema hema hemî amûrên Radestkirina Berdewam ên li sûkê servera xweya CI/Git an depoya wêneyê hewce dike. Ev dibe ku bibe faktorek sînordar di pêşkeftina xweya cloudê de. Bi GitOps re, hûn dikarin amûrên naskirî bikar bînin.
  3. Bûyerên wekî amûrek entegrasyonê: Gava ku daneyên di Git-ê de têne nûve kirin, Weave Flux (an operatorê Weave Cloud) dema xebitandinê agahdar dike. Gava ku Kubernetes komek guheztinê qebûl dike, Git tê nûve kirin. Ev modelek entegrasyonê ya hêsan peyda dike ji bo organîzekirina gerîdeyên xebatê ji bo GitOps, wekî ku li jêr tê nîşandan.

encamê

GitOps garantiyên nûvekirina bihêz ên ku ji hêla amûrek nûjen a CI/CD ve tê xwestin peyda dike:

  • otomatîkî;
  • convergence;
  • idempotency;
  • determînîzm.

Ev girîng e ji ber ku ew modelek xebitandinê ji bo pêşdebirên xwecihî cloudê pêşkêşî dike.

  • Amûrên kevneşopî yên ji bo rêvebirin û çavdêrîkirina pergalên bi tîmên operasyonê yên ku di hundurê pirtûkê de dixebitin re têkildar in (komek prosedurek û operasyonên rûtîn - bi qasî werger.), bi veqetandinek taybetî ve girêdayî ye.
  • Di rêveberiya xwecihî ya cloudê de, amûrên çavdêriyê awayê çêtirîn e ku meriv encamên bicîhkirinê bipîve da ku tîmê pêşkeftinê zû bersivê bide.

Bifikirin ku gelek kom li ser ewrên cihêreng û gelek karûbarên bi tîmên xwe û plansaziyên bicîhkirinê belav bûne. GitOps ji bo birêvebirina vê pirbûnê modelek pîvan-guhêrbar pêşkêşî dike.

PS ji wergêr

Li ser bloga me jî bixwînin:

Tenê bikarhênerên qeydkirî dikarin beşdarî anketê bibin. Têketinji kerema xwe.

Berî ku ev her du werger li Habré xuya bibin, we di derbarê GitOps de dizanibû?

  • Erê, min her tişt dizanibû

  • Tenê bi awayekî rûpî

  • na

35 bikarhêneran deng dan. 10 bikarhêner jî betal bûn.

Source: www.habr.com

Add a comment