🥇Inhoud-gebaseerde tagging in die werf versamelaar: hoekom en hoe werk dit?

werf is ons oopbron GitOps CLI-hulpmiddel vir die bou en aflewering van toepassings aan Kubernetes. IN vrystelling v1.1 'n nuwe kenmerk is in die beeldversamelaar bekendgestel: merk beelde volgens inhoud of inhoud-gebaseerde tagging. Tot nou toe het die tipiese merkerskema in werf behels die merk van Docker-beelde deur Git tag, Git branch of Git commit. Maar al hierdie skemas het tekortkominge wat heeltemal opgelos word deur die nuwe etiketteringstrategie. Besonderhede daaroor en hoekom dit so goed is, is onder die knie.

Ontplooi 'n stel mikrodienste vanaf een Git-bewaarplek

'n Situasie kom dikwels voor wanneer 'n aansoek in baie min of meer onafhanklike dienste verdeel word. Vrystellings van hierdie dienste kan onafhanklik plaasvind: een of meer dienste kan op 'n slag vrygestel word, terwyl die res sonder enige veranderinge moet aanhou werk. Maar vanuit die oogpunt van kodeberging en projekbestuur, is dit geriefliker om sulke toepassingsdienste in 'n enkele bewaarplek te hou.

Daar is situasies wanneer dienste werklik onafhanklik is en nie met 'n enkele toepassing geassosieer word nie. In hierdie geval sal hulle in afsonderlike projekte geleë wees en hul vrystelling sal deur afsonderlike GI/CD-prosesse in elk van die projekte uitgevoer word.

In werklikheid verdeel ontwikkelaars egter dikwels 'n enkele toepassing in verskeie mikrodienste, maar die skep van 'n aparte bewaarplek en projek vir elke ... is 'n duidelike oormaat. Dit is hierdie situasie wat verder bespreek sal word: verskeie sulke mikrodienste is in 'n enkele projekbewaarplek geleë en vrystellings vind plaas deur 'n enkele proses in CI/CD.

Tagging deur Git-tak en Git-tag

Kom ons sê die mees algemene merkstrategie word gebruik - tag-of-tak. Vir Git-takke word beelde gemerk met die naam van die tak, vir een tak op 'n slag is daar net een gepubliseerde beeld met die naam van daardie tak. Vir Git-merkers word beelde volgens die merkernaam gemerk.

Wanneer 'n nuwe Git-merker geskep word - byvoorbeeld wanneer 'n nuwe weergawe vrygestel word - sal 'n nuwe Docker-merker vir alle projekbeelde in die Docker-register geskep word:

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

Hierdie nuwe beeldname word deur Helm-sjablone na die Kubernetes-konfigurasie gestuur. Wanneer die ontplooiing met die opdrag begin werf deploy veld word opgedateer image in Kubernetes hulpbronmanifesteer en herbegin die ooreenstemmende hulpbronne as gevolg van die veranderde beeldnaam.

probleem: in die geval waar, in werklikheid, die inhoud van die prent nie verander het sedert die vorige ontplooiing (Git tag), maar slegs sy Docker tag, dit gebeur oormaat herbegin hierdie toepassing en gevolglik is 'n mate van stilstand moontlik. Alhoewel daar geen werklike rede was om hierdie herbegin uit te voer nie.

As gevolg hiervan, met die huidige merkskema is dit nodig om verskeie afsonderlike Git-bewaarplekke te omhein en die probleem ontstaan om die ontplooiing van hierdie verskeie bewaarplekke te organiseer. Oor die algemeen blyk so 'n skema oorlaai en kompleks te wees. Dit is beter om baie dienste in 'n enkele bewaarplek te kombineer en Docker-etikette te skep sodat daar geen onnodige herbeginsels is nie.

Tagging deur Git commit

werf het ook 'n merkstrategie wat verband hou met Git commits.

Git-commit is 'n identifiseerder vir die inhoud van 'n Git-bewaarplek en hang af van die wysigingsgeskiedenis van lêers in die Git-bewaarplek, so dit lyk logies om dit te gebruik om beelde in die Docker-register te merk.

Merking deur Git commit het egter dieselfde nadele as tagging deur Git-takke of Git-etikette:

'n Leë commit kan geskep word wat geen lêers verander nie, maar die Docker-merker van die prent sal verander word.
'n Samevoegingstoewysing kan geskep word wat nie die lêers verander nie, maar die Docker-merker van die prent sal verander word.
'n Toewysing kan gemaak word wat daardie lêers in Git verander wat nie in die prent ingevoer is nie, en die Docker-merker van die prent sal weer verander word.

Merking van Git-taknaam weerspieël nie beeldweergawe nie

Daar is nog 'n probleem wat verband hou met die merkstrategie vir Git-takke.

Merking volgens taknaam werk solank die commits op daardie tak opeenvolgend in chronologiese volgorde versamel word.

As die gebruiker in die huidige skema begin om 'n ou commit te herbou wat met 'n sekere tak geassosieer word, dan sal werf die prent herskryf deur die ooreenstemmende Docker tag te gebruik met 'n nuutgeboude weergawe van die prent vir die ou commit. Ontplooiings wat van nou af hierdie merker gebruik, loop die risiko om 'n ander weergawe van die prent te trek wanneer peule herbegin word, as gevolg daarvan sal ons toepassing verbinding met die CI-stelsel verloor en gedesinchroniseer word.

Daarbenewens, met opeenvolgende stoot in een tak met 'n kort tydperk tussen hulle, kan die ou commit later as die nuwer een saamgestel word: die ou weergawe van die prent sal die nuwe een oorskryf deur die Git-takmerker te gebruik. Sulke probleme kan deur 'n CI/CD-stelsel opgelos word (byvoorbeeld, in GitLab CI word laasgenoemde se pyplyn vir 'n reeks commits geloods). Nie alle stelsels ondersteun dit egter nie en daar moet 'n meer betroubare manier wees om so 'n fundamentele probleem te voorkom.

Wat is inhoudgebaseerde tagging?

Dus, wat is inhoudgebaseerde tagging - merk prente volgens inhoud.

Om Docker-etikette te skep, is dit nie Git-primitiewe (Git-tak, Git-tag ...) wat gebruik word nie, maar 'n kontrolesom wat geassosieer word met:

inhoud van die beeld. Die beeld-ID-merker weerspieël die inhoud daarvan. Wanneer 'n nuwe weergawe gebou word, sal hierdie identifiseerder nie verander as die lêers in die prent nie verander het nie;
geskiedenis van die skep van hierdie beeld in Git. Beelde wat geassosieer word met verskillende Git-takke en verskillende bougeskiedenis via werf sal verskillende ID-etikette hê.

So 'n identifiseerder tag is die sogenaamde beeld verhoog handtekening.

Elke prent bestaan uit 'n stel fases: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch ens. Elke stadium het 'n identifiseerder wat die inhoud daarvan weerspieël − verhoog handtekening (verhoog handtekening).

Die finale beeld, wat uit hierdie stadiums bestaan, is gemerk met die sogenaamde handtekening van die stel van hierdie stadiums - stadiums handtekening, - wat veralgemenend is vir alle stadiums van die beeld.

Vir elke prent van die konfigurasie werf.yaml in die algemene geval sal daar sy eie handtekening wees en dienooreenkomstig 'n Docker-etiket.

Die verhooghandtekening los al hierdie probleme op:

Weerstand teen leë Git-commits.
Resistant to Git commits wat lêers verander wat nie relevant is vir die prent nie.
Lei nie tot die probleem om die huidige weergawe van die prent op te knap wanneer bouwerk vir ou Git-commits van 'n tak herbegin word nie.

Dit is nou die aanbevole merkstrategie en is die verstek in werf vir alle CI-stelsels.

Hoe om te aktiveer en te gebruik in werf

Die opdrag het nou 'n ooreenstemmende opsie werf publish: --tag-by-stages-signature=true|false

In 'n CI-stelsel word die merkstrategie deur die opdrag gespesifiseer werf ci-env. Voorheen is die parameter daarvoor gedefinieer werf ci-env --tagging-strategy=tag-or-branch. Nou, as jy spesifiseer werf ci-env --tagging-strategy=stages-signature of moenie hierdie opsie spesifiseer nie, werf sal by verstek die merkstrategie gebruik stages-signature. Span werf ci-env sal outomaties die nodige vlae vir die opdrag stel werf build-and-publish (Of werf publish), dus hoef geen bykomende opsies vir hierdie opdragte gespesifiseer te word nie.

Byvoorbeeld, die opdrag:

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

...kan die volgende beelde skep:

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

Hier 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d is 'n handtekening van die stadiums van die beeld backendEn f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - handtekening van beeldstadia frontend.

Wanneer spesiale funksies gebruik word werf_container_image и werf_container_env Dit is nie nodig om enigiets in die Helm-sjablone te verander nie: hierdie funksies sal outomaties die korrekte beeldname genereer.

Voorbeeldkonfigurasie in 'n CI-stelsel:

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

Meer inligting oor konfigurasie is beskikbaar in die dokumentasie:

In totaal

Nuwe opsie werf publish --tag-by-stages-signature=true|false.
Nuwe opsie waarde werf ci-env --tagging-strategy=stages-signature|tag-or-branch (indien nie gespesifiseer nie, sal die verstek wees stages-signature).
As jy voorheen die merkopsies vir Git commits gebruik het (WERF_TAG_GIT_COMMIT of opsie werf publish --tag-git-commit COMMIT), maak seker dat jy oorskakel na die merkstrategie stadiums-handtekening.
Dit is beter om onmiddellik nuwe projekte na die nuwe merkskema oor te skakel.
Wanneer oorgeplaas word na werf 1.1, is dit raadsaam om ou projekte na die nuwe merkskema oor te skakel, maar die ou tag-of-tak word steeds ondersteun.

Inhoud-gebaseerde tagging los al die probleme op wat in die artikel gedek word:

Docker tag naam weerstand teen leë Git commits.
Weerstand van die Docker-merker se naam teen Git commits wat lêers verander wat irrelevant is vir die prent.
Lei nie tot die probleem om die huidige weergawe van die prent op te knap wanneer bouwerk vir ou Git-commits vir Git-takke herbegin word nie.

Gebruik dit! En moenie vergeet om ons te besoek by GitHubom 'n kwessie te skep of 'n bestaande een te vind, voeg 'n pluspunt by, skep 'n PR of kyk bloot na die ontwikkeling van die projek.

Inhoudgebaseerde tagging in die werfbouer: hoekom en hoe werk dit?