ProHoster > Blog > Administratioun > Inhaltsbaséiert Tagging am werf Sammler: firwat a wéi funktionnéiert et?

Inhaltsbaséiert Tagging am werf Sammler: firwat a wéi funktionnéiert et?

Inhaltsbaséiert Tagging am werf Sammler: firwat a wéi funktionnéiert et?

werf ass eisen Open Source GitOps CLI Utility fir Uwendungen op Kubernetes ze bauen an ze liwweren. IN Fräisetzung v1.1 eng nei Feature gouf am Bildsammler agefouert: Biller no Inhalt markéieren oder Inhalt-baséiert Tagging. Bis elo huet den typesche Tagging Schema an der Werf d'Markéierung vun Docker Biller duerch Git Tag, Git Branche oder Git commit involvéiert. Awer all dës Schemaen hunn Nodeeler déi komplett vun der neier Taggingstrategie geléist ginn. Detailer doriwwer a firwat et sou gutt ass sinn ënner dem Schnëtt.

Ausrollen vun engem Set vu Mikroservicer aus engem Git Repository

Eng Situatioun geschitt dacks wann eng Applikatioun a vill méi oder manner onofhängeg Servicer opgedeelt ass. Verëffentlechunge vun dëse Servicer kënnen onofhängeg geschéien: een oder méi Servicer kënnen gläichzäiteg verëffentlecht ginn, während de Rescht ouni Ännerunge weider muss schaffen. Awer aus der Siicht vu Codelagerung a Projektmanagement ass et méi praktesch sou Applikatiounsservicer an engem eenzege Repository ze halen.

Et gi Situatiounen wou Servicer wierklech onofhängeg sinn an net mat enger eenzeger Applikatioun verbonne sinn. An dësem Fall wäerte se an getrennte Projete lokaliséiert ginn an hir Verëffentlechung gëtt duerch separat CI / CD Prozesser an all eenzel vun de Projeten duerchgefouert.

Wéi och ëmmer, a Wierklechkeet hunn d'Entwéckler dacks eng eenzeg Applikatioun a verschidde Mikroservicer opgedeelt, awer e separaten Repository a Projet fir all ze kreéieren ... ass eng kloer Iwwerkill. Et ass dës Situatioun déi weider diskutéiert gëtt: verschidde sou Mikroservicer sinn an engem eenzege Projet Repository lokaliséiert a Verëffentlechunge geschéien duerch een eenzege Prozess am CI / CD.

Tagging duerch Git Branche a Git Tag

Loosst eis soen datt déi heefegst Tagging Strategie benotzt gëtt - tag-oder-Branch. Fir Git Filialen gi Biller mam Numm vun der Branche markéiert, fir eng Branche gläichzäiteg gëtt et nëmmen ee publizéiert Bild mam Numm vun där Branche. Fir Git Tags ginn d'Biller nom Tagnumm gezeechent.

Wann en neie Git Tag erstallt gëtt - zum Beispill, wann eng nei Versioun verëffentlecht gëtt - gëtt en neien Docker Tag fir all Projet Biller an der Docker Registry erstallt:

  • 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

Dës nei Bildnimm ginn duerch Helm Template an d'Kubernetes Konfiguratioun weiderginn. Wann Dir d'Deployment mam Kommando ufänkt werf deploy Feld gëtt aktualiséiert image an Kubernetes Ressource manifestéiert an Restarting déi entspriechend Ressourcen wéinst der geännert Bild Numm.

Problem: am Fall wou tatsächlech den Inhalt vum Bild net geännert huet zënter der viregter Rollout (Git Tag), awer nëmmen säin Docker Tag, geschitt dat iwwerschësseg dës Applikatioun nei unzefänken an deementspriechend e puer Ausdauer méiglech ass. Och wann et kee richtege Grond war fir dësen Neistart ze maachen.

Als Resultat, mam aktuellen Tagging Schema ass et néideg fir e puer getrennte Git Repositories z'ënnerscheeden an de Problem entsteet d'Rollout vun dëse verschidde Repositories z'organiséieren. Am Allgemengen, ass esou e Schema iwwerlaascht a komplex. Et ass besser vill Servicer an engem eenzege Repository ze kombinéieren an Docker Tags ze kreéieren sou datt et keng onnéideg Neistart gëtt.

Tagging vum Git commit

werf huet och eng Tagging Strategie verbonne mat Git commits.

Git-commit ass en Identifizéierer fir den Inhalt vun engem Git Repository an hänkt vun der Editéiergeschicht vun Dateien am Git Repository of, sou datt et logesch schéngt et ze benotzen fir Biller an der Docker Registry ze taggen.

Wéi och ëmmer, Tagging vu Git commit huet déiselwecht Nodeeler wéi Tagging vu Git Branchen oder Git Tags:

  • En eidelen Engagement kéint erstallt ginn, deen keng Dateien ännert, awer den Docker Tag vum Bild gëtt geännert.
  • E Fusiounscommit kéint erstallt ginn, deen d'Dateien net ännert, awer den Docker Tag vum Bild gëtt geännert.
  • Eng Verpflichtung kéint gemaach ginn, déi dës Dateien am Git ännert, déi net an d'Bild importéiert sinn, an den Docker-Tag vum Bild gëtt erëm geännert.

Tagging Git Branche Numm reflektéiert net d'Bild Versioun

Et gëtt en anere Problem mat der Taggingstrategie fir Git Filialen assoziéiert.

Tagging vum Branchenumm funktionnéiert soulaang d'Verpflichtungen op där Branche sequenziell a chronologescher Uerdnung gesammelt ginn.

Wann am aktuellen Schema de Benotzer ufänkt en alen Engagement opzebauen, deen mat enger bestëmmter Branche assoziéiert ass, da wäert d'werf d'Bild iwwerschreiwe mat dem entspriechende Docker Tag mat enger nei gebauter Versioun vum Bild fir déi al Verpflichtung. Deployementer déi dësen Tag vun elo un benotzen, riskéieren eng aner Versioun vum Bild ze zéien wann Dir Pods nei start, als Resultat vun deem eis Applikatioun d'Verbindung mam CI System verléiert an desynchroniséiert gëtt.

Zousätzlech, mat successive Pushen an eng Branche mat enger kuerzer Zäit tëscht hinnen, kann déi al Verpflichtung méi spéit kompiléiert ginn wéi déi nei: déi al Versioun vum Bild iwwerschreift déi nei mat dem Git Branche Tag. Esou Probleemer kënnen duerch e CI / CD System geléist ginn (zum Beispill am GitLab CI gëtt d'Pipeline vun der leschter fir eng Serie vu Verpflichtungen lancéiert). Wéi och ëmmer, net all Systemer ënnerstëtzen dëst an et muss e méi zouverléissege Wee ginn fir sou e fundamentale Problem ze vermeiden.

Wat ass Inhalt-baséiert Tagging?

Also, wat ass Inhalt-baséiert Tagging - Biller no Inhalt taggen.

Fir Docker Tags ze kreéieren, sinn et net Git Primitiven (Git Branche, Git Tag ...) déi benotzt ginn, awer e Checksum verbonne mat:

  • Inhalt vum Bild. D'Bild ID Tag reflektéiert säin Inhalt. Wann Dir eng nei Versioun baut, wäert dësen Identifizéierer net änneren wann d'Fichier'en am Bild net geännert hunn;
  • Geschicht fir dëst Bild am Git ze kreéieren. Biller verbonne mat verschiddene Git Filialen a verschiddene Baugeschicht iwwer werf wäerten verschidden ID Tags hunn.

Sou en Identifikatiounstag ass de sougenannte Bild Etapp Ënnerschrëft.

All Bild besteet aus enger Rei vun Etappen: from, before-install, git-archive, install, imports-after-install, before-setup... git-latest-patch etc. All Etapp huet en Identifizéierer deen säin Inhalt reflektéiert - Etapp Ënnerschrëft (Bühnsignatur).

Dat lescht Bild, dat aus dësen Etappen besteet, ass mat der sougenannter Ënnerschrëft vum Set vun dësen Etappen markéiert - Etappen Ënnerschrëft, - wat fir all Etappe vum Bild generaliséiert gëtt.

Fir all Bild vun der Configuratioun werf.yaml am allgemenge Fall gëtt et seng eege Ënnerschrëft an deementspriechend en Docker Tag.

D'Bühn Ënnerschrëft léist all dës Problemer:

  • Resistent géint eidel Git Verpflichtungen.
  • Resistant to Git commits datt Dateien änneren déi net relevant fir d'Bild sinn.
  • Féiert net zum Problem fir déi aktuell Versioun vum Bild z'iwwerschaffen wann Dir Builds fir al Git Verpflichtungen vun enger Branche nei start.

Dëst ass elo d'recommandéiert Tagging Strategie an ass de Standard am werf fir all CI Systemer.

Wéi aktivéiert a benotzt am werf

De Kommando huet elo eng entspriechend Optioun werf publish: --tag-by-stages-signature=true|false

An engem CI System gëtt d'Taggingstrategie vum Kommando spezifizéiert werf ci-env. Virdrun war de Parameter dofir definéiert werf ci-env --tagging-strategy=tag-or-branch. Elo, wann Dir uginn werf ci-env --tagging-strategy=stages-signature oder präziséiert dës Optioun net, werf benotzt d'Taggingstrategie par défaut stages-signature. Equipe werf ci-env wäert automatesch déi néideg Fändelen fir de Kommando setzen werf build-and-publish (oder werf publish), also musse keng zousätzlech Optioune fir dës Kommandoen spezifizéiert ginn.

Zum Beispill, de Kommando:

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

...kann déi folgend Biller erstellen:

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

et ass 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d ass eng Ënnerschrëft vun de Stadien vum Bild backendan f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - Ënnerschrëft vun Bild Etappe frontend.

Wann Dir speziell Funktiounen benotzt werf_container_image и werf_container_env Et ass net néideg eppes an den Helm Templates z'änneren: dës Funktiounen generéieren automatesch déi richteg Bildnamen.

Beispill Konfiguratioun an engem CI System:

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

Méi Informatioun iwwer d'Konfiguratioun ass an der Dokumentatioun verfügbar:

Total

  • Nei Optioun werf publish --tag-by-stages-signature=true|false.
  • Nei Optioun Wäert werf ci-env --tagging-strategy=stages-signature|tag-or-branch (wann net spezifizéiert, ass de Standard stages-signature).
  • Wann Dir virdru d'Tagging Optiounen fir Git commits benotzt hutt (WERF_TAG_GIT_COMMIT oder Optioun werf publish --tag-git-commit COMMIT), da gitt sécher op d'Taggingstrategie ze wiesselen Etappen-Ënnerschrëft.
  • Et ass besser direkt nei Projeten op den neien Tagging Schema ze wiesselen.
  • Wann Dir op werf 1.1 transferéiert, ass et unzeroden al Projeten op den neien Tagging Schema ze wiesselen, awer déi al tag-oder-Branch gëtt nach ëmmer ënnerstëtzt.

Inhalt-baséiert Tagging léist all d'Problemer déi am Artikel behandelt ginn:

  • Docker Tag Numm Resistenz géint eidel Git Verpflichtungen.
  • Widderstandsfäegkeet vum Docker Tag Numm op Git engagéiert datt Dateien irrelevant fir d'Bild änneren.
  • Féiert net zum Problem fir d'aktuell Versioun vum Bild z'iwwerpréiwen wann Dir Builds fir al Git Verpflichtungen fir Git Filialen nei starten.

Benotz et! An vergiesst net eis ze besichen um GitHubfir en Thema ze kreéieren oder en existent ze fannen, e Plus addéieren, e PR erstellen oder einfach d'Entwécklung vum Projet kucken.

PS

Liest och op eisem Blog:

Source: will.com

Setzt e Commentaire