Notu. transl.: En la komunumo de Kubernetes, tendenco nomita GitOps akiras evidentan popularecon, kiel ni persone vidis, KubeCon Eŭropo 2019. Ĉi tiu termino estis relative lastatempa de la estro de Weaveworks - Alexis Richardson - kaj signifas la uzon de iloj konataj al programistoj (ĉefe Git, de tie la nomo) por solvi funkciajn problemojn. Aparte, ni parolas pri la funkciado de Kubernetes stokante ĝiajn agordojn en Git kaj aŭtomate eligante ŝanĝojn al la grapolo. Matthias Jg parolas pri du aliroj al ĉi tiu lanĉo en ĉi tiu artikolo.
Lasta jaro (fakte, formale tio okazis en aŭgusto 2017 - ĉ. trad.) Estas nova aliro al deplojado de aplikoj en Kubernetes. Ĝi nomiĝas GitOps, kaj ĝi baziĝas sur la baza ideo, ke deplojversioj estas spuritaj en la sekura medio de Git-deponejo.
La ĉefaj avantaĝoj de ĉi tiu aliro estas kiel sekvas::
- Deploja versio kaj ŝanĝhistorio. La stato de la tuta areto estas stokita en Git-deponejo, kaj deplojoj estas ĝisdatigitaj nur per kommits. Krome, ĉiuj ŝanĝoj povas esti spuritaj uzante la commit-historion.
- Rollbacks uzante konatajn Git-komandojn. Simpla
git resetpermesas vin restarigi ŝanĝojn en deplojoj; pasintaj ŝtatoj ĉiam disponeblas. - Preta alirkontrolo. Kutime, Git-sistemo enhavas multajn sentivajn datumojn, do plej multaj kompanioj atentas ĝin por protekti ĝin. Sekve, ĉi tiu protekto ankaŭ validas por operacioj kun deplojoj.
- Politikoj por Deplojoj. Plej multaj Git-sistemoj denaske subtenas branĉo-post-branĉajn politikojn—ekzemple, nur tiraj petoj povas ĝisdatigi majstron, kaj ŝanĝoj devas esti reviziitaj kaj akceptitaj de alia grupano. Kiel ĉe alirkontrolo, la samaj politikoj validas por deploj ĝisdatigoj.
Kiel vi povas vidi, estas multaj avantaĝoj al la metodo GitOps. Dum la pasinta jaro, du aliroj akiris specialan popularecon. Unu estas puŝbazita, la alia estas tirbazita. Antaŭ ol ni rigardu ilin, ni unue rigardu kiel aspektas tipaj Kubernetes-deplojoj.
Deplojaj Metodoj
En la lastaj jaroj, diversaj metodoj kaj iloj por deplojoj establiĝis en Kubernetes:
- Surbaze de denaskaj Kubernetes/Kustomize ŝablonoj. Ĉi tio estas la plej facila maniero por disfaldi aplikaĵojn sur Kubernetes. La programisto kreas la bazajn YAML-dosierojn kaj aplikas ilin. Por forigi konstante reverkadon de la samaj ŝablonoj, Kustomize estis evoluigita (ĝi transformas Kubernetes-ŝablonojn en modulojn). Notu. transl.: Kustomize estis integrita en kubectl kun .
- Helm Charts. Helm-diagramoj permesas krei arojn de ŝablonoj, initujoj, kromĉaroj, ktp., kiuj estas uzataj por disfaldi aplikaĵojn kun pli flekseblaj agordaj elektoj ol en ŝablono-bazita aliro. Ĉi tiu metodo baziĝas sur ŝablonoj YAML-dosieroj. Helm plenigas ilin per diversaj parametroj kaj poste sendas ilin al Tiller, areto-komponento, kiu deplojas ilin al la areto kaj permesas ĝisdatigojn kaj malfunkciigon. La grava afero estas, ke Helm esence nur enigas la deziratajn valorojn en la ŝablonojn kaj poste aplikas ilin same kiel ĝi estas farita en la tradicia aliro. (legu pli pri kiel ĉio funkcias kaj kiel vi povas uzi ĝin en nia - ĉ. traduk.). Estas ampleksa vario de pretaj Helm-diagramoj kovrantaj larĝan gamon de taskoj.
- Alternativaj Iloj. Estas multaj alternativaj iloj. Kion ili ĉiuj havas komune estas, ke ili transformas kelkajn ŝablonajn dosierojn en Kubernetes-legeblajn YAML-dosierojn kaj poste uzas ilin.
En nia laboro, ni konstante uzas Helm-diagramojn por gravaj iloj (ĉar ili havas multajn aferojn jam pretajn, kio plifaciligas la vivon) kaj "purajn" Kubernetes-YAML-dosierojn por disfaldi niajn proprajn aplikojn.
Tiri & Puŝo
En unu el miaj lastatempaj blogaj afiŝoj, mi prezentis la ilon , kiu ebligas al vi transigi ŝablonojn al la Git-deponejo kaj ĝisdatigi la deplojon post ĉiu transdono aŭ antaŭenpuŝo de la ujo. Mia sperto montras, ke ĉi tiu ilo estas unu el la ĉefaj por antaŭenigi la tiran aliron, do mi ofte raportos al ĝi. Se vi volas scii pli pri kiel uzi ĝin, ĉi tie .
NB! Ĉiuj avantaĝoj de uzado de GitOps restas la samaj por ambaŭ aliroj.
Tiro bazita aliro
La tira aliro estas bazita sur la fakto ke ĉiuj ŝanĝoj estas aplikitaj de ene de la areto. Estas funkciigisto ene de la areto, kiu regule kontrolas la rilatajn deponejojn de Git kaj Docker Registry. Se iuj ŝanĝoj okazas al ili, la stato de la areto estas ĝisdatigita interne. Ĉi tiu procezo estas ĝenerale konsiderata kiel tre sekura, ĉar neniu ekstera kliento havas aliron al la rajtoj de administranto de grapo.
Pros:
- Neniu ekstera kliento havas rajtojn fari ŝanĝojn al la areto; ĉiuj ĝisdatigoj estas lanĉitaj de interne.
- Iuj iloj ankaŭ permesas al vi sinkronigi ĝisdatigojn pri Helm-diagramo kaj ligi ilin al la areto.
- Docker Registry povas esti skanita por novaj versioj. Se nova bildo estas havebla, la Git-deponejo kaj deplojo estas ĝisdatigitaj al la nova versio.
- Tiraj iloj povas esti distribuitaj tra malsamaj nomspacoj kun malsamaj Git-deponejoj kaj permesoj. Danke al ĉi tio, modelo de plurtenanto povas esti uzata. Ekzemple, teamo A povus uzi nomspacon A, teamo B povus uzi nomspacon B, kaj la infrastrukturteamo povus uzi tutmondan spacon.
- Kiel regulo, la iloj estas tre malpezaj.
- Kombinite kun iloj kiel operatoro , sekretoj povas esti stokitaj ĉifrite en Git-deponejo kaj prenitaj ene de la areto.
- Ekzistas neniu ligo al KD-duktoj ĉar deplojoj okazas ene de la areto.
Miksoj:
- Administri deplojajn sekretojn de Helm-diagramoj estas pli malfacila ol ordinaraj, ĉar ili unue devas esti generitaj en formo de, ekzemple, sigelitaj sekretoj, poste deĉifritaj de interna funkciigisto, kaj nur post tio ili fariĝas disponeblaj al la tira ilo. Tiam vi povas ruli la eldonon en Helm kun la valoroj en la jam deplojitaj sekretoj. La plej facila maniero estas krei sekreton kun ĉiuj Helm-valoroj uzataj por deplojo, deĉifri ĝin kaj transigi ĝin al Git.
- Kiam vi prenas tiran alproksimiĝon, vi fariĝas ligita por tiri ilojn. Ĉi tio limigas la kapablon personecigi la deplojan procezon en areto. Ekzemple, Kustomize estas malfaciligita pro la fakto, ke ĝi devas funkcii antaŭ ol la finaj ŝablonoj estas engaĝitaj al Git. Mi ne diras, ke vi ne povas uzi memstarajn ilojn, sed ili estas pli malfacile integreblaj en via deploja procezo.
Puŝo bazita aliro
En la puŝa aliro, ekstera sistemo (ĉefe KD-duktoj) lanĉas deplojojn al la areto post kompromiso al la Git-deponejo aŭ se la antaŭa CI-dukto estas sukcesa. En ĉi tiu aliro, la sistemo havas aliron al la areto.
Puloj:
- Sekureco estas determinita de la Git-deponejo kaj konstrua dukto.
- Deploji Helm-diagramojn estas pli facila kaj subtenas Helm-kromaĵojn.
- Sekretoj estas pli facile administreblaj ĉar sekretoj povas esti uzitaj en duktoj kaj ankaŭ povas esti stokitaj ĉifrite en Git (depende de la preferoj de la uzanto).
- Ne estas konekto al specifa ilo, ĉar ajna tipo povas esti uzata.
- Ujversiaj ĝisdatigoj povas esti iniciatitaj per la konstrudukto.
Miksoj:
- La alirdatumoj de grapo estas ene de la konstrusistemo.
- Ĝisdatigi deplojajn ujojn ankoraŭ estas pli facila kun tira procezo.
- Peza dependeco de la KD-sistemo, ĉar la duktoj, kiujn ni bezonas, eble estis origine skribitaj por Gitlab Runners, kaj tiam la teamo decidas translokiĝi al Azure DevOps aŭ Jenkins... kaj devos migri grandan nombron da konstruoduktoj.
Rezultoj: Puŝi aŭ Tiri?
Kiel kutime, ĉiu aliro havas siajn avantaĝojn kaj malavantaĝojn. Iuj taskoj estas pli facile plenumeblaj kun unu kaj pli malfacilaj kun alia. Komence mi faris deplojojn permane, sed post kiam mi trovis kelkajn artikolojn pri Weave Flux, mi decidis efektivigi GitOps-procezojn por ĉiuj projektoj. Por bazaj ŝablonoj tio estis facila, sed tiam mi ekhavis malfacilaĵojn kun Helm-diagramoj. Tiutempe, Weave Flux nur ofertis rudimentan version de la Helm Chart Operator, sed eĉ nun iuj taskoj estas pli malfacilaj pro la bezono permane krei sekretojn kaj apliki ilin. Vi povus argumenti, ke la tira aliro estas multe pli sekura ĉar la akreditaĵoj de la areto ne estas alireblaj ekster la areto, igante ĝin multe pli sekura ke ĝi valoras la ekstran penon.
Post iom da pripensado, mi venis al la neatendita konkludo, ke tio ne estas tiel. Se ni parolas pri komponantoj, kiuj postulas maksimuman protekton, ĉi tiu listo inkludos sekretan stokadon, CI/KD-sistemojn kaj Git-deponejojn. La informoj en ili estas tre vundeblaj kaj bezonas maksimuman protekton. Aldone, se iu eniras vian Git-deponejon kaj povas puŝi kodon tie, ili povas disfaldi kion ajn ili volas (ĉu ĝi estas tiri aŭ puŝi) kaj infiltri la sistemojn de la areto. Tiel, la plej gravaj komponentoj, kiuj devas esti protektitaj, estas la Git-deponejo kaj CI/KD-sistemoj, ne la akreditaĵoj pri grapo. Se vi havas bone agorditajn politikojn kaj sekurecajn kontrolojn por ĉi tiuj specoj de sistemoj, kaj akreditaĵoj pri grapo estas nur ĉerpitaj en duktoj kiel sekretoj, la aldonita sekureco de tira aliro eble ne estas tiel valora kiel origine pensis.
Do, se la tira aliro estas pli laborintensa kaj ne provizas sekurecan avantaĝon, ĉu ne estas logike uzi nur la puŝon? Sed iu povus argumenti, ke en la puŝa aliro vi estas tro ligita al la KD-sistemo kaj, eble, estas pli bone ne fari tion, por ke estos pli facile efektivigi migradojn estonte.
Laŭ mi (kiel ĉiam), vi devus uzi tion, kio plej taŭgas por aparta kazo aŭ kombini. Persone, mi uzas ambaŭ alirojn: Weave Flux por tir-bazitaj deplojoj, kiuj plejparte inkluzivas niajn proprajn servojn, kaj puŝan aliron kun Helm kaj kromaĵojn, kiuj faciligas apliki Helm-diagramojn al la areto kaj ebligas vin krei sekretojn perfekte. Mi pensas, ke neniam estos ununura solvo taŭga por ĉiuj kazoj, ĉar ĉiam estas multaj nuancoj kaj ili dependas de la specifa apliko. Dirite, mi tre rekomendas GitOps - ĝi multe pli facilas la vivon kaj plibonigas sekurecon.
Mi esperas, ke mia sperto pri ĉi tiu temo helpos vin decidi, kiu metodo pli taŭgas por via speco de disfaldo, kaj mi ĝojus aŭdi vian opinion.
PS Noto de la tradukinto
La malavantaĝo de la tira modelo estas, ke estas malfacile meti bilditajn manifestojn en Git, sed ne estas malavantaĝo, ke la KD-dukto en la tira modelo vivas aparte de la lanĉo kaj esence fariĝas kategorio-dukto. Daŭre Apliki. Tial, eĉ pli da peno estos postulata por kolekti ilian statuson de ĉiuj deplojoj kaj iel disponigi aliron al protokoloj/statuso, prefere rilate al la KD-sistemo.
Tiusence, la puŝmodelo permesas al ni disponigi almenaŭ iujn garantiojn de lanĉo, ĉar la vivdaŭro de la dukto povas esti egala al la vivdaŭro de la lanĉo.
Ni provis ambaŭ modelojn kaj venis al la samaj konkludoj kiel la aŭtoro de la artikolo:
- La tira modelo taŭgas por ni organizi ĝisdatigojn de sistemaj komponantoj sur granda nombro da aretoj (vidu. ).
- La puŝmodelo bazita sur GitLab CI taŭgas por lanĉi aplikaĵojn per Helm-diagramoj. Samtempe, la disvolvado de disfaldoj ene de duktoj estas monitorita per la ilo . Cetere, en la kunteksto de ĉi tiu nia projekto, ni aŭdis la konstantan "GitOps" kiam ni diskutis la urĝajn problemojn de DevOps-inĝenieroj ĉe nia stando ĉe KubeCon Europe'19.
PPS de tradukisto
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «»;
- «".
Nur registritaj uzantoj povas partopreni la enketon. , bonvolu.
Ĉu vi uzas GitOps?
-
Jes, tiri alproksimiĝon
-
Jes, puŝu
-
Jes, tiri + puŝi
-
Jes, io alia
-
Neniu
30 uzantoj voĉdonis. 10 uzantoj sindetenis.
fonto: www.habr.com