Ohar. itzul.: Kubernetes komunitatean, GitOps izeneko joera bat ospea irabazten ari da, pertsonalki ikusi dugunez, KubeCon Europe 2019. Termino hau nahiko berria zen Weaveworks-eko buruak - Alexis Richardson - eta garatzaileek ezagutzen dituzten tresnak erabiltzea esan nahi du (batez ere Git, hortik datorkio izena) funtzionamendu-arazoak konpontzeko. Bereziki, Kubernetesen funtzionamenduaz ari gara bere konfigurazioak Git-en gordeta eta klusterrean aldaketak automatikoki zabalduz. Matthias Jg-ek inplementazio honen bi ikuspegiri buruz hitz egiten du artikulu honetan.
Azken urtean (Izan ere, formalki hori 2017ko abuztuan gertatu zen - gutxi gorabehera) Kubernetesen aplikazioak zabaltzeko ikuspegi berri bat dago. GitOps deitzen da, eta inplementazio-bertsioak Git biltegi baten ingurune seguruan jarraipena egiten duen oinarrizko ideian oinarritzen da.
Ikuspegi honen abantaila nagusiak hauek dira::
- Inplementazio bertsioa eta aldaketen historia. Kluster osoaren egoera Git biltegi batean gordetzen da, eta inplementazioak konpromezuen bidez soilik eguneratzen dira. Horrez gain, aldaketa guztien jarraipena egin daiteke konpromisoen historia erabiliz.
- Git komando ezagunak erabiliz atzera egiten du. Sinplea
git resetinplementazioetan aldaketak berrezartzeko aukera ematen du; iraganeko estatuak beti daude eskuragarri. - Sarbide-kontrola prest. Normalean, Git sistema batek datu sentikor asko ditu, beraz, enpresa gehienek arreta berezia jartzen diote babesteari. Horren arabera, babes hori inplementazioak dituzten operazioei ere aplikatzen zaie.
- Inplementazioetarako politikak. Git sistema gehienek adarrez adar politikak onartzen dituzte natiboki; adibidez, pull-eskaerek soilik egunera dezakete masterra, eta aldaketak beste taldekide batek berrikusi eta onartu behar ditu. Sarbide-kontrolarekin gertatzen den bezala, politika berdinak aplikatzen dira inplementazioaren eguneraketei.
Ikus dezakezunez, GitOps metodoak onura asko ditu. Azken urtean, bi ikuspegik ospe berezia lortu dute. Bata push oinarritzen da, bestea pull oinarritzen da. Horiek aztertu aurretik, ikus ditzagun Kubernetes ohiko inplementazioak nolakoak diren.
Inplementazio-metodoak
Azken urteotan, Kubernetes-ek hainbat metodo eta tresna ezarri ditu inplementazioetarako:
- Kubernetes/Kustomize txantiloi natiboetan oinarrituta. Hau da Kubernetes-en aplikazioak zabaltzeko modurik errazena. Garatzaileak oinarrizko YAML fitxategiak sortzen ditu eta aplikatzen ditu. Txantiloi berdinak etengabe berridazteaz kentzeko, Kustomize garatu zen (Kubernetes txantiloiak modulu bihurtzen ditu). Ohar. itzul.: Kustomize kubectl-en integratu da .
- Helm Zerrendak. Helm diagramek txantiloi, init edukiontzi, sidecars, etab. multzoak sortzeko aukera ematen dute, txantiloietan oinarritutako ikuspegian baino pertsonalizazio aukera malguagoak dituzten aplikazioak zabaltzeko erabiltzen direnak. Metodo hau txantiloidun YAML fitxategietan oinarritzen da. Helm-ek hainbat parametroz betetzen ditu eta, ondoren, Tiller-era bidaltzen ditu, kluster-era zabaltzen dituen eta eguneratzeak eta atzerapenak ahalbidetzen dituen kluster osagaia. Garrantzitsua da Helm-ek, funtsean, nahi diren balioak txantiloietan txertatzen dituela eta, ondoren, ikuspegi tradizionalean egiten den modu berean aplikatzen dituela. (irakurri gehiago nola funtzionatzen duen eta nola erabil dezakezun gure - gutxi gorabehera. itzul.). Askotariko prestatutako Helm diagramak daude, zeregin ugari biltzen dituztenak.
- Erreminta alternatiboak. Erreminta alternatibo asko daude. Guztiek komunean dutena da txantiloi-fitxategi batzuk Kubernetesek irakur daitezkeen YAML fitxategi bihurtzen dituztela eta gero erabiltzen dituztela.
Gure lanean, etengabe erabiltzen ditugu Helm diagramak tresna garrantzitsuetarako (dagoeneko gauza asko baitituzte prest, eta horrek bizitza askoz errazten du) eta Kubernetes YAML fitxategi "garbiak" gure aplikazioak zabaltzeko.
Tira eta Bultza
Nire azken blogeko batean, tresna aurkeztu nuen , eta horrek aukera ematen dizu txantiloiak Git biltegira bidaltzeko eta edukiontziaren konpromezu edo bultzada bakoitzaren ondoren hedapena eguneratzeko. Nire esperientziak erakusten du tresna hau tira planteamendua sustatzeko nagusienetako bat dela, eta, beraz, askotan aipatuko dut. Erabilerari buruz gehiago jakin nahi baduzu, hemen .
NB! GitOps erabiltzearen onura guztiak berdinak izaten jarraitzen dute bi ikuspegietarako.
Tiran oinarritutako ikuspegia
Aldaketa guztiak kluster barrutik aplikatzen direnean oinarritzen da pull ikuspegia. Kluster barruan operadore bat dago erlazionatutako Git eta Docker Erregistroko biltegiak aldizka egiaztatzen dituena. Aldaketarik gertatzen bada, klusterraren egoera barnean eguneratzen da. Prozesu hau, oro har, oso segurutzat jotzen da, kanpoko bezero batek ez baitu klusterren administratzaile eskubideetarako sarbidea.
Pros:
- Kanpoko bezero batek ez du klusterrean aldaketak egiteko eskubiderik; eguneratze guztiak barrutik zabaltzen dira.
- Tresna batzuek Helm diagramen eguneraketak sinkronizatzeko eta klusterra lotzeko aukera ere ematen dute.
- Docker Erregistroa bertsio berrietarako eskaneatu daiteke. Irudi berri bat eskuragarri badago, Git biltegia eta hedapena bertsio berrira eguneratzen dira.
- Pull tresnak izen-espazio ezberdinetan banatu daitezke Git biltegi eta baimen ezberdinekin. Horri esker, maizte askoren eredua erabil daiteke. Adibidez, A taldeak A izen-espazioa erabil dezake, B taldeak B izen-espazioa erabil dezake eta azpiegitura taldeak espazio globala erabil dezake.
- Oro har, tresnak oso arinak dira.
- Operatzailea bezalako tresnekin konbinatuta , sekretuak Git biltegi batean zifratuta gorde daitezke eta kluster barruan berreskuratu.
- Ez dago CD kanalizazioekin konexiorik, inplementazioak kluster barruan gertatzen direnez.
Cons:
- Helm zerrendetako hedapen-sekretuak kudeatzea ohikoak baino zailagoa da, lehenik eta behin, esate baterako, sekretu zigilatuen moduan sortu behar baitira, gero barne-operadore batek deszifratu, eta, ondoren, tira-tresnaren eskura jartzen baitira. Ondoren Helm-en bertsioa exekutatu dezakezu dagoeneko zabaldutako sekretuetako balioekin. Modurik errazena hedatzeko erabiltzen diren Helm balio guztiekin sekretu bat sortzea da, deszifratzea eta Git-en konprometitzea.
- Tire hurbilketa bat hartzen duzunean, tira tresnak lotzen zara. Horrek kluster batean inplementazio-prozesua pertsonalizatzeko gaitasuna mugatzen du. Adibidez, Kustomize konplikatua da azken txantiloiak Git-ekin konprometitu aurretik exekutatu behar duelako. Ez dut esaten tresna autonomoak erabili ezin dituzunik, baina zailagoa da zure inplementazio-prozesuan integratzea.
Push oinarritutako ikuspegia
Push ikuspegian, kanpoko sistema batek (batez ere CD kanalizazioak) klusterra inplementazioak abiarazten ditu Git biltegian konprometitu ondoren edo aurreko CI kanalizazioa arrakastatsua bada. Planteamendu honetan, sistemak klustererako sarbidea du.
Pros:
- Segurtasuna Git biltegiak eta eraikitze kanalizazioak zehazten du.
- Helm diagramak zabaltzea errazagoa da eta Helm pluginak onartzen ditu.
- Sekretuak errazago kudeatzen dira, sekretuak kanalizazioetan erabil daitezkeelako eta Git-en zifratuta ere gorde daitezkeelako (erabiltzailearen hobespenen arabera).
- Ez dago tresna zehatz batekin konexiorik, edozein motatakoa erabil baitaiteke.
- Edukiontziaren bertsioen eguneraketak eraikitze kanalizazioak abiarazi ditzake.
Cons:
- Klusterren sarbide-datuak eraikuntza-sistemaren barruan daude.
- Inplementazio-ontziak eguneratzea oraindik errazagoa da tira-prozesu batekin.
- CD sistemarekiko menpekotasun handia, behar ditugun kanalizazioak jatorriz Gitlab Runnersentzat idatziak izan daitezkeelako, eta orduan taldeak Azure DevOps edo Jenkinsera joatea erabakitzen du... eta eraikitze kanalizazio ugari migratu beharko ditu.
Emaitzak: Push al Pull?
Normalean gertatzen den bezala, ikuspegi bakoitzak bere alde onak eta txarrak ditu. Zeregin batzuk errazago betetzen dira batekin eta zailagoa beste batekin. Hasieran eskuz inplementazioak egiten ari nintzen, baina Weave Flux-i buruzko artikulu batzuk topatu ondoren, proiektu guztietarako GitOps prozesuak ezartzea erabaki nuen. Oinarrizko txantiloietarako hau erraza izan zen, baina gero zailtasunekin hasi nintzen Helm diagramekin. Garai hartan, Weave Flux-ek Helm Chart Operator-aren bertsio oinarrizkoa baino ez zuen eskaintzen, baina orain ere zeregin batzuk zailagoak dira sekretuak eskuz sortu eta aplikatzeko beharragatik. Argudia dezakezu pull ikuspegia askoz seguruagoa dela, klusterren kredentzialak ez direlako klusteretik kanpo eskuragarri, eta horrek nahikoa segurtasuna hobetzen du aparteko ahalegina merezi izan dezan.
Pentsatu ondoren, ustekabeko ondoriora iritsi nintzen ez dela horrela. Babes maximoa eskatzen duten osagaiez hitz egiten badugu, zerrenda honek biltegiratze sekretua, CI/CD sistemak eta Git biltegiak barne hartuko ditu. Horien barruan dagoen informazioa oso ahula da eta babes handiena behar du. Gainera, norbait zure Git biltegian sartzen bada eta bertan kodea bultza badezake, nahi duena inplementa dezake (tira edo push izan) eta klusterreko sistemetan infiltratu. Beraz, babestu behar diren osagai garrantzitsuenak Git biltegia eta CI/CD sistemak dira, ez klusterreko kredentzialak. Sistema mota hauetarako politikak eta segurtasun-kontrolak ondo konfiguratuta badituzu, eta klusterren kredentzialak kanalizazioetan soilik ateratzen badira sekretu gisa, baliteke tira-ikuspegiaren segurtasun gehigarriak hasiera batean uste bezain baliotsua ez izatea.
Beraz, pull ikuspegia lan intentsiboagoa bada eta ez badu segurtasun onurarik ematen, ez al da logikoa push ikuspegia soilik erabiltzea? Baina norbaitek esan dezake push planteamenduan CD sistemari lotuegi zaudela eta, agian, hobe dela hori ez egitea, etorkizunean migrazioak egitea errazagoa izan dadin.
Nire ustez (beti bezala), kasu jakin baterako edo konbinatu egokiena dena erabili beharko zenuke. Pertsonalki, bi ikuspegiak erabiltzen ditut: Weave Flux, gehienbat gure zerbitzuak barne hartzen dituzten pull-oinarritutako inplementazioetarako, eta push ikuspegia Helm eta pluginekin, zeinak Helm diagramak klusterrean aplikatzea errazten duena eta sekretuak modu errazean sortzeko aukera ematen duena. Uste dut inoiz ez dela egongo kasu guztietarako egokia den irtenbide bakarra, beti baitaude Γ±abardura asko eta aplikazio zehatzaren araberakoak direlako. Hori esanda, GitOps gomendatzen dut - bizitza asko errazten du eta segurtasuna hobetzen du.
Espero dut gai honi buruz dudan esperientziak zure inplementazio motarako zein metodo egokiena den erabakitzen lagunduko dizula eta zure iritzia entzutea poztuko nuke.
PS itzultzailearen oharra
Tira-ereduaren alde txarra da errendatutako manifestuak Git-en jartzea zaila dela, baina tira-ereduaren CD kanalizazioa inplementazioarengandik bereizita bizi den eta funtsean kategoria-bide bihurtzea da. Etengabeko aplikazioa. Hori dela eta, are gehiago esfortzua beharko da inplementazio guztietatik haien egoera biltzeko eta nolabait erregistro/egoera sarbidea emateko, ahal izanez gero CD sistemari erreferentzia eginez.
Zentzu honetan, bultzada ereduari esker, gutxienez hedatzeko berme batzuk eskaintzea ahalbidetzen dugu, hodiaren iraupena zabalkundearen iraupenaren berdina izan daitekeelako.
Bi ereduak probatu eta artikuluaren egilearen ondorio berdinetara iritsi ginen:
- Pull eredua egokia da sistemaren osagaien eguneraketak antolatzeko kluster ugaritan (ikus. ).
- GitLab CI-n oinarritutako push eredua Helm diagramak erabiliz aplikazioak zabaltzeko egokia da. Aldi berean, kanalizazioen inplementazioen hedapena kontrolatzen da tresna erabiliz . Bide batez, gure proiektu honen testuinguruan, etengabeko βGitOpsβ entzun genuen DevOps ingeniarien arazo larriei buruz eztabaidatu genuenean KubeCon Europe'19-ko gure standean.
PPS itzultzailearen eskutik
Irakurri ere gure blogean:
- «»;
- «»;
- «»;
- Β«'.
Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. , mesedez.
GitOps erabiltzen ari al zara?
-
Bai, tira hurbilketa
-
Bai, bultzatu
-
Bai, tira + bultza
-
Bai, beste zerbait
-
No
30 erabiltzailek eman dute botoa. 10 erabiltzaile abstenitu ziren.
Iturria: www.habr.com