Ohar. itzul.: Duela gutxi argitalpen baten ondoren GitOps-en pull eta push metodoei buruz, eredu honi buruzko interesa ikusi genuen orokorrean, baina gai honi buruzko errusierazko argitalpen gutxi zeuden (habren ez dago besterik gabe). Horregatik, atsegin handiz eskaintzen dizugu beste artikulu baten itzulpena - duela ia urtebete bada ere! - Weaveworks-ekoa, zeinaren buruak "GitOps" terminoa asmatu zuen. Testuak planteamenduaren funtsa eta daudenekiko desberdintasun nagusiak azaltzen ditu.
Duela urtebete argitaratu genuen . Orduan, Weaveworks taldeak Kubernetes-en guztiz oinarritutako SaaS bat abiarazi zuen eta hodeiko jatorrizko ingurune batean hedatzeko, kudeatzeko eta monitorizatzeko praktika egokien multzo bat garatu genuen.
Artikulua ezaguna izan zen. Beste pertsona batzuk GitOps-i buruz hitz egiten hasi ziren eta tresna berriak argitaratzen hasi ziren , , , , eta abar. Gure webgunean agertu da argitalpenak eta GitOps erabilera kasuak. Baina batzuek oraindik galderak dituzte. Zertan desberdintzen da eredua tradizionalarekin? eta etengabeko entrega ()? Beharrezkoa al da Kubernetes erabiltzea?
Laster konturatu ginen deskribapen berri bat behar zela, eskainiz:
- Adibide eta istorio ugari;
- GitOps-en definizio espezifikoa;
- Etengabeko entrega tradizionalarekin alderatzea.
Artikulu honetan gai hauek guztiak lantzen saiatu gara. GitOps-en sarrera eguneratua eta garatzaileen eta CI/CD ikuspegia eskaintzen du. Kubernetesen zentratzen gara batez ere, nahiz eta eredua orokortu daitekeen.
Ezagutu GitOps
Imajinatu Alice. Familia aseguruak zuzentzen ditu, eta osasun, auto, etxe eta bidaia aseguruak eskaintzen dizkie kontratuen nondik norakoak beraiek okupatuta dauden pertsonei. Bere negozioa alboko proiektu gisa hasi zen Alice banku batean lanean ari zela datu-zientzialari gisa. Egun batean konturatu zen algoritmo informatiko aurreratuak erabil zezakeela datuak modu eraginkorragoan aztertzeko eta aseguru paketeak formulatzeko. Inbertitzaileek finantzatu zuten proiektua, eta orain bere konpainiak urtean 20 milioi dolar baino gehiago ekartzen ditu eta azkar hazten ari da. Gaur egun, 180 pertsonari ematen dio lana hainbat postutan. Webgunea, datu-basea garatzen, mantentzen eta bezero-basea aztertzen duen talde teknologikoa barne hartzen du. 60 laguneko taldea Bob konpainiaren zuzendari teknikoa da.
Bob-en taldeak produkzio sistemak hodeian zabaltzen ditu. Beren oinarrizko aplikazioak GKEn exekutatzen dira, Google Cloud-eko Kubernetes aprobetxatuz. Horrez gain, hainbat datu eta analisi-tresna erabiltzen dituzte beren lanean.
Familia Aseguruak ez zuen edukiontzirik erabili nahi, baina Dockerren ilusioak harrapatu zuen. Konpainiak laster aurkitu zuen GKEk eginbide berriak probatzeko klusterrak inplementatzea errazten zuela. CI eta Quay-rako Jenkins gehitu ziren edukiontzien erregistroa antolatzeko, eta edukiontzi eta konfigurazio berriak GKEra eraman zituzten Jenkinsentzako scriptak idatzi ziren.
Denbora pixka bat pasa da. Alice eta Bob etsita zeuden aukeratutako ikuspegiaren errendimenduarekin eta negozioan zuen eraginarekin. Edukiontzien sarrerak ez zuen produktibitatea hobetu taldeak espero zuen bezainbeste. Batzuetan inplementazioak apurtzen ziren, eta ez zegoen argi kode-aldaketak errua ziren ala ez. Gainera, zaila izan da konfigurazio-aldaketen jarraipena egitea. Askotan kluster berri bat sortu eta hara aplikazioak mugitzea beharrezkoa izaten zen, hori baitzen sistema bihurtutako nahaspila kentzeko modurik errazena. Alice beldur zen aplikazioa garatu ahala egoerak okerrera egingo ote zuen (gainera, ikaskuntza automatikoan oinarritutako proiektu berri bat sortzen ari zen). Bobek lanaren zatirik handiena automatizatu zuen eta ez zuen ulertzen zergatik zegoen hoditeria oraindik ezegonkorra, ez zen ondo eskalatzen eta eskuzko esku-hartzea behar zuen aldian-aldian?
Ondoren, GitOps-en berri izan zuten. Erabaki hau konfiantzaz aurrera egiteko behar zutena izan zen.
Alicek eta Bobek urteak daramatzate Git, DevOps eta azpiegiturak kode-fluxu gisa entzuten. GitOps-en berezitasuna da ideia horiek Kubernetes-en testuinguruan inplementatzeko praktika onen multzo bat ekartzen duela, behin betikoak eta arauzkoak. Gai hau , barne .
Familia Aseguruak GitOps ezartzea erabakitzen du. Konpainiak orain Kubernetesekin bateragarria den funtzionamendu-eredu automatizatu bat du eta konbinatzen ditu abiadura batera egonkortasunazeren eta:
- taldearen produktibitatea bikoiztu egin zela ikusi zuen inor erotu gabe;
- gidoiak hornitzeari utzi zion. Horren ordez, orain eginbide berrietan zentratu eta ingeniaritza-metodoak hobetu ditzakete; adibidez, kanariar inplementazioak sartzea eta probak hobetzea;
- zabaltze-prozesua hobetu dugu, gutxitan matxuratu dadin;
- Eskuzko esku-hartzerik gabe hutsegite partzialen ondoren inplementazioak leheneratzeko aukera izan zuen;
- erositako erabiliaΠΎEntrega-sistemetan konfiantza handiagoa. Alicek eta Bobek taldea paraleloan lan egiten duten mikrozerbitzu taldeetan banatu zezaketela aurkitu zuten;
- Proiektuan 30-50 aldaketa egin ditzake egunero talde bakoitzaren ahaleginaren bidez eta teknika berriak probatu;
- Erraza da proiektura garatzaile berriak erakartzea, zeinak ordu gutxiren buruan tira-eskaerak erabiliz produkziorako eguneraketak zabaltzeko aukera baitute;
- SOC2ren esparruan auditoria erraz gainditu (zerbitzu-hornitzaileek datuen kudeaketa segururako eskakizunak betetzeko; irakurri gehiago, adibidez, - gutxi gorabehera. itzul.).
Zer gertatu da?
GitOps bi gauza dira:
- Kubernetes eta hodeiko natiborako eredu operatiboa. Praktika egokien multzoa eskaintzen du edukiontzidun klusterrak eta aplikazioak hedatzeko, kudeatzeko eta monitorizatzeko. Definizio dotorea forman tik :
- Garatzaileetan oinarritutako aplikazioen kudeaketa-ingurune bat sortzeko bidea. Git lan-fluxua eragiketetan zein garapenean aplikatzen dugu. Kontuan izan hau ez dela Git push-a soilik, CI/CD eta UI/UX tresnen multzo osoa antolatzea baizik.
Git-i buruzko hitz batzuk
Bertsioak kontrolatzeko sistemak eta Git-en oinarritutako lan-fluxua ezagutzen ez badituzu, horiei buruz ikastea gomendatzen dizugu. Sukurtsalekin eta tira-eskaerekin lan egitea magia beltza dirudi hasieran, baina onurek merezi dute ahalegina. Hemen hasteko.
Kubernetes-ek nola funtzionatzen duen
Gure istorioan, Alice eta Bob-ek GitOps-era jo zuten Kubernetesekin denbora batez lan egin ostean. Izan ere, GitOps Kubernetesekin oso lotuta dago - Kubernetesen oinarritutako azpiegitura eta aplikazioetarako eredu operatiboa da.
Zer ematen die Kubernetes erabiltzaileei?
Hona hemen ezaugarri nagusi batzuk:
- Kubernetes ereduan, dena deklarazio moduan deskriba daiteke.
- Kubernetes API zerbitzariak deklarazio hau hartzen du sarrera gisa eta gero etengabe saiatzen da clusterra deklarazioan deskribatutako egoerara eramaten.
- Adierazpenak nahikoak dira hainbat lan-karga deskribatzeko eta kudeatzeko: "aplikazioak".
- Ondorioz, aplikazioan eta klusterrean aldaketak gertatzen dira:
- edukiontzien irudien aldaketak;
- deklarazio-zehaztapenean aldaketak;
- ingurumeneko akatsak - adibidez, edukiontzi-hondatzeak.
Kubernetesen Konbergentzia Gaitasun Handiak
Administratzaile batek konfigurazio-aldaketak egiten dituenean, Kubernetes orkestratzaileak klusterrean aplikatuko ditu, bere egoera dagoen bitartean. ez da konfigurazio berrira hurbilduko. Eredu honek Kubernetes-eko edozein baliabidetarako balio du eta baliabide pertsonalizatuen definizioekin (CRD) zabal daiteke. Hori dela eta, Kubernetes inplementazioek propietate zoragarri hauek dituzte:
- automatizazioa: Kubernetesen eguneratzeek aldaketak dotorez eta garaiz aplikatzeko prozesua automatizatzeko mekanismo bat eskaintzen dute.
- Konbergentzia: Kubernetes-ek eguneratzen saiatzen jarraituko du arrakasta arte.
- Idempotentzia: Konbergentziaren aplikazio errepikatuek emaitza bera lortzen dute.
- Determinismoa: Baliabideak nahikoak direnean, eguneratutako klusterraren egoera nahi den egoeraren araberakoa da soilik.
GitOps-ek nola funtzionatzen duen
Kubernetesi buruz nahikoa ikasi dugu GitOps-ek nola funtzionatzen duen azaltzeko.
Itzuli gaitezen Familia Aseguruen mikrozerbitzuen taldeetara. Zer egin behar dute normalean? Begiratu beheko zerrenda (bertan dauden elementuren bat arraroa edo ezezaguna iruditzen bazaizu, mesedez, eutsi kritikarik eta geratu gurekin). Hauek Jenkinsen oinarritutako lan-fluxuen adibideak besterik ez dira. Beste tresnekin lan egitean beste prozesu asko daude.
Gauza nagusia da ikusten dugula eguneratze bakoitza konfigurazio fitxategietan eta Git biltegietan aldaketekin amaitzen dela. Git-en egindako aldaketa hauek "GitOps operadoreak" kluster eguneratzea eragiten dute:
1. Lan prozesua: "Jenkins eraikitzea - ββadar maisua'.
Zereginen zerrenda:
- Jenkinsek etiketatutako irudiak Quay-ra bultzatzen ditu;
- Jenkinsek konfigurazioa eta Helm diagramak bultzatzen ditu biltegiratze-ontzi nagusira;
- Hodeiko funtzioak konfigurazioa eta diagramak kopiatzen ditu biltegiratze-ontzi nagusitik Git biltegi nagusira;
- GitOps operadoreak clusterra eguneratzen du.
2. Jenkins eraikitzea - ββaskatu edo konponketa-adarra:
- Jenkinsek etiketarik gabeko irudiak eramaten ditu Quay-ra;
- Jenkinsek konfigurazioa eta Helm diagramak bultzatzen ditu eszenaratzeko biltegiratze-ontzira;
- Hodeiko funtzioak konfigurazioa eta diagramak kopiatzen ditu eszenatze-biltegiratze-ontzitik eszenatze Git biltegira;
- GitOps operadoreak clusterra eguneratzen du.
3. Jenkins eraiki - garatu edo ezaugarri adar:
- Jenkinsek etiketarik gabeko irudiak eramaten ditu Quay-ra;
- Jenkinsek konfigurazioa eta Helm diagramak bultzatzen ditu garapen biltegiratze-ontzira;
- Hodeiko funtzioak konfigurazioa eta diagramak garatzeko biltegiratze-ontzitik garatzeko Git biltegira kopiatzen ditu;
- GitOps operadoreak clusterra eguneratzen du.
4. Bezero berri bat gehitzea:
- Kudeatzaileak edo administratzaileak (LCM/ops) Gradle-ri deitzen dio hasiera batean sareko karga-orekatzaileak (NLB) zabaltzeko eta konfiguratzeko;
- LCM/ops-ek konfigurazio berri bat konprometitzen du inplementazioa eguneratzeetarako prestatzeko;
- GitOps operadoreak clusterra eguneratzen du.
GitOps-en deskribapen laburra
- Deskribatu sistema osoaren nahi den egoera ingurune bakoitzeko zehaztapen deklaratiboak erabiliz (gure istorioan, Bob-en taldeak sistemaren konfigurazio osoa definitzen du Git-en).
- Git biltegia sistema osoaren nahi den egoerari buruzko egiaren iturri bakarra da.
- Nahi den egoeraren aldaketa guztiak Git-en konpromezuen bidez egiten dira.
- Nahi diren kluster-parametro guztiak klusterean bertan ere ikus daitezke. Modu honetan bat datozen (konbergente, elkarren) edo desberdina (desberdintasuna, aldendu) nahi eta ikusitako egoerak.
- Nahi diren eta ikusitako egoerak desberdinak badira, orduan:
- Badago konbergentzia-mekanismo bat lehenago edo beranduago helburu eta behatutako egoerak automatikoki sinkronizatzen dituena. Kluster barruan, Kubernetesek hau egiten du.
- Prozesua berehala hasten da "aldaketa konpromisoa" alerta batekin.
- Konfigura daitekeen denbora-tarte baten ondoren, "dif" alerta bat bidali daiteke egoera desberdinak badira.
- Modu honetan, Git-eko konpromezu guztiek kluster eguneratze egiaztagarriak eta idempotenteak eragiten dituzte.
- Rollback aldez aurretik nahi den egoera batera konbergentzia da.
- Konbergentzia behin betikoa da. Bere agerraldia honako hauek adierazten dute:
- Ez dago diferentzia-alertarik denbora-tarte jakin batean.
- "konbergentzia" alerta (adibidez, webhook, Git writeback gertaera).
Zer da dibergentzia?
Errepikatu dezagun berriro: nahi diren kluster propietate guztiak klusterean bertan behatu behar dira.
Dibergentziaren adibide batzuk:
- Konfigurazio fitxategian aldaketa Git-en adarrak bat egiteagatik.
- Konfigurazio fitxategian aldaketa bat GUI bezeroak egindako Git konpromezu baten ondorioz.
- Git-en PR-ren ondorioz nahi duzun egoeran hainbat aldaketa egin ondoren edukiontziaren irudia eta konfigurazio aldaketak eraikiz.
- Klusterren egoera aldaketa bat, errore baten ondorioz, baliabideen gatazkaren ondorioz, "portaera txarra" edo, besterik gabe, jatorrizko egoeratik ausazko desbideratzea.
Zein da konbergentziaren mekanismoa?
Adibide batzuk:
- Edukiontzi eta klusterrentzat, konbergentzia mekanismoa Kubernetes-ek ematen du.
- Mekanismo bera erabil daiteke Kubernetesen oinarritutako aplikazioak eta diseinuak kudeatzeko (esaterako, Istio eta Kubeflow).
- Kubernetes, irudi biltegien eta Git-en arteko interakzio operatiboa kudeatzeko mekanismo bat eskaintzen du , parte dena .
- Oinarrizko makinentzat, konbergentzia-mekanismoak deklaratiboa eta autonomoa izan behar du. Gure esperientziatik esan dezakegu hori definizio horretatik hurbilen dagoena, baina hala ere gizakiaren kontrola eskatzen du. Zentzu honetan, GitOps-ek Azpiegituraren tradizioa Kode gisa zabaltzen du.
GitOps-ek Git Kubernetes-en konbergentzia motor bikainarekin konbinatzen du ustiapen eredu bat eskaintzeko.
GitOps-ek esateko aukera ematen digu: Deskribatu eta beha daitezkeen sistemak bakarrik automatizatu eta kontrolatu daitezke.
GitOps hodeiko jatorrizko pila osorako pentsatuta dago (adibidez, Terraform, etab.)
GitOps ez da Kubernetes bakarrik. Sistema osoa modu deklaratiboan gidatzea eta konbergentzia erabiltzea nahi dugu. Sistema osoarekin Kubernetesekin lan egiten duten inguruneen bilduma esan nahi dugu - adibidez, "dev cluster 1", "produkzioa", etab. Ingurune bakoitzak makinak, klusterrak, aplikazioak eta datuak eskaintzen dituzten kanpoko zerbitzuetarako interfazeak barne hartzen ditu. eta abar.
Kontuan izan zein garrantzitsua den Terraform kasu honetan bootstrapping arazorako. Kubernetes nonbait zabaldu behar da, eta Terraform erabiliz, GitOps lan-fluxu berberak aplika ditzakegu Kubernetes eta aplikazioak oinarri dituen kontrol-geruza sortzeko. Praktika onena erabilgarria da.
Kubernetesen gaineko geruzetan GitOps kontzeptuak aplikatzeko arreta handia dago. Momentu honetan, GitOps motako irtenbideak daude Istio, Helm, Ksonnet, OpenFaaS eta Kubeflow-entzat, baita Pulumirentzat ere, hodeiko natiborako aplikazioak garatzeko geruza bat sortzen dutenak.
Kubernetes CI/CD: GitOps beste ikuspegi batzuekin alderatzea
Esan bezala, GitOps bi gauza dira:
- Goian deskribatutako Kubernetes eta hodeiko natiboaren funtzionamendu-eredua.
- Garatzaileetan oinarritutako aplikazioak kudeatzeko ingurunerako bidea.
Askorentzat, GitOps Git bultzadetan oinarritutako lan-fluxua da batez ere. Guk ere gustatzen zaigu. Baina hori ez da guztia: ikus ditzagun orain CI/CD kanalizazioak.
GitOps-ek Kubernetesentzako etengabeko hedapena (CD) ahalbidetzen du
GitOps-ek etengabeko inplementazio-mekanismo bat eskaintzen du, "inplementazio-kudeaketarako sistema" bereizien beharra ezabatzen duena. Kubernetes-ek zure alde egiten du lan guztia.
- Aplikazioa eguneratzeko Git-en eguneratu behar da. Hau nahi den egoerarako transakzio-eguneratzea da. "Inplementazioa" Kubernetes-ek berak egiten du kluster barruan, eguneratutako deskribapenean oinarrituta.
- Kubernetes-en funtzionamenduaren izaera dela eta, eguneratze hauek konbergenteak dira. Honek etengabeko hedapenerako mekanismo bat eskaintzen du, zeinetan eguneratze guztiak atomikoak diren.
- Oharra: Git eta Kubernetes integratzen dituen GitOps operadore bat eskaintzen du eta CD-a egiteko aukera ematen du klusterraren egoera nahi eta uneko egoera bateratuz.
Kubectl eta gidoirik gabe
Kubectl erabiltzea saihestu behar duzu zure clusterra eguneratzeko, eta batez ere kubectl komandoak taldekatzeko script-ak erabiltzea saihestu. Horren ordez, GitOps kanalizazioarekin, erabiltzaile batek bere Kubernetes klusterra egunera dezake Git bidez.
Abantailen artean daude:
- Eskuin. Eguneratze-talde bat aplikatu, bat egin eta azkenik balioztatu daiteke, hedapen atomikoaren helburura hurbilduz. Aitzitik, script-ak erabiltzeak ez du konbergentzia bermerik ematen (behean honi buruzko informazio gehiago).
- ΠΠ΅Π·ΠΎΠΏΠ°ΡΠ½ΠΎΡΡΡ. Kelsey Hightower: "Mugatu zure Kubernetes klustererako sarbidea arazketaz edo mantentzeaz arduratzen diren automatizazio tresnei eta administratzaileei". ikusi ere segurtasunari eta zehaztapen teknikoak betetzeari buruz, baita Jenkinsen gidoi kontu handiz idatzitako kredentzialak lapurtuz.
- Erabiltzaile Esperientzia. Kubectl-ek Kubernetes objektu-ereduaren mekanika erakusten du, nahiko konplexuak direnak. Egokiena, erabiltzaileek abstrakzio maila altuago batean elkarreragin beharko lukete sistemarekin. Hemen berriro Kelseyri erreferentzia egingo diot eta ikustea gomendatuko dut .
CI eta CDaren arteko aldea
GitOps-ek lehendik dauden CI/CD ereduak hobetzen ditu.
CI zerbitzari modernoa orkestrazio tresna bat da. Bereziki, CI kanalizazioak orkestratzeko tresna da. Besteak beste, eraikitzea, probatzea, enborrekin bateratzea, etab. CI zerbitzariek urrats anitzeko kanalizazio konplexuen kudeaketa automatizatzen dute. Ohiko tentazioa da Kubernetes-en eguneratze-multzo bat idaztea eta kanalizazio baten zati gisa exekutatu klusterrean aldaketak bultzatzeko. Izan ere, hori da aditu askok egiten dutena. Hala ere, hau ez da optimoa, eta hona hemen zergatik.
CI erabili behar da eguneraketak enborrera bultzatzeko, eta Kubernetes klusterrak bere burua aldatu beharko luke eguneratze horietan oinarrituta CDa barne kudeatzeko. Guk deitzen diogu , CI push eredua ez bezala. CDa parte da exekuzio-orkestrazioa.
Zergatik CI zerbitzariek ez dituzte CDak Kubernetes-en zuzeneko eguneratzeen bidez egin behar
Ez erabili CI zerbitzaririk Kubernetesen zuzeneko eguneraketak orkestratzeko CI lan multzo gisa. Hau da hitz egiten ari garen kontrako eredua zure blogean.
Itzuli gaitezen Alice eta Bobengana.
Zein arazo izan zituzten? Bob-en CI zerbitzariak aldaketak aplikatzen ditu klusterrean, baina prozesuan huts egiten badu, Bob-ek ez du jakingo zein egoeratan dagoen (edo egon behar duen) klusterra edo nola konpondu. Gauza bera gertatzen da arrakasta izanez gero.
Demagun Bob-en taldeak irudi berri bat eraiki zuela eta gero bere inplementazioak adabaki zituela irudia zabaltzeko (dena CI kanaletik).
Irudia normal eraikitzen bada, baina kanalizazioak huts egiten badu, taldeak asmatu beharko du:
- Eguneraketa zabaldu al da?
- Eraikuntza berri bat martxan jartzen al dugu? Horrek alferrikako bigarren mailako efektuak ekarriko al ditu, irudi aldaezin beraren bi eraikuntza edukitzeko aukerarekin?
- Hurrengo eguneraketa itxaron behar al dugu eraikuntza exekutatu aurretik?
- Zer gertatu zen zehazki? Zein pauso errepikatu behar dira (eta zeintzuk dira seguru errepikatzeko)?
Git-en oinarritutako lan-fluxu bat ezartzeak ez du bermatzen Bob-en taldeak arazo hauekin topatuko ez dituenik. Oraindik akatsen bat egin dezakete commit push-arekin, etiketarekin edo beste parametroren batekin; hala ere, ikuspegi hori dena edo ezer ez den ikuspegi esplizitu batetik askoz hurbilago dago oraindik.
Laburbilduz, hona hemen zergatik CI zerbitzariek ez lukete CD-rekin landu behar:
- Eguneratze-gidoiak ez dira beti deterministak; Erraza da haietan akatsak egitea.
- CI zerbitzariak ez dira bat egiten deklarazio-kluster eredura.
- Zaila da inpotentzia bermatzea. Erabiltzaileek sistemaren semantika sakona ulertu behar dute.
- Zailagoa da hutsegite partzial batetik berreskuratzea.
Helm-i buruzko oharra: Helm erabili nahi baduzu, GitOps operadore batekin konbinatzea gomendatzen dugu, esaterako. . Horrek konbergentzia ziurtatzen lagunduko du. Helm bera ez da ez determinista ez atomikoa.
GitOps Kubernetes-en Etengabeko Entrega ezartzeko modurik onena da
Alice eta Bob-en taldeak GitOps inplementatzen du eta software produktuekin lan egitea, errendimendu handia eta egonkortasuna mantentzea askoz errazagoa dela deskubritzen du. Buka dezagun artikulu hau haien ikuspegi berria nolakoa den erakusten duen ilustrazio batekin. Kontuan izan gehienbat aplikazio eta zerbitzuez ari garela, baina GitOps plataforma oso bat kudeatzeko erabil daiteke.
Kubernetesen funtzionamendu-eredua
Begira ezazu hurrengo diagrama. Git eta edukiontziaren irudi-biltegia bi bizi-ziklo orkestratuetarako partekatutako baliabide gisa aurkezten ditu:
- Git-en fitxategiak irakurtzen eta idazten dituen etengabeko integrazio kanalizazioa eta edukiontzien irudien biltegi bat egunera dezake.
- Inplementazioa kudeaketa eta behagarritasuna konbinatzen dituen Runtime GitOps kanalizazioa. Git-en fitxategiak irakurtzen eta idazten ditu eta edukiontzien irudiak deskarga ditzake.
Zeintzuk dira aurkikuntza nagusiak?
- Kezkak bereiztea: Kontuan izan bi kanalizazioak Git edo irudi biltegia eguneratuz soilik komunika daitezkeela. Beste era batera esanda, suebaki bat dago CI eta exekuzio-ingurunearen artean. "Mutaezintasuneko suebakia" deitzen diogu (mudaezintasun suebakia), biltegiaren eguneratze guztiek bertsio berriak sortzen baitituzte. Gai honi buruzko informazio gehiago lortzeko, jo 72-87 diapositibak .
- Edozein CI eta Git zerbitzari erabil dezakezu: GitOps-ek edozein osagairekin funtzionatzen du. Zure CI eta Git zerbitzari gogokoenak, irudi-biltegiak eta proba-multzoak erabiltzen jarrai dezakezu. Merkatuan dauden Etengabeko Bidalketa-tresna ia guztiek beren CI/Git zerbitzaria edo irudi-biltegia behar dute. Hau hodeiko natiboaren garapenean faktore mugatzailea izan daiteke. GitOps-ekin, tresna ezagunak erabil ditzakezu.
- Gertaerak integrazio tresna gisa: Git-eko datuak eguneratu bezain laster, Weave Flux (edo Weave Cloud operadoreak) exekuzio-denbora jakinarazten du. Kubernetes-ek aldaketa multzo bat onartzen duen bakoitzean, Git eguneratzen da. Honek integrazio-eredu sinple bat eskaintzen du GitOps-en lan-fluxuak antolatzeko, behean erakusten den moduan.
Ondorioa
GitOps-ek edozein CI/CD tresna modernoek eskatzen duten eguneratze-berme sendoak eskaintzen ditu:
- automatizazioa;
- konbergentzia;
- inpotentzia;
- determinismoa.
Garrantzitsua da hodeiko jatorrizko garatzaileentzako eredu operatibo bat eskaintzen duelako.
- Sistemak kudeatzeko eta monitorizatzeko tresna tradizionalak runbook baten barruan jarduten duten operazio taldeekin lotzen dira (ohiko prozedura eta eragiketa multzoa - gutxi gorabehera), hedapen zehatz bati lotuta.
- Hodeiko jatorrizko kudeaketan, behagarritasun-tresnak dira inplementazioen emaitzak neurtzeko modurik onena, garapen-taldeak azkar erantzun dezan.
Imajinatu hodei ezberdinetan eta zerbitzu askotan sakabanatuta dauden kluster asko beren talde eta inplementazio planekin. GitOps-ek eskala aldaezina den eredu bat eskaintzen du ugaritasun hori guztia kudeatzeko.
PS itzultzailetik
Irakurri ere gure blogean:
- «»;
- «»;
- Β«'.
Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. , mesedez.
Ba al zenekien GitOps-en berri bi itzulpen hauek HabrΓ©-n agertu aurretik?
-
Bai, dena banekien
-
Azaletik bakarrik
-
No
35 erabiltzailek eman dute botoa. 10 erabiltzaile abstenitu ziren.
Iturria: www.habr.com