🥇 Tagio ar sail cynnwys yn y casglwr werff: pam a sut mae'n gweithio?

werff yw ein cyfleustodau ffynhonnell agored GitOps CLI ar gyfer adeiladu a chyflwyno ceisiadau i Kubernetes. YN rhyddhau v1.1 cyflwynwyd nodwedd newydd yn y casglwr delweddau: tagio delweddau yn ôl cynnwys neu tagio sy'n seiliedig ar gynnwys. Hyd yn hyn, roedd y cynllun tagio nodweddiadol mewn werff yn cynnwys tagio delweddau Docker yn ôl tag Git, cangen Git neu Git commit. Ond mae gan yr holl gynlluniau hyn anfanteision sy'n cael eu datrys yn llwyr gan y strategaeth dagio newydd. Mae manylion amdano a pham ei fod mor dda o dan y toriad.

Cyflwyno set o ficrowasanaethau o un gadwrfa Git

Mae sefyllfa'n aml yn digwydd pan fydd cais yn cael ei rannu'n fwy neu lai o wasanaethau annibynnol. Gall rhyddhau'r gwasanaethau hyn ddigwydd yn annibynnol: gellir rhyddhau un neu fwy o wasanaethau ar y tro, tra bod yn rhaid i'r gweddill barhau i weithio heb unrhyw newidiadau. Ond o safbwynt storio cod a rheoli prosiectau, mae'n fwy cyfleus cadw gwasanaethau cais o'r fath mewn un ystorfa.

Mae sefyllfaoedd pan fo gwasanaethau yn wirioneddol annibynnol a heb fod yn gysylltiedig ag un cymhwysiad. Yn yr achos hwn, byddant yn cael eu lleoli mewn prosiectau ar wahân a bydd eu rhyddhau yn cael ei wneud trwy brosesau CI/CD ar wahân ym mhob un o'r prosiectau.

Fodd bynnag, mewn gwirionedd, mae datblygwyr yn aml yn rhannu un cymhwysiad yn nifer o ficrowasanaethau, ond mae creu ystorfa a phrosiect ar wahân ar gyfer pob un... yn orlif amlwg. Y sefyllfa hon a gaiff ei thrafod ymhellach: mae nifer o ficrowasanaethau o'r fath wedi'u lleoli mewn un storfa prosiect ac mae rhyddhau'n digwydd trwy un broses yn CI/CD.

Tagio yn ôl cangen Git a thag Git

Gadewch i ni ddweud mai'r strategaeth dagio fwyaf cyffredin a ddefnyddir - tag-neu-cangen. Ar gyfer canghennau Git, mae delweddau wedi'u tagio ag enw'r gangen, ar gyfer un gangen ar y tro nid oes ond un ddelwedd gyhoeddedig wrth enw'r gangen honno. Ar gyfer tagiau Git, mae delweddau'n cael eu tagio yn ôl enw'r tag.

Pan fydd tag Git newydd yn cael ei greu - er enghraifft, pan fydd fersiwn newydd yn cael ei ryddhau - bydd tag Docker newydd yn cael ei greu ar gyfer holl ddelweddau prosiect yng Nghofrestrfa'r Docwyr:

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

Mae'r enwau delwedd newydd hyn yn cael eu trosglwyddo trwy dempledi Helm i gyfluniad Kubernetes. Wrth gychwyn y gosodiad gyda'r gorchymyn werf deploy maes yn cael ei ddiweddaru image yn Kubernetes mae adnodd yn amlygu ac yn ailgychwyn yr adnoddau cyfatebol oherwydd yr enw delwedd wedi'i newid.

problem: yn yr achos pan, mewn gwirionedd, nid yw cynnwys y ddelwedd wedi newid ers y cyflwyniad blaenorol (Git tag), ond dim ond ei dag Docker, mae hyn yn digwydd gormodedd ailgychwyn y cais hwn ac, yn unol â hynny, mae rhywfaint o amser segur yn bosibl. Er nad oedd unrhyw reswm gwirioneddol i berfformio'r ailgychwyn hwn.

O ganlyniad, gyda'r cynllun tagio presennol mae angen ffensio sawl ystorfa Git ar wahân ac mae'r broblem yn codi o drefnu cyflwyno'r sawl ystorfa hyn. Yn gyffredinol, mae cynllun o'r fath yn troi allan i fod yn orlwytho ac yn gymhleth. Mae'n well cyfuno llawer o wasanaethau yn un ystorfa a chreu tagiau Docker fel nad oes unrhyw ailgychwyniadau diangen.

Tagio gan ymrwymo Git

Mae gan werf hefyd strategaeth dagio sy'n gysylltiedig ag ymrwymiadau Git.

Mae Git-commit yn ddynodwr ar gyfer cynnwys ystorfa Git ac mae'n dibynnu ar hanes golygu ffeiliau yn ystorfa Git, felly mae'n ymddangos yn rhesymegol ei ddefnyddio ar gyfer tagio delweddau yng Nghofrestrfa'r Docwyr.

Fodd bynnag, mae gan dagio gan Git commit yr un anfanteision â thagio gan ganghennau Git neu dagiau Git:

Gellid creu ymrwymiad gwag nad yw'n newid unrhyw ffeiliau, ond bydd tag Docker y ddelwedd yn cael ei newid.
Gellid creu ymrwymiad uno nad yw'n newid y ffeiliau, ond bydd tag Docker y ddelwedd yn cael ei newid.
Gellid gwneud ymrwymiad sy'n newid y ffeiliau hynny yn Git nad ydynt yn cael eu mewnforio i'r ddelwedd, a bydd tag Docker y ddelwedd yn cael ei newid eto.

Nid yw tagio enw cangen Git yn adlewyrchu fersiwn delwedd

Mae problem arall yn gysylltiedig â’r strategaeth dagio ar gyfer canghennau Git.

Mae tagio yn ôl enw cangen yn gweithio cyn belled â bod yr ymrwymiadau ar y gangen honno'n cael eu casglu'n ddilyniannol mewn trefn gronolegol.

Os bydd y defnyddiwr yn dechrau ailadeiladu hen ymrwymiad sy'n gysylltiedig â changen benodol yn y cynllun presennol, yna bydd werf yn ailysgrifennu'r ddelwedd gan ddefnyddio'r tag Docker cyfatebol gyda fersiwn newydd o'r ddelwedd ar gyfer yr hen ymrwymiad. Mae gosodiadau sy'n defnyddio'r tag hwn o hyn ymlaen mewn perygl o dynnu fersiwn wahanol o'r ddelwedd wrth ailgychwyn codennau, ac o ganlyniad bydd ein cymhwysiad yn colli cysylltiad â'r system CI ac yn cael ei ddadgydamseru.

Yn ogystal, gyda gwthiadau olynol i mewn i un gangen gyda chyfnod byr o amser rhyngddynt, gellir llunio'r hen ymrwymiad yn hwyrach na'r un newydd: bydd hen fersiwn y ddelwedd yn trosysgrifo'r un newydd gan ddefnyddio'r tag cangen Git. Gellir datrys problemau o'r fath trwy system CI/CD (er enghraifft, yn GitLab CI mae'r ail yn cael ei lansio ar gyfer cyfres o ymrwymiadau). Fodd bynnag, nid yw pob system yn cefnogi hyn a rhaid cael ffordd fwy dibynadwy o atal problem mor sylfaenol.

Beth yw tagio seiliedig ar gynnwys?

Felly, beth yw tagio seiliedig ar gynnwys - tagio delweddau yn ôl cynnwys.

I greu tagiau Docker, nid cyntefigau Git (cangen Git, tag Git...) a ddefnyddir, ond siec sy'n gysylltiedig â:

cynnwys y ddelwedd. Mae'r tag ID delwedd yn adlewyrchu ei gynnwys. Wrth adeiladu fersiwn newydd, ni fydd y dynodwr hwn yn newid os nad yw'r ffeiliau yn y ddelwedd wedi newid;
hanes creu'r ddelwedd hon yn Git. Bydd gan ddelweddau sy'n gysylltiedig â gwahanol ganghennau Git a hanes adeiladu gwahanol trwy werff wahanol dagiau ID.

Tag dynodwr o'r fath yw'r hyn a elwir llofnod llwyfan delwedd.

Mae pob delwedd yn cynnwys set o gamau: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch etc. Mae gan bob cam ddynodwr sy'n adlewyrchu ei gynnwys − llofnod llwyfan (llofnod llwyfan).

Mae'r ddelwedd derfynol, sy'n cynnwys y camau hyn, wedi'i thagio â llofnod bondigrybwyll y set o'r camau hyn - llofnod camau, - sy'n gyffredinoli ar gyfer pob cam o'r ddelwedd.

Ar gyfer pob delwedd o'r ffurfweddiad werf.yaml yn yr achos cyffredinol, bydd ei lofnod ei hun ac, yn unol â hynny, tag Dociwr.

Mae llofnod y llwyfan yn datrys yr holl broblemau hyn:

Yn gwrthsefyll gwagio ymrwymiadau Git.
Mae Resistant to Git yn ymrwymo i newid ffeiliau nad ydynt yn berthnasol i'r ddelwedd.
Nid yw'n arwain at y broblem o ailwampio'r fersiwn gyfredol o'r ddelwedd wrth ailgychwyn adeiladau ar gyfer hen ymrwymiadau Git o gangen.

Dyma'r strategaeth dagio a argymhellir bellach a dyma'r rhagosodiad mewn werff ar gyfer pob system CI.

Sut i alluogi a defnyddio mewn werf

Bellach mae gan y gorchymyn opsiwn cyfatebol werf publish: --tag-by-stages-signature=true|false

Mewn system CI, mae'r gorchymyn yn pennu'r strategaeth dagio werf ci-env. Yn flaenorol, diffiniwyd y paramedr ar ei gyfer werf ci-env --tagging-strategy=tag-or-branch. Yn awr, os byddwch yn nodi werf ci-env --tagging-strategy=stages-signature neu peidiwch â nodi'r opsiwn hwn, bydd werf yn defnyddio'r strategaeth dagio yn ddiofyn stages-signature. Tîm werf ci-env yn gosod y baneri angenrheidiol ar gyfer y gorchymyn yn awtomatig werf build-and-publish (Neu werf publish), felly nid oes angen nodi unrhyw opsiynau ychwanegol ar gyfer y gorchmynion hyn.

Er enghraifft, y gorchymyn:

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

...yn gallu creu'r delweddau canlynol:

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

Yma 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d yn llofnod o gamau'r ddelwedd backendAc f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - llofnod camau delwedd frontend.

Wrth ddefnyddio swyddogaethau arbennig werf_container_image и werf_container_env Nid oes angen newid unrhyw beth yn y templedi Helm: bydd y swyddogaethau hyn yn cynhyrchu'r enwau delwedd cywir yn awtomatig.

Ffurfweddiad enghreifftiol mewn system CI:

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

Mae rhagor o wybodaeth am ffurfweddu ar gael yn y ddogfennaeth:

Yn gyfan gwbl

Opsiwn newydd werf publish --tag-by-stages-signature=true|false.
Gwerth opsiwn newydd werf ci-env --tagging-strategy=stages-signature|tag-or-branch (os na chaiff ei nodi, y rhagosodiad fydd stages-signature).
Os gwnaethoch ddefnyddio'r opsiynau tagio ar gyfer ymrwymiadau Git o'r blaen (WERF_TAG_GIT_COMMIT neu opsiwn werf publish --tag-git-commit COMMIT), yna gwnewch yn siŵr eich bod chi'n newid i'r strategaeth dagio llofnod cam.
Mae'n well newid prosiectau newydd ar unwaith i'r cynllun tagio newydd.
Wrth drosglwyddo i werff 1.1, fe'ch cynghorir i newid hen brosiectau i'r cynllun tagio newydd, ond yr hen tag-neu-cangen yn cael ei gefnogi o hyd.

Mae tagio ar sail cynnwys yn datrys yr holl broblemau a gwmpesir yn yr erthygl:

Enw tag docwr ymwrthedd i wag Git ymrwymo.
Mae gwytnwch yr enw tag Docker i Git yn ymrwymo bod newid ffeiliau yn amherthnasol i'r ddelwedd.
Nid yw'n arwain at y broblem o ailwampio'r fersiwn gyfredol o'r ddelwedd wrth ailgychwyn adeiladau ar gyfer hen ymrwymiadau Git ar gyfer canghennau Git.

Defnyddia fe! A pheidiwch ag anghofio ymweld â ni yn GitHubi greu mater neu ddod o hyd i un sy'n bodoli, ychwanegu fantais, creu cysylltiadau cyhoeddus neu wylio datblygiad y prosiect.

PS

Darllenwch hefyd ar ein blog:

Ffynhonnell: hab.com

Tagio ar sail cynnwys yn adeiladwr werff: pam a sut mae'n gweithio?