🥇Di berhevoka werfê de nîşankirina naverokê: çima û çawa dixebite?

werf Ji bo avakirin û radestkirina serîlêdanan ji Kubernetes re amûra meya çavkaniya vekirî GitOps CLI ye. LI serbestberdana v1.1 taybetmendiyek nû di berhevkarê wêneyan de hate destnîşan kirin: nîşankirina wêneyan ji hêla naverokê an nîşankirina-based naverokê. Heya nuha, pilana nîşankirina tîpîk di werf de bi nîşankirina wêneyên Docker-ê ji hêla Git tag, şaxê Git an Git commit ve girêdayî bû. Lê van hemî nexşeyan kêmasiyên xwe hene ku bi stratejiya nû ya nîşankirinê bi tevahî têne çareser kirin. Agahdariyên li ser wê û çima ew qas baş e di bin qutbûnê de ne.

Ji yek depoya Git-ê komek mîkroxizmet radike

Pir caran rewşek çêdibe dema ku serîlêdanek li gelek karûbarên bêtir an kêmtir serbixwe tê dabeş kirin. Serbestberdana van karûbaran dikare serbixwe çêbibe: yek an çend karûbar dikarin di carekê de werin berdan, dema ku yên mayî divê bêyî ti guhertinan xebata xwe bidomînin. Lê ji hêla hilanîna kodê û rêveberiya projeyê ve, hêsantir e ku meriv karûbarên serîlêdanê yên weha di depoyek yekane de bigire.

Rewş hene ku karûbar bi rastî serbixwe ne û bi serîlêdanek yekane ve girêdayî ne. Di vê rewşê de, ew ê di projeyên cihêreng de cih bigirin û serbestberdana wan dê di her projeyan de bi pêvajoyên cihêreng ên CI/CD ve were kirin.

Lêbelê, di rastiyê de, pêşdebiran bi gelemperî serîlêdanek yekane di nav çend mîkroservisan de vediqetînin, lê çêkirina depoyek û projeyek cihê ji bo her yekê ... zêdebûnek eşkere ye. Ev rewş e ku dê bêtir were nîqaş kirin: çend mîkroxizmetên weha di depoyek projeyek yekane de cih digirin û berdan bi pêvajoyek yekane di CI/CD de pêk tê.

Nîşankirina ji hêla şaxê Git û tagê Git ve

Ka em bibêjin stratejiya nîşankirinê ya herî gelemperî tê bikar anîn - tag-an-şax. Ji bo şaxên Git, wêne bi navê şaxê têne nîşankirin, ji bo şaxek her carê tenê wêneyek çapkirî bi navê wê şaxê heye. Ji bo etîketên Git, wêne li gorî navê tagê têne nîşankirin.

Dema ku tagek Git-ê ya nû tê afirandin - mînakî, dema ku guhertoyek nû tê berdan - dê ji bo hemî wêneyên projeyê di Registry Docker de tagek nû ya Docker were afirandin:

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

Van navên nû yên wêneyê di nav şablonên Helm de derbasî veavakirina Kubernetes dibin. Dema ku bi fermanê dest bi belavkirinê dike werf deploy qada tê nûkirin image di çavkaniya Kubernetes de ji ber navê wêneyê guherî çavkaniyên têkildar diyar dike û ji nû ve dest pê dike.

pirsgirêka: Di rewşê de ku, bi rastî, naveroka wêneyê ji pêşandana berê (tag Git) neguherî ye, lê tenê nîşana wê Docker, ev diqewime. zêdeyî ji nû ve destpêkirina vê serîlêdanê û, li gorî vê yekê, hin demdirêj gengaz e. Her çend sedemek rastîn tune bû ku vê ji nû ve destpêkirinê pêk bîne.

Wekî encamek, bi pilana nîşankirina heyî re pêdivî ye ku çend depoyên Git-ê yên cihêreng werin dorpêç kirin û pirsgirêk organîzekirina vekirina van çend depoyan derdikeve holê. Bi gelemperî, nexşeyek wusa zêde bargiran û tevlihev dibe. Çêtir e ku meriv gelek karûbaran di depoyek yekane de berhev bike û etîketên Docker biafirîne da ku ji nû ve destpêkirinên nehewce nebin.

Nîşankirina ji hêla Git commit ve

werf di heman demê de xwedî stratejiyek nîşankirinê ye ku bi Git commits ve girêdayî ye.

Git-commit ji bo naveroka depoyek Git-ê nasnameyek e û bi dîroka guherandina pelên di depoya Git-ê de ve girêdayî ye, ji ber vê yekê mentiqî xuya dike ku meriv wê ji bo nîşankirina wêneyan di Registry Docker de bikar bîne.

Lêbelê, nîşankirina ji hêla Git commit ve heman dezavantajên wekî nîşankirina ji hêla şaxên Git an tagên Git ve heye:

Dibe ku komîteyek vala were afirandin ku tu pelan naguhezîne, lê nîşana Docker ya wêneyê dê were guheztin.
Dikare pevgirêdanek were afirandin ku pelan naguhezîne, lê taga Docker ya wêneyê dê were guheztin.
Dibe ku peywirek were çêkirin ku wan pelên li Git-ê yên ku di nav wêneyê de neyên guheztin biguhezîne, û etîketa Docker ya wêneyê dê dîsa were guheztin.

Etîketkirina navê şaxê Git guhertoya wêneyê nîşan nade

Pirsgirêkek din bi stratejiya nîşankirinê ya ji bo şaxên Git ve girêdayî ye.

Etîketkirina bi navê şaxê heya ku peywirên li ser wê şaxê bi rêz û rêza kronolojîk têne berhev kirin dixebite.

Ger di pilana heyî de bikarhêner dest bi avakirina komîteyek kevn a ku bi şaxek diyar ve girêdayî ye dest pê bike, wê hingê werf dê wêneyê bi karanîna etîketa Docker-a têkildar re bi guhertoyek nû ya çêkirî ya wêneyê ji bo peywira kevn ji nû ve binivîsîne. Sazkirinên ku ji nuha û pê ve vê tagê bikar tînin xetera kişandina guhertoyek cûda ya wêneyê dema ku pod ji nû ve dest pê bikin, dikişînin, wekî encamek ku serlêdana me dê têkiliya bi pergala CI-ê re winda bike û desenkronîze bibe.

Digel vê yekê, digel pêlên li dû hev li yek şaxek ku di navbera wan de demek kurt heye, dibe ku peywira kevn ji ya nûtir dereng were berhev kirin: guhertoya kevn a wêneyê dê ya nû bi karanîna etîketa şaxê Git binivîsîne. Pirsgirêkên weha dikarin bi pergalek CI/CD-ê ve werin çareser kirin (mînak, di GitLab CI de lûleya paşîn ji bo rêzek peywiran tê destpêkirin). Lêbelê, hemî pergal piştgirî nadin vê yekê û divê rêyek pêbawertir hebe ku pêşî li pirsgirêkek weha bingehîn bigire.

Nîşankirina-based naverokê çi ye?

Ji ber vê yekê, nîşankirina naverokê çi ye - nîşankirina wêneyan ji hêla naverokê ve.

Ji bo afirandina etîketên Docker, ew ne primitives Git (şaxa Git, etîketa Git...) ne ku têne bikar anîn, lê kontrolek ku bi wan re têkildar e:

naveroka wêneyê. Nasnameya wêneyê naveroka wê nîşan dide. Dema ku guhertoyek nû ava dike, heke pelên di wêneyê de nehatine guhertin, ev nasname nayê guhertin;
dîroka afirandina vê wêneyê li Git. Wêneyên ku bi şaxên Git-ê yên cihêreng û dîroka avakirina cihêreng ve girêdayî ne, bi navgîniya werfê ve dê xwedan nasnameyên cihêreng bin.

Tagek nasnameyê ya bi vî rengî tê gotin îmza qonaxa wêneyê.

Her wêne ji komek qonaxan pêk tê: from, before-install, git-archive, install, imports-after-install, before-setup... git-latest-patch etc. Her qonax xwedan nasnameyek e ku naveroka wê nîşan dide - îmza qonaxa (îmza qonaxê).

Wêneya paşîn, ku ji van qonaxan pêk tê, bi navê îmzaya koma van qonaxan tê tag kirin - qonaxên îmze, - ku ji bo hemî qonaxên wêneyê gelemperî dike.

Ji bo her wêneyek ji veavakirinê werf.yaml di rewşa gelemperî de, dê îmzeya xwe û, li gorî vê yekê, nîşanek Docker hebe.

Îmzeya qonaxê van pirsgirêkan hemî çareser dike:

Berxwedêrên Git vala.
Berxwedêr ji Git re dike ku pelên ku bi wêneyê re ne têkildar diguhezîne.
Dema ku avakirinan ji bo paceyên Git-ê yên kevin ên şaxekê ji nû ve bidin destpêkirin, rê nade pirsgirêka sererastkirina guhertoya heyî ya wêneyê.

Ev naha stratejiya nîşankirinê ya pêşniyarkirî ye û ji bo hemî pergalên CI-ê di werfê de xwerû ye.

Meriv çawa di werfê de çalak dike û bikar tîne

Ferman niha vebijarkek têkildar heye werf publish: --tag-by-stages-signature=true|false

Di pergalek CI de, stratejiya nîşankirinê ji hêla fermanê ve tête diyar kirin werf ci-env. Berê, parametre ji bo wê hate diyarkirin werf ci-env --tagging-strategy=tag-or-branch. Niha, eger hûn diyar bikin werf ci-env --tagging-strategy=stages-signature an jî vê vebijarkê diyar nekin, werf dê stratejiya nîşankirinê ji hêla xwerû ve bikar bîne stages-signature. Kom werf ci-env dê bixweber alayên pêwîst ji bo fermanê saz bike werf build-and-publish (an jî werf publish), ji ber vê yekê ne hewce ye ku vebijarkên zêde ji bo van fermanan bêne diyar kirin.

Ji bo nimûne, emrê:

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

... dikare wêneyên jêrîn biafirîne:

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

Ev e 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d îmzaya qonaxên wêneyê ye backendû f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - îmzekirina qonaxên wêneyê frontend.

Dema ku fonksiyonên taybetî bikar bînin werf_container_image и werf_container_env Di şablonên Helm de ne hewce ye ku tiştek biguhezîne: ev fonksiyon dê bixweber navên wêneyê rast biafirînin.

Veavakirina Mînak di pergala CI de:

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

Zêdetir agahdarî li ser veavakirinê di belgeyê de heye:

Tevahî

Vebijêrkek nû werf publish --tag-by-stages-signature=true|false.
Nirxa vebijarka nû werf ci-env --tagging-strategy=stages-signature|tag-or-branch (heke ne diyar be, dê pêşnuma be stages-signature).
Ger we berê vebijarkên nîşankirinê ji bo Git commits bikar aniye (WERF_TAG_GIT_COMMIT an vebijêrk werf publish --tag-git-commit COMMIT), wê hingê pê ewle bin ku hûn li stratejiya nîşankirinê veguherînin qonax-îmza.
Çêtir e ku meriv tavilê projeyên nû li pilana nîşankirina nû veguherîne.
Dema ku veguheztina werf 1.1, tê pêşniyar kirin ku projeyên kevn veguherînin nexşeya nîşankirina nû, lê ya kevn tag-an-şax hîn jî piştgirî ye.

Etîketkirina-based naverokê hemî pirsgirêkên ku di gotarê de hatine destnîşan kirin çareser dike:

Berxwedana navê etîketa Docker ji bo pêkanîna Git vala.
Berxwedana navê etîketa Docker-ê ya li Git dihêle ku pelên ku bi wêneyê re ne têkildar biguhezîne.
Dema ku avakirinan ji bo Git-ya kevn ji bo şaxên Git-ê ji nû ve dest pê dike, rê nade pirsgirêka sererastkirina guhertoya heyî ya wêneyê.

Wê bixebitîne! Û ji bîr nekin ku hûn biçin serdana me GitHubji bo afirandina pirsgirêkek an peydakirina yek heyî, zêdeyek zêde bikin, PR-ê biafirînin an jî bi tenê li pêşveçûna projeyê temaşe bikin.

PS

Li ser bloga me jî bixwînin:

Source: www.habr.com

Nîşankirina-based naverokê di avakerê werf de: çima û çawa dixebite?