🥇 Efnismiðað merking í werf safnara: hvers vegna og hvernig virkar það?

werf er opinn uppspretta GitOps CLI tólið okkar til að byggja og afhenda forrit til Kubernetes. IN gefa út v1.1 nýr eiginleiki var kynntur í myndasafnaranum: að merkja myndir eftir efni eða innihaldsmiðaða merkingu. Hingað til hefur hið dæmigerða merkingarkerfi í werf fólgið í sér að merkja Docker myndir með Git tag, Git branch eða Git commit. En öll þessi kerfi hafa ókosti sem eru algjörlega leystir með nýju merkingarstefnunni. Upplýsingar um það og hvers vegna það er svo gott eru undir skurðinum.

Rúlla út safn af örþjónustum úr einni Git geymslu

Oft kemur upp sú staða þegar umsókn er skipt í margar meira og minna sjálfstæðar þjónustur. Losun þessara þjónustu getur átt sér stað sjálfstætt: eina eða fleiri þjónustur geta verið gefnar út í einu, en restin verður að halda áfram að virka án nokkurra breytinga. En frá sjónarhóli kóðageymslu og verkefnastjórnunar er þægilegra að geyma slíka forritaþjónustu í einni geymslu.

Það eru aðstæður þar sem þjónusta er sannarlega óháð og ekki tengd einni umsókn. Í þessu tilviki verða þau staðsett í sérstökum verkefnum og útgáfa þeirra fer fram með sérstökum CI/CD ferlum í hverju verkefni.

Hins vegar, í raun og veru, skipta verktaki oft einu forriti í nokkrar örþjónustur, en að búa til sérstaka geymslu og verkefni fyrir hverja... er augljóst of mikið. Það er þessi staða sem verður rædd frekar: nokkrar slíkar örþjónustur eru staðsettar í einni verkefnageymslu og útgáfur eiga sér stað með einu ferli í CI/CD.

Merking með Git grein og Git tagi

Segjum að algengasta merkingaraðferðin sé notuð - tag-eða-grein. Fyrir Git útibú eru myndir merktar með nafni útibúsins, fyrir eina útibú í einu er aðeins ein birt mynd með nafni greinarinnar. Fyrir Git tags eru myndir merktar í samræmi við merkisheitið.

Þegar nýtt Git tag er búið til - til dæmis þegar ný útgáfa er gefin út - verður nýtt Docker tag búið til fyrir allar verkefnismyndir í Docker Registry:

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

Þessi nýju myndanöfn eru send í gegnum Helm sniðmát í Kubernetes stillingarnar. Þegar dreifing er hafin með skipuninni werf deploy verið að uppfæra reitinn image í Kubernetes auðlindaskrám og endurræsa samsvarandi auðlindir vegna breytts nafns myndar.

vandamálið: ef innihald myndarinnar hefur í raun ekki breyst frá fyrri útgáfu (Git tag), heldur aðeins Docker tag hennar, gerist þetta óþarfur endurræsa þetta forrit og í samræmi við það er einhver niður í miðbæ möguleg. Þó það væri engin raunveruleg ástæða til að framkvæma þessa endurræsingu.

Þar af leiðandi, með núverandi merkingarkerfi, er nauðsynlegt að girða nokkrar aðskildar Git geymslur og vandamálið kemur upp við að skipuleggja útsetningu þessara nokkurra geymslu. Almennt séð reynist slíkt kerfi vera of mikið og flókið. Það er betra að sameina margar þjónustur í eina geymslu og búa til Docker merki þannig að það séu engar óþarfa endurræsingar.

Merking með Git commit

werf er einnig með merkingarstefnu sem tengist Git commits.

Git-commit er auðkenni fyrir innihald Git geymslu og fer eftir breytingasögu skráa í Git geymslunni, svo það virðist rökrétt að nota það til að merkja myndir í Docker Registry.

Hins vegar, merking með Git commit hefur sömu ókosti og merking með Git greinum eða Git tags:

Tómt commit gæti verið búið til sem breytir engum skrám, en Docker merkinu á myndinni verður breytt.
Hægt væri að búa til samrunaskuld sem breytir ekki skránum, en Docker merkinu á myndinni verður breytt.
Hægt væri að gera skuldbindingu sem breytir þeim skrám í Git sem eru ekki fluttar inn í myndina og Docker merkinu á myndinni verður breytt aftur.

Merking Git greinarheiti endurspeglar ekki myndútgáfu

Það er annað vandamál sem tengist merkingarstefnunni fyrir Git útibú.

Merking eftir heiti útibús virkar svo framarlega sem skuldbindingum á greininni er safnað í röð í tímaröð.

Ef í núverandi kerfi sem notandinn byrjar að endurbyggja gamla skuldbindingu sem tengist ákveðinni grein, þá mun werf endurskrifa myndina með því að nota samsvarandi Docker tag með nýbyggðri útgáfu af myndinni fyrir gamla skuldbindinguna. Dreifing sem notar þetta merki héðan í frá eiga á hættu að draga aðra útgáfu af myndinni þegar endurræst er belg, þar af leiðandi mun forritið okkar missa tenginguna við CI kerfið og verða ósamstillt.

Að auki, með samfelldum ýtum inn í eina grein með stuttan tíma á milli þeirra, gæti gamla commit verið sett saman síðar en nýrri: gamla útgáfan af myndinni mun skrifa yfir þá nýju með Git branch taginu. Slík vandamál er hægt að leysa með CI/CD kerfi (til dæmis, í GitLab CI er leiðsla þess síðarnefnda sett af stað fyrir röð skuldbindinga). Hins vegar styðja ekki öll kerfi þetta og það verður að vera til áreiðanlegri leið til að koma í veg fyrir slíkt grundvallarvandamál.

Hvað er innihaldsmiðað merking?

Svo, hvað er innihaldsmiðað merking - að merkja myndir eftir innihaldi.

Til að búa til Docker merki eru það ekki Git frumefni (Git grein, Git merki...) sem eru notuð, heldur eftirlitssumma sem tengist:

innihald myndarinnar. Myndauðkennismerkið endurspeglar innihald þess. Þegar ný útgáfa er byggð mun þetta auðkenni ekki breytast ef skrárnar á myndinni hafa ekki breyst;
sögu um að búa til þessa mynd í Git. Myndir sem tengjast mismunandi Git greinum og mismunandi byggingarsögu í gegnum werf munu hafa mismunandi auðkennismerki.

Slík auðkennismerki er svokallað mynd sviðsmerki.

Hver mynd samanstendur af setti af þrepum: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch o.s.frv. Hvert stig hefur auðkenni sem endurspeglar innihald þess - sviðsáskrift (sviðsundirskrift).

Lokamyndin, sem samanstendur af þessum stigum, er merkt með svokallaðri undirskrift setts þessara stiga - stig undirskrift, - sem er að alhæfa fyrir öll stig myndarinnar.

Fyrir hverja mynd úr uppsetningunni werf.yaml í almennu tilvikinu mun það vera eigin undirskrift og, í samræmi við það, Docker merki.

Sviðsundirskriftin leysir öll þessi vandamál:

Þolir tómar Git skuldbindingar.
Resistant to Git skuldbindingar sem breyta skrám sem eiga ekki við myndina.
Leiðir ekki til vandamálsins við að endurskoða núverandi útgáfu af myndinni þegar endurræst er smíðar fyrir gamla Git commits af útibúi.

Þetta er nú mælt með merkingarstefnu og er sjálfgefið í werf fyrir öll CI kerfi.

Hvernig á að virkja og nota í werf

Skipunin hefur nú samsvarandi valmöguleika werf publish: --tag-by-stages-signature=true|false

Í CI kerfi er merkingarstefnan tilgreind með skipuninni werf ci-env. Áður var færibreytan skilgreind fyrir það werf ci-env --tagging-strategy=tag-or-branch. Nú, ef þú tilgreinir werf ci-env --tagging-strategy=stages-signature eða ekki tilgreina þennan valkost, werf mun sjálfgefið nota merkingarstefnuna stages-signature. Lið werf ci-env mun sjálfkrafa setja nauðsynlega fána fyrir skipunina werf build-and-publish (Eða werf publish), þannig að ekki þarf að tilgreina fleiri valkosti fyrir þessar skipanir.

Til dæmis, skipunin:

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

...getur búið til eftirfarandi myndir:

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

Hér 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d er undirskrift á stigum myndarinnar backendOg f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - undirskrift myndstiga frontend.

Þegar sérstakar aðgerðir eru notaðar werf_container_image и werf_container_env Það er engin þörf á að breyta neinu í Helm sniðmátunum: þessar aðgerðir munu sjálfkrafa búa til rétt myndnöfn.

Dæmi um uppsetningu í CI kerfi:

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

Nánari upplýsingar um uppsetningu er að finna í skjölunum:

Alls

Nýr valkostur werf publish --tag-by-stages-signature=true|false.
Nýtt valréttargildi werf ci-env --tagging-strategy=stages-signature|tag-or-branch (ef ekki tilgreint verður sjálfgefið stages-signature).
Ef þú notaðir áður merkingarvalkostina fyrir Git commits (WERF_TAG_GIT_COMMIT eða valmöguleika werf publish --tag-git-commit COMMIT), vertu viss um að skipta yfir í merkingarstefnuna stig-undirskrift.
Það er betra að skipta strax nýjum verkefnum yfir í nýja merkingarkerfið.
Við flutning yfir í werf 1.1 er ráðlegt að skipta gömlum verkefnum yfir í nýja merkingarkerfið, en það gamla tag-eða-grein er enn stutt.

Efnismiðað merking leysir öll vandamál sem fjallað er um í greininni:

Docker tag nafn viðnám gegn tómum Git skuldbindingum.
Seigla Docker tag nafnsins til Git skuldbindingar sem breyta skrám sem eru óviðkomandi myndinni.
Leiðir ekki til vandamálsins við að endurskoða núverandi útgáfu af myndinni þegar endurræst er smíðar fyrir gamla Git commits fyrir Git greinar.

Nota það! Og ekki gleyma að heimsækja okkur kl GitHubað búa til mál eða finna það sem fyrir er, bæta við plús, búa til PR eða einfaldlega fylgjast með þróun verkefnisins.

PS

Lestu líka á blogginu okkar:

Heimild: www.habr.com

Efnismiðað merking í werf smiðnum: hvers vegna og hvernig virkar það?