Notu. transl.: Post lastatempa publikigo pri tiraj kaj puŝaj metodoj en GitOps, ni ĝenerale vidis intereson pri ĉi tiu modelo, sed estis tre malmultaj ruslingvaj publikaĵoj pri ĉi tiu temo (estas simple neniuj ĉe Habré). Tial ni ĝojas proponi al via atento tradukon de alia artikolo – kvankam antaŭ preskaŭ unu jaro! - de Weaveworks, kies kapo kreis la esprimon "GitOps". La teksto klarigas la esencon de la aliro kaj ŝlosilajn diferencojn de ekzistantaj.
Antaŭ unu jaro ni publikigis . Tiam ni konigis kiel la teamo de Weaveworks lanĉis SaaS tute bazitan sur Kubernetes kaj evoluigis aron de preskribaj plej bonaj praktikoj por disfaldi, administri kaj monitori en nuba indiĝena medio.
La artikolo montriĝis populara. Aliaj homoj komencis paroli pri GitOps kaj komencis eldoni novajn ilojn por , , , , kaj tiel plu. Aperis en nia retejo publikaĵoj kaj GitOps uzkazoj. Sed kelkaj homoj ankoraŭ havas demandojn. Kiel la modelo diferencas de la tradicia? kaj daŭra livero ()? Ĉu necesas uzi Kubernetes?
Ni baldaŭ rimarkis, ke necesas nova priskribo, proponante:
- Granda nombro da ekzemploj kaj rakontoj;
- Specifa difino de GitOps;
- Komparo kun tradicia kontinua liverado.
En ĉi tiu artikolo ni provis kovri ĉiujn ĉi tiujn temojn. Ĝi disponigas ĝisdatigitan enkondukon al GitOps kaj programisto kaj CI/CD-perspektivo. Ni ĉefe koncentriĝas pri Kubernetes, kvankam la modelo povas esti ĝeneraligita.
Renkontu GitOps
Imagu Alicon. Ŝi administras Familian Asekuron, kiu ofertas sanan, aŭton, hejmon, kaj vojaĝasekuron al homoj kiuj estas tro okupataj por mem eltrovi la enojn de kontraktoj. Ŝia komerco komenciĝis kiel flankprojekto kiam Alice laboris en banko kiel datuma sciencisto. Iun tagon ŝi rimarkis, ke ŝi povas uzi altnivelajn komputilajn algoritmojn por pli efike analizi datumojn kaj formuli asekurpakaĵojn. Investantoj financis la projekton, kaj nun ŝia firmao alportas pli ol $ 20 milionojn jare kaj kreskas rapide. Nuntempe, ĝi dungas 180 homojn en diversaj postenoj. Ĉi tio inkluzivas teknologian teamon, kiu disvolvas, konservas la retejon, datumbazon kaj analizas la klientbazon. La teamo de 60 homoj estas gvidata de Bob, la teknika direktoro de la firmao.
La teamo de Bob deplojas produktadsistemojn en la nubo. Iliaj kernaj aplikaĵoj funkcias per GKE, utiligante Kubernetes en Google Cloud. Krome, ili uzas diversajn datumojn kaj analizajn ilojn en sia laboro.
Familia Asekuro ne volis uzi ujojn, sed kaptiĝis en la entuziasmo de Docker. La kompanio baldaŭ malkovris, ke GKE faciligis disfaldi grapojn por testi novajn funkciojn. Jenkins por CI kaj Quay estis aldonitaj por organizi la konteneran registron, skriptoj estis skribitaj por Jenkins, kiuj puŝis novajn ujojn kaj agordojn al GKE.
Iom da tempo pasis. Alice kaj Bob estis seniluziigitaj kun la prezento de ilia elektita aliro kaj ĝia efiko al la komerco. La enkonduko de ujoj ne plibonigis produktivecon tiom kiom la teamo esperis. Foje deplojoj rompiĝus, kaj estis neklare ĉu kodŝanĝoj estis kulpaj. Ankaŭ montriĝis malfacile spuri agordajn ŝanĝojn. Ofte estis necese krei novan areton kaj movi aplikaĵojn al ĝi, ĉar ĉi tio estis la plej facila maniero forigi la malordon, kiu fariĝis la sistemo. Alicio timis, ke la situacio plimalboniĝos dum la aplikaĵo disvolviĝas (krome kreiĝas nova projekto bazita sur maŝinlernado). Bob aŭtomatigis la plej grandan parton de la laboro kaj ne komprenis kial la dukto ankoraŭ estas malstabila, ne bone skalis kaj postulis manan intervenon periode?
Tiam ili lernis pri GitOps. Ĉi tiu decido montriĝis ĝuste tio, kion ili bezonis por memfide antaŭeniri.
Alice kaj Bob aŭdas pri Git, DevOps kaj infrastrukturo kiel kodaj laborfluoj dum jaroj. Kio estas unika pri GitOps estas, ke ĝi alportas aron da plej bonaj praktikoj - kaj definitivaj kaj normigaj - por efektivigi ĉi tiujn ideojn en la kunteksto de Kubernetes. Ĉi tiu temo , inkluzive en .
Familia Asekuro decidas efektivigi GitOps. La kompanio nun havas aŭtomatan operacian modelon kongruan kun Kubernetes kaj kombinas rapideco el stabilecoĉar ili:
- trovis ke la produktiveco de la teamo duobliĝis sen iu ajn freneziĝi;
- ĉesis servi skriptojn. Anstataŭe, ili nun povas koncentriĝi pri novaj funkcioj kaj plibonigi inĝenierajn metodojn - ekzemple, enkondukante kanariajn landojn kaj plibonigante testadon;
- ni plibonigis la deplojprocezon tiel ke ĝi malofte rompiĝas;
- ricevis la ŝancon restarigi deplojojn post partaj fiaskoj sen mana interveno;
- aĉetita uzataоPli granda konfido en liversistemoj. Alice kaj Bob malkovris ke ili povis dividi la teamon en mikroservteamojn laborantajn en paralela;
- povas fari 30-50 ŝanĝojn al la projekto ĉiutage per la klopodoj de ĉiu grupo kaj provi novajn teknikojn;
- estas facile altiri novajn programistojn al la projekto, kiuj havas la ŝancon eldoni ĝisdatigojn al produktado uzante tirajn petojn ene de kelkaj horoj;
- facile trapasi revizion en la kadro de SOC2 (por konformeco de servaj provizantoj kun postuloj por sekura administrado de datumoj; legu pli, ekzemple, - ĉ. traduk.).
Kio okazis?
GitOps estas du aferoj:
- Funkcia modelo por Kubernetes kaj denaska de la nubo. Ĝi disponigas aron de plej bonaj praktikoj por deploji, administri kaj monitori kontenerigitajn aretojn kaj aplikojn. Eleganta difino en la formo el :
- La vojo al kreado de ellaboranto-centra aplika administradmedio. Ni aplikas la Git-laborfluon al ambaŭ operacioj kaj disvolviĝo. Bonvolu noti, ke ĉi tio ne temas nur pri Git-puŝo, sed pri organizado de la tuta aro de CI/CD kaj UI/UX-iloj.
Kelkajn vortojn pri Git
Se vi ne konas versio-kontrolsistemojn kaj Git-bazitan laborfluon, ni tre rekomendas lerni pri ili. Labori kun branĉoj kaj tiraj petoj eble ŝajnas nigra magio komence, sed la avantaĝoj valoras la penon. Jen komenci.
Kiel funkcias Kubernetes
En nia rakonto, Alice kaj Bob turnis sin al GitOps post iom da tempo labori kun Kubernetes. Efektive, GitOps estas proksime rilata al Kubernetes - ĝi estas funkcia modelo por infrastrukturo kaj aplikoj bazitaj sur Kubernetes.
Kion Kubernetes donas al uzantoj?
Jen kelkaj ĉefaj trajtoj:
- En la Kubernetes-modelo, ĉio povas esti priskribita en deklara formo.
- La Kubernetes API-servilo prenas ĉi tiun deklaracion kiel enigaĵon kaj tiam daŭre provas alporti la areton en la staton priskribitan en la deklaro.
- Deklaroj sufiĉas por priskribi kaj administri ampleksan varion de laborkvantoj — "aplikaĵoj".
- Kiel rezulto, ŝanĝoj al la aplikaĵo kaj areto okazas pro:
- ŝanĝoj en ujbildoj;
- ŝanĝoj al la deklara specifo;
- eraroj en la medio - ekzemple ujo kraŝoj.
Grandaj Konverĝaj Kapabloj de Kubernetes
Kiam administranto faras agordajn ŝanĝojn, la orkestro de Kubernetes aplikos ilin al la areto kondiĉe ke ĝia stato estos ne proksimiĝos al la nova agordo. Ĉi tiu modelo funkcias por iu ajn rimedo de Kubernetes kaj estas etendebla kun Propraj Rimedaj Difinoj (CRDs). Tial, Kubernetes-deplojoj havas la jenajn mirindajn ecojn:
- Aŭtomatigo: Kubernetes-ĝisdatigoj provizas mekanismon por aŭtomatigi la procezon apliki ŝanĝojn gracie kaj ĝustatempe.
- Konverĝo: Kubernetes daŭre provos ĝisdatigojn ĝis sukceso.
- Idempotenco: Ripetaj aplikoj de konverĝo kondukas al la sama rezulto.
- Determinismo: Kiam rimedoj sufiĉas, la stato de la ĝisdatigita areto dependas nur de la dezirata stato.
Kiel GitOps funkcias
Ni lernis sufiĉe pri Kubernetes por klarigi kiel GitOps funkcias.
Ni revenu al la teamoj pri mikroservoj de Family Insurance. Kion ili kutime devas fari? Rigardu la malsupran liston (se iuj en ĝi ŝajnas stranga aŭ nekonata, bonvolu ne kritiki kaj resti ĉe ni). Ĉi tiuj estas nur ekzemploj de laborfluoj bazitaj en Jenkins. Estas multaj aliaj procezoj kiam oni laboras kun aliaj iloj.
La ĉefa afero estas, ke ni vidas, ke ĉiu ĝisdatigo finiĝas per ŝanĝoj al la agordaj dosieroj kaj Git-deponejoj. Ĉi tiuj ŝanĝoj al Git igas la "GitOps-funkciigiston" ĝisdatigi la areton:
1. Laborprocezo: "Jenkins konstruo - majstra branĉo".
Taskolisto:
- Jenkins puŝas etikeditajn bildojn al Quay;
- Jenkins puŝas konfig kaj Helm-diagramojn al la majstra stoka sitelo;
- La nuba funkcio kopias la agordojn kaj diagramojn de la majstra stoka sitelo al la majstra Git-deponejo;
- La GitOps-funkciigisto ĝisdatigas la areton.
2. Jenkins konstruo - liberigu aŭ varmecan branĉon:
- Jenkins puŝas neetikeditajn bildojn al Quay;
- Jenkins puŝas konfig kaj Helm-diagramojn al la ensceniga stoka sitelo;
- La nuba funkcio kopias la agordojn kaj diagramojn de la sursceniga stoka sitelo al la sursceniga Git-deponejo;
- La GitOps-funkciigisto ĝisdatigas la areton.
3. Jenkins konstruo - disvolvi aŭ prezentas branĉon:
- Jenkins puŝas neetikeditajn bildojn al Quay;
- Jenkins puŝas konfig kaj Helm-diagramojn en la evolui-stokan sitelon;
- La nuba funkcio kopias la agordojn kaj diagramojn de la evolu-stoka sitelo al la evolua Git-deponejo;
- La GitOps-funkciigisto ĝisdatigas la areton.
4. Aldonante novan klienton:
- La manaĝero aŭ administranto (LCM/ops) vokas Gradle por komence deploji kaj agordi retajn ŝarĝbalancilojn (NLB);
- LCM/ops faras novan agordon por prepari la deplojon por ĝisdatigoj;
- La GitOps-funkciigisto ĝisdatigas la areton.
Mallonga priskribo de GitOps
- Priskribu la deziratan staton de la tuta sistemo uzante deklarajn specifojn por ĉiu medio (en nia rakonto, la teamo de Bob difinas la tutan sisteman agordon en Git).
- La Git-deponejo estas la ununura fonto de vero pri la dezirata stato de la tuta sistemo.
- Ĉiuj ŝanĝoj al la dezirata stato estas faritaj per kommits en Git.
- Ĉiuj dezirataj aretparametroj ankaŭ estas observeblaj en la areto mem. Tiamaniere ni povas determini ĉu ili koincidas (konverĝas, konverĝi) aŭ malsamas (malsamiĝi, diverĝi) dezirataj kaj observitaj statoj.
- Se la dezirata kaj observita statoj malsamas, tiam:
- Ekzistas konverĝa mekanismo, kiu baldaŭ aŭ malfrue aŭtomate sinkronigas la celon kaj observitajn ŝtatojn. Ene de la areto, Kubernetes faras tion.
- La procezo komenciĝas tuj kun "ŝanĝo farita" atentigo.
- Post iu agordebla tempodaŭro, oni povas sendi "malsaman" alarmon se la statoj estas malsamaj.
- Tiel, ĉiuj kommitaĵoj en Git kaŭzas kontroleblajn kaj idempotentajn ĝisdatigojn al la areto.
- Rollback estas konverĝo al antaŭe dezirata stato.
- La konverĝo estas fina. Ĝia okazo estas indikita per:
- Neniuj diferencoj por certa tempodaŭro.
- "konverĝa" atentigo (ekz. rethook, Git writeback-okazaĵo).
Kio estas diverĝo?
Ni ripetu denove: ĉiuj dezirataj aretposedaĵoj devas esti observeblaj en la areto mem.
Kelkaj ekzemploj de diverĝo:
- Ŝanĝo en agorda dosiero pro kunfandado de branĉoj en Git.
- Ŝanĝo en la agorda dosiero pro Git-komisio farita de la GUI-kliento.
- Multoblaj ŝanĝoj al la dezirata stato pro PR en Git sekvataj de konstruado de la ujbildo kaj agordaj ŝanĝoj.
- Ŝanĝo en la stato de la areto pro eraro, rimedkonflikto rezultiganta "malbonan konduton", aŭ simple hazarda devio de la origina stato.
Kio estas la mekanismo de konverĝo?
Kelkaj ekzemploj:
- Por ujoj kaj aretoj, la konverĝa mekanismo estas provizita de Kubernetes.
- La sama mekanismo povas esti uzata por administri aplikojn kaj dezajnojn bazitajn en Kubernetes (kiel Istio kaj Kubeflow).
- Mekanismo por administri la funkcian interagon inter Kubernetes, bilddeponejoj kaj Git provizas , kiu estas parto .
- Por bazmaŝinoj, la konverĝa mekanismo devas esti deklara kaj aŭtonoma. El nia propra sperto ni povas diri tion plej proksima al ĉi tiu difino, sed ankoraŭ postulas homan kontrolon. En ĉi tiu senso, GitOps etendas la tradicion de Infrastrukturo kiel Kodo.
GitOps kombinas Git kun la bonega konverĝa motoro de Kubernetes por provizi modelon por ekspluatado.
GitOps permesas al ni diri: Nur tiuj sistemoj kiuj povas esti priskribitaj kaj observitaj povas esti aŭtomatigitaj kaj kontrolitaj.
GitOps estas celita por la tuta nuba indiĝena stako (ekzemple, Terraform, ktp.)
GitOps ne estas nur Kubernetes. Ni volas, ke la tuta sistemo estu kondukata deklara kaj uzu konverĝon. Per la tuta sistemo ni signifas kolekton de medioj laborantaj kun Kubernetes - ekzemple "dev-grupo 1", "produktado", ktp. Ĉiu medio inkluzivas maŝinojn, aretojn, aplikojn, kaj ankaŭ interfacojn por eksteraj servoj, kiuj provizas datumojn, monitoradon. kaj ktp.
Rimarku kiom gravas Terraform por la problemo pri ekfunkciigo en ĉi tiu kazo. Kubernetes devas esti deplojita ie, kaj uzi Terraform signifas, ke ni povas apliki la samajn GitOps-laborfluojn por krei la kontroltavolon, kiu subtenas Kubernetes kaj aplikaĵojn. Ĉi tio estas utila plej bona praktiko.
Estas forta fokuso pri aplikado de GitOps-konceptoj al tavoloj supre de Kubernetes. Nuntempe, ekzistas solvoj de tipo GitOps por Istio, Helm, Ksonnet, OpenFaaS kaj Kubeflow, kaj ankaŭ, ekzemple, por Pulumi, kiuj kreas tavolon por disvolvi aplikojn por denaskaj nuboj.
Kubernetes CI/CD: komparante GitOps kun aliaj aliroj
Kiel dirite, GitOps estas du aferoj:
- La mastruma modelo por Kubernetes kaj nubo denaska priskribita supre.
- La vojo al programisto-centra aplika administradmedio.
Por multaj, GitOps estas ĉefe laborfluo bazita sur Git-puŝoj. Ni ankaŭ ŝatas lin. Sed tio ne estas ĉio: ni nun rigardu CI/CD-duktojn.
GitOps ebligas kontinuan deplojon (KD) por Kubernetes
GitOps ofertas kontinuan deplojan mekanismon, kiu forigas la bezonon de apartaj "deplojaj administradsistemoj". Kubernetes faras la tutan laboron por vi.
- Ĝisdatigi la aplikaĵon postulas ĝisdatigon en Git. Ĉi tio estas transakcia ĝisdatigo al la dezirata stato. "Deplojo" tiam estas farita ene de la areto fare de Kubernetes mem surbaze de la ĝisdatigita priskribo.
- Pro la naturo de kiel funkcias Kubernetes, ĉi tiuj ĝisdatigoj konverĝas. Ĉi tio disponigas mekanismon por kontinua deplojo en kiu ĉiuj ĝisdatigoj estas atomaj.
- Notu: ofertas GitOps-funkciigiston, kiu integras Git kaj Kubernetes kaj ebligas ke KD estu farita per akordigo de la dezirata kaj aktuala stato de la areto.
Sen kubectl kaj skriptoj
Vi devus eviti uzi Kubectl por ĝisdatigi vian areton, kaj precipe eviti uzi skriptojn por grupigi kubectl-komandojn. Anstataŭe, kun la dukto GitOps, uzanto povas ĝisdatigi sian Kubernetes-areton per Git.
Avantaĝoj inkluzivas:
- Ĝuste. Grupo de ĝisdatigoj povas esti aplikata, konverĝita kaj finfine validigita, proksimigante nin al la celo de atoma deplojo. Kontraste, uzado de skriptoj ne provizas ajnan garantion de konverĝo (pli pri tio ĉi malsupre).
- Sekureco. Kelsey Hightower: "Limigu aliron al via Kubernetes-areo al aŭtomatigaj iloj kaj administrantoj, kiuj respondecas pri senararigado aŭ prizorgado de ĝi." Vidu ankaŭ pri sekureco kaj konformeco al teknikaj specifoj, same kiel ŝtelante akreditaĵojn de senzorge skribita Jenkins-skripto.
- Uzanto-Sperto. Kubectl elmontras la mekanikon de la objektmodelo Kubernetes, kiuj estas sufiĉe kompleksaj. Ideale, uzantoj devus interagi kun la sistemo sur pli alta nivelo de abstraktado. Ĉi tie mi denove raportos al Kelsey kaj rekomendos spekti .
Diferenco inter CI kaj KD
GitOps plibonigas ekzistantajn CI/CD-modelojn.
Moderna CI-servilo estas orkestra ilo. Aparte, ĝi estas ilo por reĝisori CI-duktojn. Ĉi tiuj inkluzivas konstrui, testi, kunfandi al trunko, ktp. CI-serviloj aŭtomatigas la administradon de kompleksaj plurpaŝaj duktoj. Ofta tento estas skribi aron de Kubernetes-ĝisdatigoj kaj ruli ĝin kiel parto de dukto por puŝi ŝanĝojn al la areto. Efektive, tion faras multaj spertuloj. Tamen ĉi tio ne estas optimuma, kaj jen kial.
CI devus esti uzata por puŝi ĝisdatigojn al la trunko, kaj la Kubernetes-areo devus ŝanĝi sin surbaze de tiuj ĝisdatigoj por administri la KD interne. Ni nomas ĝin , male al la CI-puŝmodelo. KD estas parto rultempa instrumentado.
Kial CI-Serviloj Ne Faru KD-ojn per Rektaj Ĝisdatigoj en Kubernetes
Ne uzu CI-servilon por reĝisori rektajn ĝisdatigojn al Kubernetes kiel aron de CI-laboroj. Jen la kontraŭŝablono pri kiu ni parolas sur via blogo.
Ni reiru al Alico kaj Bob.
Kiajn problemojn ili renkontis? La CI-servilo de Bob aplikas la ŝanĝojn al la areto, sed se ĝi kraŝas en la procezo, Bob ne scios en kiu stato estas (aŭ devus esti) la areto aŭ kiel ripari ĝin. La sama estas vera en kazo de sukceso.
Ni supozu, ke la teamo de Bob konstruis novan bildon kaj poste flikis siajn deplojojn por deploji la bildon (ĉio el la CI-dukto).
Se la bildo konstruas normale, sed la dukto malsukcesas, la teamo devos eltrovi:
- Ĉu la ĝisdatigo ruliĝis?
- Ĉu ni lanĉas novan konstruaĵon? Ĉu tio kondukos al nenecesaj kromefikoj - kun la ebleco havi du konstruojn de la sama neŝanĝebla bildo?
- Ĉu ni devus atendi la sekvan ĝisdatigon antaŭ ol ruli la konstruon?
- Kio ĝuste fuŝis? Kiuj paŝoj devas esti ripetitaj (kaj kiuj estas sekure ripeti)?
Establigi Git-bazitan laborfluon ne garantias, ke la teamo de Bob ne renkontos ĉi tiujn problemojn. Ili ankoraŭ povas fari eraron kun la kommit-puŝo, la etikedo aŭ iu alia parametro; tamen, ĉi tiu aliro daŭre estas multe pli proksima al eksplicita aliro ĉio-aŭ-nenio.
Por resumi, jen kial CI-serviloj ne devus trakti KD:
- Ĝisdatigskriptoj ne ĉiam estas determinismaj; Estas facile fari erarojn en ili.
- CI-serviloj ne konverĝas al la deklara clustermodelo.
- Estas malfacile garantii idempotencon. Uzantoj devas kompreni la profundan semantikon de la sistemo.
- Estas pli malfacile resaniĝi de parta fiasko.
Noto pri Helm: Se vi volas uzi Helm, ni rekomendas kombini ĝin kun GitOps-funkciigisto kiel ekzemple . Ĉi tio helpos certigi konverĝon. Helm mem estas nek determinisma nek atoma.
GitOps kiel la plej bona maniero efektivigi Kontinuan Liveron por Kubernetes
La teamo de Alice kaj Bob efektivigas GitOps kaj malkovras, ke fariĝis multe pli facile labori kun softvaraĵoj, konservi altan rendimenton kaj stabilecon. Ni finu ĉi tiun artikolon per ilustraĵo montranta kiel aspektas ilia nova aliro. Memoru, ke ni plejparte parolas pri aplikaĵoj kaj servoj, sed GitOps povas esti uzata por administri tutan platformon.
Funkcia modelo por Kubernetes
Rigardu la sekvan diagramon. Ĝi prezentas Git kaj la ujan bilddeponejon kiel komunajn rimedojn por du reĝisoritaj vivocikloj:
- Daŭra integriga dukto, kiu legas kaj skribas dosierojn al Git kaj povas ĝisdatigi deponejon de ujbildoj.
- Runtime GitOps-dukto, kiu kombinas deplojon kun administrado kaj observeblo. Ĝi legas kaj skribas dosierojn al Git kaj povas elŝuti ujajn bildojn.
Kio estas la ĉefaj trovoj?
- Apartigo de zorgoj: Bonvolu noti, ke ambaŭ duktoj povas komuniki nur ĝisdatigante Git aŭ la bilddeponejon. Alivorte, ekzistas fajroŝirmilo inter CI kaj la rultempa medio. Ni nomas ĝin la "neŝanĝebla fajroŝirmilo" (neŝanĝebla fajroŝirmilo), ĉar ĉiuj deponejo ĝisdatigoj kreas novajn versiojn. Por pliaj informoj pri ĉi tiu temo, vidu al lumbildoj 72-87 .
- Vi povas uzi ajnan CI kaj Git-servilon: GitOps funkcias kun iu ajn komponanto. Vi povas daŭre uzi viajn plej ŝatatajn CI kaj Git-servilojn, bilddeponejojn kaj testajn arojn. Preskaŭ ĉiuj aliaj Kontinuaj Liveraj iloj sur la merkato postulas sian propran CI/Git-servilon aŭ bilddeponejon. Ĉi tio povas fariĝi limiga faktoro en la disvolviĝo de nubo indiĝeno. Kun GitOps, vi povas uzi konatajn ilojn.
- Eventoj kiel integriga ilo: Tuj kiam datumoj en Git estas ĝisdatigitaj, Weave Flux (aŭ la Weave Cloud-funkciigisto) sciigas rultempon. Kiam ajn Kubernetes akceptas ŝanĝan aron, Git estas ĝisdatigita. Ĉi tio provizas simplan integrigan modelon por organizi laborfluojn por GitOps, kiel montrite sube.
konkludo
GitOps provizas la fortajn ĝisdatigajn garantiojn postulatajn de iu ajn moderna CI/CD-ilo:
- aŭtomatigo;
- konverĝo;
- idempotenco;
- determinismo.
Ĉi tio estas grava ĉar ĝi ofertas funkcian modelon por denaskaj programistoj de nubo.
- Tradiciaj iloj por administrado kaj monitorado de sistemoj estas rilataj al operaciaj teamoj funkciigantaj ene de rullibro (aro da rutinaj proceduroj kaj operacioj - ĉ. traduk.), ligita al specifa deplojo.
- En denaska administrado de nubo, observeblaj iloj estas la plej bona maniero por mezuri la rezultojn de deplojoj por ke la evolua teamo povu respondi rapide.
Imagu multajn aretojn disigitajn tra malsamaj nuboj kaj multaj servoj kun siaj propraj teamoj kaj deplojplanoj. GitOps ofertas skal-senvarian modelon por administri ĉi tiun tutan abundon.
PS de tradukisto
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «".
Nur registritaj uzantoj povas partopreni la enketon. , bonvolu.
Ĉu vi sciis pri GitOps antaŭ ol ĉi tiuj du tradukoj aperis ĉe Habré?
-
Jes, mi sciis ĉion
-
Nur supraĵe
-
Neniu
35 uzantoj voĉdonis. 10 uzantoj sindetenis.
fonto: www.habr.com