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

ÇfarĂ« Ă«shtĂ« GitOps?

ShĂ«n. pĂ«rk.: Pas publikimit tĂ« fundit tĂ« materialeve rreth metodave pull dhe push nĂ« GitOps, ne pamĂ« interes pĂ«r kĂ«tĂ« model nĂ« pĂ«rgjithĂ«si, megjithatĂ«, publikimet nĂ« gjuhĂ«n ruse mbi kĂ«tĂ« temĂ« ishin tepĂ«r tĂ« pakta (nĂ« Habr nuk ka asnjĂ«). Prandaj, jemi tĂ« lumtur t'ju ofrojmĂ« pĂ«rkthimin e njĂ« artikulli tjetĂ«r — ndonĂ«se tashmĂ« pothuajse njĂ« vit mĂ« parĂ«! — nga kompania Weaveworks, themeluesi i sĂ« cilĂ«s shpiku termin “GitOps”. NĂ« tekst shpjegohet thelbi i qasjes dhe dallimet kyçe nga ato ekzistuese.

Një vit më parë ne publikuam një hyrje në GitOps. Atëherë ne treguam se si ekipi i Weaveworks filloi një SaaS, tërësisht të bazuar në Kubernetes, dhe zhvilloi një set praktikash më të mira për implementimin, menaxhimin dhe monitorimin në një ambient cloud native.

Artikulli u bë i njohur. Të tjerë filluan të flasin për GitOps, filluan të publikojnë mjete të reja për git push, zhvillimit, sekretet, funksione, integrimit të vazhdueshëm etj. Në faqen tonë u shfaq një numër i madh publikimesh dhe raste përdorimi të GitOps. Por disa njerëz ende patën pyetje. Si ndryshon modeli nga tradita infrastructure as code dhe dërgesat e vazhdueshme (continuous delivery)? A është e domosdoshme të përdoret Kubernetes?

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

  1. Një numër të madh shembujsh dhe historish;
  2. Një përcaktim konkret të GitOps;
  3. Krahasimi me dërgimin e vazhdueshëm tradicional.

Në këtë artikull ne përpiqemi të mbulojmë të gjitha këto tema. Do të gjeni një hyrje të azhurnuar në GitOps dhe një perspektivë mbi të nga ana e zhvilluesve dhe CI/CD. Ne kryesisht fokusohemi në Kubernetes, megjithatë modeli mund të përgjithësohet.

Njoftohuni: GitOps

Imagjinoni Alice. Ajo menaxhon kompaninĂ« Family Insurance, e cila ofron politika pĂ«r sigurimin e shĂ«ndetit, automjeteve, pasurive dhe sigurimeve tĂ« udhĂ«timit pĂ«r persona qĂ« janĂ« shumĂ« tĂ« zĂ«nĂ« pĂ«r tĂ« kuptuar detajet e kontratave vetĂ«. Biznesi i saj filloi si njĂ« projekt anĂ«sor, kur Alice punonte nĂ« bankĂ« si data scientist. NjĂ«herĂ« ajo kuptoi se mund tĂ« pĂ«rdorte algoritme tĂ« avancuara kompjuterike pĂ«r tĂ« analizuar tĂ« dhĂ«nat mĂ« efektivisht dhe pĂ«r tĂ« formuar paketa sigurimi. InvestitorĂ«t financuan projektin, dhe tani kompania e saj sjell mbi 20 milion dollarĂ« nĂ« vit dhe po rritet me shpejtĂ«si. Aktualisht, nĂ« tĂ« punojnĂ« 180 njerĂ«z nĂ« pozita tĂ« ndryshme. Midis tyre Ă«shtĂ« ekipi teknologjik, i cili merret me zhvillimin, mirĂ«mbajtjen e faqes, bazĂ«s sĂ« dhĂ«nave dhe analizĂ«n e bazĂ«s sĂ« klientĂ«ve. Ekipi me 60 njerĂ«z drejtohet nga Bob — drejtori teknik i kompanisĂ«.

Ekipi i Bob-it boton sisteme production në cloud. Aplikacionet e tyre kryesore funksionojnë në GKE, duke shfrytëzuar avantazhet e Kubernetes në Google Cloud. Për më tepër, ata përdorin një sërë mjetesh për përpunimin e të dhënave dhe analitikës.

Family Insurance nuk kishte për qëllim të përdorte kontejnerë, por u infektua nga entuziazmi për rreth Docker. Së shpejti specialistët e kompanisë zbuluan se GKE lejonte botimin e grupeve për testimin e funksioneve të reja lehtësisht dhe pa mundim. U shtuan Jenkins për CI dhe Quay për organizimin e regjistrit të kontejnerëve, u shkruan skriptet për Jenkins, të cilat publikuan kontejnerë të rinj dhe konfigurations në GKE.

Ka kaluar njĂ« kohĂ«. Alice dhe Bob u zhgĂ«njyen me performancĂ«n e qasjes sĂ« zgjedhur dhe ndikimin e saj nĂ« biznes. Implementimi i kontejnerĂ«ve nuk e rriti performancĂ«n aq sa kishte shpresuar ekipi. NdonjĂ«herĂ« publikuar ishte e prishur, dhe nuk ishte e qartĂ« nĂ«se ndryshimet nĂ« kod ishin fajtorĂ«t. Gjithashtu, ishte e vĂ«shtirĂ« tĂ« ndiqeshin ndryshimet e konfigurations. Shpesh duhej tĂ« krijohej njĂ« grup i ri dhe tĂ« ĐżĐ”Ń€Đ”ĐœĐŸŃeshin aplikacionet nĂ« tĂ«, pasi kĂ«shtu ishte mĂ« e lehtĂ« tĂ« eleminoheshin tĂ« gjitha kaosi nĂ« tĂ« cilin ishte kthyer sistemi. Alice kishte frikĂ« se situata do tĂ« pĂ«rkeqĂ«sohej me zhvillimin e aplikacionit (pĂ«r mĂ« tepĂ«r, njĂ« projekt i ri po pritej tĂ« nisĂ« mbi mĂ«simin e makinerisĂ«). Bob kishte automatizuar shumicĂ«n e punĂ«s dhe nuk e kuptonte pse pipeline vazhdonte tĂ« ishte i paqĂ«ndrueshĂ«m, tĂ« mos shkonte pĂ«rpara dhe ndonjĂ«herĂ« kĂ«rkonte ndĂ«rhyrje manuale?

Pastaj ata mësuan rreth GitOps. Ky zgjidhje doli të ishte pikërisht ajo që u nevojitej për të avancuar me besim.

Alice dhe Bob kishin dĂ«gjuar pĂ«r disa vite pĂ«r proceset e bazuara nĂ« Git, DevOps dhe infrastructure as code. Veçoria e GitOps Ă«shtĂ« se ai sjell njĂ« sĂ«rĂ« praktikash mĂ« tĂ« mira — kategorike dhe normuese — pĂ«r implementimin e kĂ«tyre ideve nĂ« kontekstin e Kubernetes. Ky temĂ« u ngrit disa herĂ«, pĂ«rfshirĂ« nĂ« blogun e Weaveworks.

Family Insurance vendos tĂ« implementojĂ« GitOps. Tani kompania ka njĂ« model tĂ« automatizuar operimi, tĂ« pĂ«rputhshĂ«m me Kubernetes dhe qĂ« kombinon сĐșĐŸŃ€ĐŸŃŃ‚ŃŒ me me stabilitetin, pasi ata:

  • zbuluan se produktiviteti i ekipit u dyfishua dhe askush nuk po shpĂ«rthehet kĂ«shtu.
  • ndaluan suportin pĂ«r skriptet. NĂ« vend tĂ« kĂ«saj, ata tani mund tĂ« pĂ«rqendrohen nĂ« funksionalitete tĂ« reja dhe tĂ« pĂ«rmirĂ«sojnĂ« metodat inxhinierike — pĂ«r shembull, tĂ« implementojnĂ« lĂ«shime tĂ« kanarinave dhe tĂ« pĂ«rmirĂ«sojnĂ« testimin;
  • pĂ«rmirĂ«suan procesin e shpĂ«rndarjes — tani ai rrallĂ« dĂ«shton;
  • fituan mundĂ«sinĂ« pĂ«r tĂ« rikuperuar shpĂ«rndarjet pas dĂ«shtimeve tĂ« pjesshme pa ndĂ«rhyrje manuale;
  • fituan mĂ«oshumĂ« besim nĂ« sistemet e dorĂ«zimit. Alisa dhe Bobi zbuluan se mund tĂ« ndanin ekipin nĂ« grupe qĂ« merren me mikroshĂ«rbime dhe punojnĂ« paralelisht;
  • mund tĂ« bĂ«jnĂ« nga 30-50 ndryshime nĂ« projekt çdo ditĂ« me pĂ«rpjekjet e çdo grupi dhe tĂ« provojnĂ« teknika tĂ« reja;
  • lehtĂ« tĂ« tĂ«rheqin nĂ« projekt zhvillues tĂ« rinj, tĂ« cilĂ«t kanĂ« mundĂ«si tĂ« zbatojnĂ« pĂ«rditĂ«sime nĂ« prodhim me ndihmĂ«n e kĂ«rkesave tĂ«rheqĂ«se brenda disa orĂ«sh;
  • lehtĂ« kalojnĂ« auditet e SOC2 (pĂ«r t'u pĂ«rputhur me kĂ«rkesat e shĂ«rbimeve pĂ«r menaxhimin e sigurt tĂ« tĂ« dhĂ«nave; lexoni mĂ« shumĂ«, pĂ«r shembull, kĂ«tu — shĂ«nim i pĂ«rkthyesit.).

ÇfarĂ« ndodhi?

GitOps është dy gjëra:

  1. Një model operimi për Kubernetes dhe cloud native. Ai ofron një set praktikash më të mira për shpërndarjen, menaxhimin dhe monitorimin e klasterëve dhe aplikacioneve të mbledhura në kontejnerë. Një përkufizim elegant në formën e një slide. nga Luis Faceira:
  2. Një rrugë për të krijuar një mjedis të orientuar ndaj zhvilluesve për menaxhimin e aplikacioneve. Ne përdorim fluksin e punës Git si për operimin ashtu edhe për zhvillimin. Vini re se nuk bëhet fjalë vetëm për Git push, por për organizimin e të gjithë grupit të mjeteve CI/CD dhe UI/UX.

Një fjalë për Git

Nëse nuk keni njohuri për sistemet e kontrollit të versioneve dhe fluksin e punës të bazuar në Git, ne rekomandojmë me ngulm të mësoni për to. Në fillim, puna me degët dhe kërkesat e tërheqjes mund të duket magji e zezë, por përfitimet ia vlejnë përpjekjeve të sakrifikuara. Ja artikull i mirë për fillimin.

Si funksionon Kubernetes

NĂ« historinĂ« tonĂ«, Alisa dhe Bobi iu drejtuan GitOps, pasi punuan pĂ«r njĂ« kohĂ« me Kubernetes. Me tĂ« vĂ«rtetĂ«, GitOps Ă«shtĂ« ngushtĂ«sisht i lidhur me Kubernetes — Ă«shtĂ« njĂ« model operimi pĂ«r infrastrukturĂ«n dhe aplikacionet qĂ« mbĂ«shteten nĂ« Kubernetes.

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

Këtu janë disa nga mundësitë kryesore:

  1. Në modelin e Kubernetes, gjithçka mund të përshkruhet në një formë deklarative.
  2. API-serveri i Kubernetes pranon këtë deklaratë si input dhe pastaj vazhdimisht përpiqet ta sjellë klasterin në gjendjen e përshkruar në deklaratë.
  3. Deklaratat mjaftojnĂ« pĂ«r tĂ« pĂ«rshkruar dhe menaxhuar njĂ« gamĂ« tĂ« gjerĂ« ngarkesash pune — "aplikacione".
  4. Si rezultat, ndryshimet në aplikacion dhe klaster ndodhin nga:
    • ndryshime nĂ« imazhet e kontejnerĂ«ve;
    • ndryshime nĂ« specifikimin deklarativ;
    • gabimet nĂ« mjedis — pĂ«r shembull, rĂ«niet e kontejnerĂ«ve.

Aftësitë e shkëlqyera të konvergjencës së Kubernetes

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

  • Automatizimi: pĂ«rditĂ«simet e Kubernetes ofrojnĂ« njĂ« mekanizĂ«m pĂ«r automatizimin e procesit tĂ« aplikimit tĂ« ndryshimeve nĂ« mĂ«nyrĂ« tĂ« saktĂ« dhe me kohĂ«.
  • Konvergjenca: Kubernetes do tĂ« vazhdojĂ« tĂ« pĂ«rpiqet pĂ«r pĂ«rditĂ«sime deri nĂ« arritjen e suksesit.
  • Idempotentizmi: ripĂ«rsĂ«ritjet e konvergjencĂ«s sjellin tĂ« njĂ«jtin rezultat.
  • Determinizmi: nĂ« kushte tĂ« mjaftueshme, gjendja e tĂ« pĂ«rditĂ«suarit tĂ« klasterit varet vetĂ«m nga gjendja e dĂ«shiruar.

Si funksionon GitOps

Ne mësuam mjaft për Kubernetes për të shpjeguar principet e funksionimit të GitOps.

Le tĂ« kthehemi te ekipet e Family Insurance, tĂ« lidhura me mikroshĂ«rbimet. ÇfarĂ« duhet tĂ« bĂ«jnĂ« zakonisht ato? Shikoni listĂ«n mĂ« poshtĂ« (nĂ«se disa pika nĂ« tĂ« duken tĂ« çuditshme ose tĂ« panjohura — ju lutemi, prisni pak me kritikat dhe mbeteni me ne). KĂ«to janĂ« thjesht shembuj tĂ« flukseve tĂ« punĂ«s me bazĂ« Jenkins. Ka edhe shumĂ« procese tĂ« tjera kur punoni me mjete tĂ« tjera.

E rëndësishmja është, ne shohim se çdo përditësim përfundon me ndryshime në skedarët e konfigurimit dhe depozitat Git. Këto ndryshime në Git çojnë në këtë mënyrë që "operatori GitOps" përditëson klasterin:

1. Fluksi i punĂ«s: "NdĂ«rtimi Jenkins — dega master».
Lista e detyrave:

  • Jenkins dĂ«rgon imazhe tĂ« etiketuara nĂ« Quay;
  • Jenkins dĂ«rgon konfigurimin dhe diagramet Helm nĂ« bucket-in e master-it;
  • Funksioni i rethit kopjon konfigurimin dhe diagramet nga bucket-i i master-it nĂ« depozitĂ«n Git master;
  • Operatori GitOps pĂ«rditĂ«son klasterin.

2. NdĂ«rtimi Jenkins — dega e lĂ«shimit ose hotfix:

  • Jenkins dĂ«rgon imazhe tĂ« paetiketuara nĂ« Quay;
  • Jenkins dĂ«rgon konfigurimin dhe diagramet Helm nĂ« bucket-in staging;
  • Funksioni nĂ« re kopjon konfigurimin dhe diagramet nga depoja staging nĂ« Git-repozitorinĂ« staging;
  • Operatori GitOps pĂ«rditĂ«son klasterin.

3. Konstruksioni Jenkins — dega develop ose feature:

  • Jenkins dĂ«rgon imazhe tĂ« paetiketuara nĂ« Quay;
  • Jenkins shton konfigurimin dhe diagramet Helm nĂ« depozitĂ«n develop;
  • Funksioni nĂ« re kopjon konfigurimin dhe diagramet nga depoja develop nĂ« Git-repozitorinĂ« develop;
  • Operatori GitOps pĂ«rditĂ«son klasterin.

4. Shtimi i klientit të ri:

  • Menaxheri ose administratori (LCM/ops) thĂ«rret Gradle pĂ«r shpĂ«rndarjen e parĂ« dhe konfigurimin e balancuesve tĂ« ngarkesĂ«s (NLB);
  • LCM/ops angazhon konfigurimin e ri pĂ«r pĂ«rgatitjen e shpĂ«rndarjes pĂ«r pĂ«rditĂ«simet;
  • Operatori GitOps pĂ«rditĂ«son klasterin.

Përshkrimi i shkurtër të 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 përcakton të gjithë konfigurimin e sistemit në Git).
    • Git-repozitorie Ă«shtĂ« burimi i vetĂ«m i tĂ« vĂ«rtetĂ«s nĂ« lidhje me gjendjen e dĂ«shiruar tĂ« gjithĂ« sistemit.
    • TĂ« gjitha ndryshimet nĂ« gjendjen e dĂ«shiruar realizohen pĂ«rmes angazhimeve nĂ« Git.
    • TĂ« gjithĂ« parametrat e dĂ«shiruar tĂ« klasterit janĂ« gjithashtu tĂ« vĂ«zhgueshĂ«m brenda vetĂ« klasterit. KĂ«shtu, ne mund tĂ« pĂ«rcaktojmĂ« nĂ«se gjendja e dĂ«shiruar dhe e vĂ«zhguar janĂ« nĂ« pĂ«rputhje (konvergojnĂ«, converge) ose ndryshojnĂ« (divergojnĂ«, diverge) gjendja e dĂ«shiruar dhe e vĂ«zhguar.
  2. Nëse gjendja e dëshiruar dhe e vëzhguar ndryshon, atëherë:
    • Ekziston njĂ« mekanizĂ«m konvergjence, i cili, njĂ«herĂ« e njĂ« kohĂ«, do tĂ« sinkronizojĂ« automatikisht gjendjen e synuar dhe gjendjen e vĂ«zhguar. Brenda klasterit, kjo merret nga Kubernetes.
    • Procesi niset menjĂ«herĂ« me njoftimin "ndryshimi Ă«shtĂ« angazhuar".
    • Pas njĂ« intervali tĂ« caktuar kohor, mund tĂ« dĂ«rgohet njĂ« njoftim "dif", nĂ«se gjendjet ndryshojnĂ«.
  3. Kështu, të gjitha angazhimet në Git shkaktuan përditësime verifikueshëm dhe idempotente në klaster.
    • Rivendosja Ă«shtĂ« njĂ« konvergjencĂ« nĂ« njĂ« gjendje tĂ« dĂ«shiruar mĂ« parĂ«.
  4. Konvergjenca është përfundimtare. Të dhënat për këtë tregojnë:
    • Mungesa e njoftimeve "dif" pĂ«r njĂ« periudhĂ« tĂ« caktuar kohore.
    • Njoftimi "konverguar" (p.sh., webhook, ngjarje Git writeback).

ÇfarĂ« Ă«shtĂ« divergjenca?

Për ta përsëritur përsëri: të gjitha pronat e dëshiruara të klasterit duhet të jenë të vëzhgueshme brenda klasterit.

Disa shembuj të divergjencës:

  • Ndryshimi nĂ« skedarin e konfigurimit pĂ«r shkak tĂ« bashkimit tĂ« degĂ«ve nĂ« Git.
  • Ndryshimi nĂ« skedarin e konfigurimit pĂ«r shkak tĂ« angazhimit nĂ« Git, tĂ« bĂ«rĂ« nga njĂ« klient GUI.
  • ShumĂ« ndryshime nĂ« gjendjen e dĂ«shiruar pĂ«r shkak tĂ« PR nĂ« Git me ndĂ«rtimin e mĂ«vonshĂ«m tĂ« imazhit tĂ« kontejnerit dhe ndryshimeve nĂ« konfigurim.
  • Ndryshimi i gjendjes sĂ« klasterit pĂ«r shkak tĂ« gabimit, konfliktit tĂ« burimeve, qĂ« çon nĂ« "sjellje tĂ« keqe", ose thjesht devijimit tĂ« rastĂ«sishĂ«m nga gjendja origjinale.

ÇfarĂ« paraqet njĂ« mekanizĂ«m konvergjence?

Disa shembuj:

  • PĂ«r kontejnerĂ«t dhe klasterĂ«t, mekanizmi i konvergjencĂ«s ofrohet nga Kubernetes.
  • I njĂ«jti mekanizĂ«m mund tĂ« pĂ«rdoret pĂ«r menaxhimin e aplikacioneve dhe strukturave tĂ« bazuara nĂ« Kubernetes (p.sh., Istio dhe Kubeflow).
  • Mekanizmi pĂ«r menaxhimin e ndĂ«rveprimeve tĂ« punĂ«s midis Kubernetes, depozitave tĂ« imazheve dhe Git-it ofron operatori GitOps Weave Flux, qĂ« Ă«shtĂ« pjesĂ« e Weave Cloud.
  • PĂ«r makinat bazĂ«, mekanizmi i konvergjencĂ«s duhet tĂ« jetĂ« deklarativ dhe autonom. Nga pĂ«rvoja jonĂ«, mund tĂ« themi se Terraform Ă«shtĂ« mĂ« afĂ«r kĂ«saj pĂ«rkufizimi, megjithatĂ«, kĂ«rkon akoma kontroll nga njĂ« person. NĂ« kĂ«tĂ« kuptim, GitOps zgjeron traditat e Infrastructure as Code.

GitOps bashkon Git me një mekanizëm të shkëlqyer konvergjence të Kubernetes, duke ofruar një model për eksploitimin.

GitOps na lejon të deklarojmë: automatikë dhe kontrolli u nënshtruan vetëm atyre sistemeve që mund të përshkruhen dhe vëzhgohen.

GitOps është për të gjithë stakun cloud native (p.sh., Terraform etj.)

GitOps nuk Ă«shtĂ« vetĂ«m Kubernetes. Ne duam qĂ« i gjithĂ« sistemi tĂ« menaxhohet nĂ« mĂ«nyrĂ« deklarative dhe tĂ« pĂ«rdorĂ« konvergjencĂ«n. Nga gjithĂ« sistemi, ne nĂ«nkuptojmĂ« njĂ« pĂ«rmbledhje tĂ« mjediseve qĂ« punojnĂ« me Kubernetes — p.sh., "dev cluster 1", "produksioni" etj. NĂ« çdo mjedis pĂ«rfshihen makina, klasterĂ«, aplikacione, si dhe ndĂ«rfaqet pĂ«r shĂ«rbimet e jashtme qĂ« ofrojnĂ« tĂ« dhĂ«na, monitorim etj.

Vini re se sa e rëndësishme është Terraform për problemin e bootstrapping. Kubernetes duhet të jetë diku i vendosur, dhe përdorimi i Terraform do të thotë se ne mund të përdorim të njëjtat procese GitOps për të ndërtuar shtresën menaxhuese, që qëndron në bazë të Kubernetes dhe aplikacioneve. Kjo është një praktikë e mirë e dobishme.

Një vëmendje e madhe i kushtohet aplikimit të koncepteve të GitOps në shtresat mbi Kubernetes. Deri tani, ka zgjidhje të tipit GitOps për Istio, Helm, Ksonnet, OpenFaaS dhe Kubeflow, si dhe për shembuj, 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 eksploitimi për Kubernetes dhe cloud native, i përshkruar më sipër.
  2. Një rrugë për organizimin e një ambienti të orientuar ndaj zhvilluesve për menaxhimin e aplikacioneve.

Për shumë, GitOps është kryesisht një proces pune i bazuar në Git push. Ne e pëlqejmë atë gjithashtu. Por kjo nuk është gjithçka: le të shikojmë tani pipeline-t e CI/CD.

GitOps siguron shpërndarje të vazhdueshme (CD) nën Kubernetes

GitOps ofron një mekanizëm për shpërndarje të vazhdueshme që eliminon nevojën për "sisteme menaxhimi të shpërndarjeve" të veçanta. E gjithë punën e bën Kubernetes.

  • PĂ«rditĂ«simi i aplikacionit kĂ«rkon njĂ« pĂ«rditĂ«sim nĂ« Git. Ky Ă«shtĂ« njĂ« pĂ«rditĂ«sim tranzaksional nĂ« gjendjen e dĂ«shiruar. "ShpĂ«rndarja" pastaj kryhet brenda klasterit nga Kubernetes vetĂ« nĂ« bazĂ« tĂ« shtesave tĂ« pĂ«rditĂ«suara.
  • PĂ«r shkak tĂ« natyrĂ«s sĂ« punĂ«s sĂ« Kubernetes, kĂ«to pĂ«rditĂ«sime janĂ« konvergjente. Kjo siguron njĂ« mekanizĂ«m pĂ«r shpĂ«rndarje tĂ« vazhdueshme, ku tĂ« gjitha pĂ«rditĂ«simet janĂ« atomike.
  • ShĂ«nim: Weave Cloud ofron njĂ« operator GitOps, qĂ« integron Git dhe Kubernetes dhe lejon ekzekutimin e CD duke pĂ«rputhur gjendjen e dĂ«shiruar me atĂ« aktuale tĂ« klasterit.

Pa kubectl dhe skenarë

Duhet të shmangen përdorimi i Kubectl për përditësimin e klasterit, sidomos skenarët për grupimin e komandave kubectl. Në vend të kësaj, me anë të pipeline të GitOps, përdoruesi mund të përditësojë klasterin e tij Kubernetes përmes Git.

Përparësitë përfshijnë:

  1. Saktësia. Një grup përditësimesh mund të aplikohet, të konvergojë dhe përfundimisht të validizohet, duke na afruar me qëllimin e shpërndarjes atomike. Në anën tjetër, përdorimi i skripteve nuk jep asnjë garanci konvergjence (më shumë për këtë më poshtë).
  2. Siguria. Citoj Kelsey Hightower: "Kufizoni aksesin në klasterin Kubernetes për mjetet e automatizimit dhe administratorët që kanë për detyrë ta rregullojnë ose ta mbajnë në punë." Shih gjithashtu postimin tim për sigurinë dhe përputhshmërinë me standardet teknike, si dhe artikullin për hackimin e Homebrew përmes vjedhjes së kredencialeve nga një skenar Jenkins i heshtur.
  3. Përvoja e përdoruesit. Kubectl zbulohet mekanika e modelit objektiv të Kubernetes, i cili është mjaft kompleks. Idealisht, përdoruesit duhet të ndërveprojnë me sistemin në një nivel më të lartë abstraksioni. Këtu do të citoj përsëri Kelsey dhe rekomandoj të shikoni një përmbledhje të tillë.

Dallimi mes CI dhe CD

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

Një server modern CI është një mjet për orkestrimin. Saktësisht, është një mjet për orkestrimin e pipeline-t CI. Këto përfshijnë ndërtimin, testimin, bashkimin në trunk etj. Serverët CI automatizojnë menaxhimin e pipeline-ve të komplikuara me shumë hapa. Një tundim i zakonshëm është për të krijuar një skenar për një grup përditësimesh Kubernetes dhe ta ekzekutojë atë si një pjesë të pipeline për të pushuar ndryshimet në klaster. Në të vërtetë, shumë specialistë e bëjnë këtë. Sidoqoftë, kjo nuk është optimale, dhe ja pse.

CI duhet të përdoret për të bërë përditësime në trunk, dhe klasteri Kubernetes duhet ta ndryshojë veten në bazë të këtyre përditësimeve për të menaxhuar CD "brenda". Ne e quajmë këtë model tërheqës për CD, në kundërshtim me modelin e CI push. CD është pjesë e orkestrimit në kohë.

Pse serverët CI nuk duhet të kryejnë CD përmes përditësimeve të drejtpërdrejta në Kubernetes

Mos e përdorni serverin CI për të orkestruar përditësime të drejtpërdrejta në Kubernetes si një grup detyrash CI. Kjo është një anti-model, për të cilin ne vazhduam të flasim në blogun tonë.

Le të kthehemi te Alisa dhe Boba.

Me çfarë problemeve janë përballur ata? Serveri CI i Bobit aplikon ndryshimet në klaster, por nëse gjatë procesit ai dështoi, Bobi nuk do të dijë në çfarë gjendjeje është (apo duhet të jetë) klasteri dhe si ta rregullojë atë. E njëjta gjë është e vërtetë dhe në rast suksesi.

Le të supozojmë se ekipi i Bobit ka ndërtuar një imazh të ri dhe pastaj e ka ndërlidhur shpërndarjet e tij për të shpërndarë imazhin (të gjitha këto nga pipeline CI).

Nëse imazhi ngarkohet normalisht, por pipeline dështoi, ekipi do të duhet të zbulojë:

  • A u shpĂ«rndan pĂ«rditĂ«simi?
  • A po ekzekutojmĂ« njĂ« ndĂ«rtim tĂ« ri? A do tĂ« çojĂ« kjo nĂ« efekte anĂ«sore tĂ« panevojshme - me mundĂ«sinĂ« e marrjes sĂ« dy ndĂ«rtimeve tĂ« tĂ« njĂ«jtit imazh tĂ« pandryshuar?
  • A duhet tĂ« presim njĂ« tjetĂ«r pĂ«rditĂ«sim para se tĂ« ekzekutojmĂ« ndĂ«rtimin?
  • ÇfarĂ« saktĂ«sisht shkoi keq? CilĂ«t hapa duhet tĂ« pĂ«rsĂ«riten (dhe cilĂ«t prej tyre mund tĂ« pĂ«rsĂ«riten me siguri)?

Organizimi i një procesi pune të bazuar në Git nuk garanton që ekipi i Bobit nuk do të përballet me këto probleme. Ata përsëri mund të bëjnë gabime me push-in e commit-it, me tag-un ose ndonjë parametër tjetër; megjithatë, ky qasje është shumë më afër një qasje të qartë all-or-nothing.

Për të përmbledhur, ja pse serverët CI nuk duhet të merren me CD:

  • Skripti i pĂ«rditĂ«simit nuk Ă«shtĂ« gjithmonĂ« i pĂ«rcaktuar; Ă«shtĂ« e lehtĂ« pĂ«r tĂ« bĂ«rĂ« gabime.
  • ServerĂ«t CI nuk konvergojnĂ« nĂ« modelin deklarativ tĂ« klasterit.
  • Eshte e vĂ«shtirĂ« tĂ« garantosh idempotencĂ«n. PĂ«rdoruesit duhet tĂ« kuptojnĂ« semantikĂ«n e thellĂ« tĂ« sistemit.
  • Ă«shtĂ« mĂ« e vĂ«shtirĂ« tĂ« kryhet rikuperimi pas njĂ« dĂ«shtimi tĂ« pjesshĂ«m.

Shënim mbi Helm: nëse dëshironi të përdorni Helm, ne rekomandojmë ta kombinoni me një operator GitOps, siç është Flux-Helm. Kjo do të ndihmojë në sigurimin e konvergjencës. Në vetvete, Helm nuk është as determinist, as atomic.

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

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

Modeli i operimit për Kubernetes.

Shikoni diagramin e mëposhtëm. Ai paraqet Git dhe depot e imazheve të konteinerëve si burime të zakonshme për dy ciklet e orkestruar:

  • Pipeline i integrimit tĂ« vazhdueshĂ«m, i cili lexon dhe shkruan skedarĂ« nĂ« Git dhe mund tĂ« azhurnohet depoja e imazheve tĂ« konteinerĂ«ve.
  • Pipeline i Runtime GitOps, qĂ« kombinon deploy-in me menaxhimin dhe vĂ«zhgimin. Ai lexon dhe shkruan skedarĂ« nĂ« Git dhe mund tĂ« ngarkojĂ« imazhe konteinerĂ«sh.

Cilat janë përfundimet kryesore?

  1. Ndara e problemeve: Vini re se të dy pipeline-t mund të shkëmbejnë të dhëna duke azhurnuar vetëm Git-in ose depot e imazheve. Në fjalë të tjera, ekziston një firewall në mes CI dhe ambientit të runtime. Ne e quajmë këtë "firewall të pavendosshmërisë" (immutability firewall), pasi të gjitha azhurnimet e depove krijojnë versione të reja. Për informacion shtesë mbi këtë temë, ju lutemi referojuni faqeve 72-87. këtë prezantim.
  2. Mund të përdoret ç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, depot e imazheve dhe paketat e testimeve. Praktikisht të gjitha mjetet e tjera për Continuous Delivery në treg kërkojnë CI-/Git-serverin e tyre ose deposit e imazheve. Kjo mund të bëhet një faktor përcaktues në zhvillimin e cloud native. Në rastin e GitOps, ju mund të përdorni mjetet që keni zakon.
  3. Ngjarjet si njĂ« mjet integrimi: Sa herĂ« qĂ« tĂ« dhĂ«nat nĂ« Git azhurnohet, Weave Flux (ose operatori Weave Cloud) e informon kĂ«tĂ« runtime. Çdo herĂ« qĂ« Kubernetes pranon njĂ« grup ndryshimesh, Git azhurnohet. Kjo siguron njĂ« model tĂ« thjeshtĂ« integrimi pĂ«r organizimin e proceseve pĂ«r GitOps, siç tregohet mĂ« poshtĂ«.

PĂ«rfundimi

GitOps ofron garantion e rëndësishme të azhurnimit, e nevojshme për çdo mjet modern CI/CD:

  • automatik;
  • konvergjencĂ«;
  • idempotencĂ«;
  • determinizĂ«m.

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

  • Mjetet tradicionale pĂ«r menaxhimin dhe vĂ«zhgimin e sistemeve janĂ« tĂ« lidhura me ekipet e operacioneve qĂ« veprojnĂ« brenda njĂ« runbook-u (grupi i procedurave rutinore dhe operacioneve — shĂ«nim i pĂ«rkthyesit), e lidhur me njĂ« deployment tĂ« caktuar.
  • NĂ« menaxhimin e sistemeve cloud native, mjetet pĂ«r vĂ«zhgimin janĂ« mĂ«nyra mĂ« e mirĂ« pĂ«r tĂ« vlerĂ«suar rezultatet e deployment-eve, nĂ« mĂ«nyrĂ« qĂ« ekipi i zhvilluesve tĂ« mund tĂ« reagojĂ« shpejt.

Imagjinoni shumë klasterë të shpërndarë në disa cloud dhe shumë shërbime me ekipet e tyre dhe planet e tyre të deployment-it. GitOps ofron një model të invariancës në shkallë 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 lutemi.

A e dinit për GitOps para këtyre dy përkthimeve në Habrë?

  • Po, e dija gjithçka

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

  • Jo

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

Burimi: habr.com

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