🥇Edukietan oinarritutako etiketatzea werf bilduman: zergatik eta nola funtzionatzen du?

werf Gure kode irekiko GitOps CLI utilitatea da Kubernetes aplikazioak eraikitzeko eta entregatzeko. IN askatu v1.1 ezaugarri berri bat sartu zen irudi-biltzailean: irudiak edukiaren arabera etiketatzea edo edukietan oinarritutako etiketatzea. Orain arte, werf-en etiketatze-eskema tipikoak Docker-en irudiak Git etiketa, Git adarra edo Git commit-en bidez etiketatzea zekarren. Baina eskema horiek guztiek etiketatze estrategia berriak guztiz konpontzen dituzten desabantailak dituzte. Horri buruzko xehetasunak eta zergatik den hain ona mozketan daude.

Git biltegi batetik mikrozerbitzu multzo bat zabaltzea

Egoera bat gertatzen da askotan aplikazio bat zerbitzu independente asko edo gutxiagotan banatzen denean. Zerbitzu horien kaleratzeak modu independentean gerta daitezke: zerbitzu bat edo gehiago kaleratu daitezke aldi berean, gainerakoek, berriz, aldaketarik gabe lanean jarraitu behar dute. Baina kodea biltegiratzearen eta proiektuen kudeaketaren ikuspuntutik, erosoagoa da aplikazio-zerbitzu horiek biltegi bakarrean mantentzea.

Zerbitzuak benetan independenteak diren eta aplikazio bakar batekin lotuta ez dauden egoerak daude. Kasu honetan, proiektu bereizietan kokatuko dira eta haiek kaleratzea CI/CD prozesu ezberdinen bidez gauzatuko da proiektu bakoitzean.

Hala ere, errealitatean, garatzaileek askotan aplikazio bakarra hainbat mikrozerbitzutan banatzen dute, baina bakoitzerako biltegi eta proiektu bereizi bat sortzea... gehiegikeria argia da. Egoera hau da gehiago eztabaidatuko dena: horrelako hainbat mikrozerbitzu proiektuen biltegi bakarrean kokatzen dira eta kaleratzeak prozesu bakar baten bidez gertatzen dira CI/CDn.

Etiketatzea Git adarraren eta Git etiketaren arabera

Demagun etiketatze-estrategia ohikoena erabiltzen dela - etiketa-edo-adarra. Git adarretarako, irudiak adarraren izenarekin etiketatzen dira, adar batentzat adar horren izenarekin argitaratutako irudi bakarra dago. Git etiketetarako, irudiak etiketaren izenaren arabera etiketatzen dira.

Git etiketa berri bat sortzen denean (adibidez, bertsio berri bat kaleratzen denean), Docker etiketa berri bat sortuko da Docker Erregistroko proiektuaren irudi guztientzat:

myregistry.org/myproject/frontend:v1.1.10
myregistry.org/myproject/myservice1:v1.1.10
myregistry.org/myproject/myservice2:v1.1.10
myregistry.org/myproject/myservice3:v1.1.10
myregistry.org/myproject/myservice4:v1.1.10
myregistry.org/myproject/myservice5:v1.1.10
myregistry.org/myproject/database:v1.1.10

Irudi-izen berri hauek Helm txantiloien bidez pasatzen dira Kubernetes konfiguraziora. Inplementazioa komandoarekin hastean werf deploy eremua eguneratzen ari da image Kubernetes baliabideen manifestuetan eta dagozkien baliabideak berrabiaraziz aldatutako irudiaren izena dela eta.

arazoa:, hain zuzen, irudiaren edukia aurreko inplementaziotik (Git etiketa) aldatu ez denean baizik eta Docker etiketa bakarrik, hau gertatzen da. gehigarria aplikazio hau berrabiarazten eta, horren ondorioz, geldialdiren bat egon daiteke. Berrabiarazi hau egiteko benetako arrazoirik ez zegoen arren.

Ondorioz, egungo etiketa-eskemarekin beharrezkoa da hainbat Git biltegi bereizi hesitzea eta hainbat biltegi horien zabaltzea antolatzeko arazoa sortzen da. Oro har, eskema hori gainkargatuta eta konplexua da. Hobe da zerbitzu asko biltegi bakarrean konbinatzea eta Docker etiketak sortzea, alferrikako berrabiarazi ez dadin.

Etiketatzea Git commit-en bidez

werf-ek Git-en konpromisoekin lotutako etiketatze-estrategia ere badu.

Git-commit Git biltegi bateko edukien identifikatzaile bat da eta Git biltegiko fitxategien edizio-historiaren araberakoa da, beraz, logikoa dirudi Docker Erregistroko irudiak etiketatzeko erabiltzea.

Hala ere, Git commit-ek etiketatzeak Git adarren edo Git etiketen etiketatzearen desabantaila berdinak ditu:

Fitxategirik aldatzen ez duen konpromiso huts bat sor liteke, baina irudiaren Docker etiketa aldatuko da.
Fitxategiak aldatzen ez dituen bateratze-konpromiso bat sor liteke, baina irudiaren Docker etiketa aldatuko da.
Irudian inportatzen ez diren Git-eko fitxategiak aldatzen dituen konpromezu bat egin liteke, eta irudiaren Docker etiketa aldatuko da berriro.

Git adarraren izena etiketatzeak ez du irudiaren bertsioa islatzen

Git adarren etiketatze-estrategiarekin lotutako beste arazo bat dago.

Adarren izenaren arabera etiketatzeak funtzionatzen du adar horretako konpromezuak sekuentzialki ordena kronologikoan biltzen badira.

Uneko eskeman erabiltzailea adar jakin batekin lotutako konpromiso zahar bat berreraikitzen hasten bada, orduan werf-ek irudia berridatziko du dagokion Docker etiketa erabiliz, konpromezu zaharraren irudiaren bertsio eraiki berri batekin. Hemendik aurrera etiketa hau erabiltzen duten inplementazioek irudiaren beste bertsio bat ateratzeko arriskua dute pod-ak berrabiaraztean, eta, ondorioz, gure aplikazioak CI sistemarekin konexioa galduko du eta desinkronizatu egingo da.

Gainera, elkarren artean denbora-tarte laburrean adar batean jarraian egindako bultzadak eginez, konpromezu zaharra berria baino beranduago konpilatu daiteke: irudiaren bertsio zaharrak berria gainidatziko du Git adarra etiketa erabiliz. Arazo horiek CI/CD sistema baten bidez ebatzi daitezke (adibidez, GitLab CI-n azken honen kanalizazioa abiarazten da konpromiso sorta baterako). Hala ere, sistema guztiek ez dute hori onartzen eta oinarrizko arazo hori saihesteko modu fidagarriagoa izan behar da.

Zer da edukietan oinarritutako etiketatzea?

Beraz, zer da edukietan oinarritutako etiketatzea - irudiak edukiaren arabera etiketatzea.

Docker etiketak sortzeko, ez dira Git primitiboak (Git adarra, Git etiketa...) erabiltzen direnak, honekin lotutako checksum bat baizik:

irudiaren edukia. Irudiaren ID etiketak bere edukia islatzen du. Bertsio berri bat eraikitzean, identifikatzaile hori ez da aldatuko irudiko fitxategiak aldatu ez badira;
Git-en irudi hau sortzeko historia. Git adar ezberdinekin eta werf bidez eraikitzeko historia ezberdinekin lotutako irudiek ID etiketa desberdinak izango dituzte.

Horrelako etiketa identifikatzaile bat deitzen zaio irudi etapa sinadura.

Irudi bakoitzak fase multzo batez osatuta dago: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch etab. Etapa bakoitzak bere edukia islatzen duen identifikatzaile bat du − etapa sinadura (eszenatokiaren sinadura).

Azken irudia, etapa hauek osatua, etapa hauen multzoaren sinadura deritzonarekin etiketatuta dago - etapa sinadura, - irudiaren fase guztietarako orokortzen dena.

Konfigurazioko irudi bakoitzeko werf.yaml kasu orokorrean, bere sinadura izango da eta, horren arabera, Docker etiketa bat.

Etapa sinadurak arazo hauek guztiak konpontzen ditu:

Git hutsen konpromezuekiko erresistentea.
Resistant to Git-ek irudiarekin garrantzitsuak ez diren fitxategiak aldatzen dituzten konpromisoak.
Ez du irudiaren egungo bertsioa berritzeko arazoa ekartzen adar bateko Git konpromezu zaharrentzako konpilazioak berrabiarazten direnean.

Hau da orain gomendatutako etiketatze-estrategia eta werf-en lehenetsia da CI sistema guztientzat.

Nola gaitu eta erabili werf-en

Komandoak dagokion aukera du orain werf publish: --tag-by-stages-signature=true|false

CI sistema batean, etiketatze-estrategia komandoak zehazten du werf ci-env. Aurretik, horretarako parametroa definitu zen werf ci-env --tagging-strategy=tag-or-branch. Orain, zehazten baduzu werf ci-env --tagging-strategy=stages-signature edo ez zehaztu aukera hau, werf-ek etiketa-estrategia erabiliko du lehenespenez stages-signature. Taldea werf ci-env komandorako beharrezko banderak automatikoki ezarriko ditu werf build-and-publish (Edo werf publish), beraz, ez da aukera gehigarririk zehaztu behar komando hauetarako.

Adibidez, komandoa:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

... irudi hauek sor ditzake:

registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

Hemen 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d irudiaren faseen sinadura da backendEta f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - Irudi-etapeen sinadura frontend.

Funtzio bereziak erabiltzean werf_container_image и werf_container_env Helm txantiloietan ez dago ezer aldatu beharrik: funtzio hauek automatikoki sortuko dituzte irudi-izen zuzenak.

CI sistema bateko konfigurazio adibidea:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

Konfigurazioari buruzko informazio gehiago dokumentazioan dago eskuragarri:

Guztira

Aukera berria werf publish --tag-by-stages-signature=true|false.
Aukera-balio berria werf ci-env --tagging-strategy=stages-signature|tag-or-branch (zehazten ez bada, lehenetsia izango da stages-signature).
Aurretik Git-en konpromisoetarako etiketa-aukerak erabili badituzu (WERF_TAG_GIT_COMMIT edo aukera werf publish --tag-git-commit COMMIT), gero ziurtatu etiketatze estrategiara aldatzen duzula etapak-sinadura.
Hobe da proiektu berriak berehala aldatzea etiketa-eskema berrira.
Werf 1.1era transferitzean, proiektu zaharrak etiketa-eskema berrira aldatzea komeni da, baina zaharra. etiketa-edo-adarra onartzen da oraindik.

Edukian oinarritutako etiketatzeak artikuluan azaltzen diren arazo guztiak konpontzen ditu:

Docker etiketa-izenen erresistentzia Git hutsen konpromisoei.
Docker etiketa-izena Git-en erresilientziak irudiarekin zerikusirik ez duten fitxategiak aldatzen dituzten konpromisoak hartzen ditu.
Ez du irudiaren egungo bertsioa berritzeko arazoa ekartzen Git adarretarako Git konprometitu zaharretarako konpilazioak berrabiarazten direnean.

Erabili ezazu! Eta ez ahaztu gurekin bisitatzea GitHubarazo bat sortzeko edo lehendik dagoen bat aurkitzeko, plus bat gehitzeko, PR bat sortzeko edo, besterik gabe, proiektuaren garapena ikusteko.

PS

Irakurri ere gure blogean:

Iturria: www.habr.com

Edukietan oinarritutako etiketatzea werf builder-en: zergatik eta nola funtzionatzen du?