Uwekaji tagi kulingana na yaliyomo kwenye mkusanyaji wa werf: kwa nini na inafanya kazi vipi?

werf ni chanzo huria chetu cha matumizi ya GitOps CLI kwa ajili ya kujenga na kuwasilisha maombi kwa Kubernetes. KATIKA kutolewa v1.1 kipengele kipya kilianzishwa katika mkusanyaji wa picha: kuweka tagi picha kwa maudhui au uwekaji tagi kulingana na yaliyomo. Hadi sasa, mpango wa kawaida wa kuweka lebo kwenye werf ulihusisha kuweka tagi kwenye picha za Docker na lebo ya Git, tawi la Git au ahadi ya Git. Lakini mipango hii yote ina hasara ambazo zinatatuliwa kabisa na mkakati mpya wa kuweka lebo. Maelezo juu yake na kwa nini ni nzuri sana iko chini ya kukata.

Kusambaza seti ya huduma ndogo kutoka kwa hazina moja ya Git

Mara nyingi hali hutokea wakati programu imegawanywa katika huduma nyingi zaidi au chini ya kujitegemea. Matoleo ya huduma hizi yanaweza kutokea kwa kujitegemea: huduma moja au zaidi inaweza kutolewa kwa wakati mmoja, wakati wengine wanapaswa kuendelea kufanya kazi bila mabadiliko yoyote. Lakini kutoka kwa mtazamo wa uhifadhi wa kanuni na usimamizi wa mradi, ni rahisi zaidi kuweka huduma hizo za maombi katika hifadhi moja.

Kuna hali wakati huduma zinajitegemea kweli na hazihusiani na programu moja. Katika kesi hii, watakuwa katika miradi tofauti na kutolewa kwao kutafanywa kupitia michakato tofauti ya CI/CD katika kila mradi.

Hata hivyo, kwa kweli, watengenezaji mara nyingi hugawanya programu moja katika huduma ndogo ndogo, lakini kuunda hifadhi tofauti na mradi kwa kila ... ni overkill wazi. Ni hali hii ambayo itajadiliwa zaidi: huduma ndogo kama hizo ziko kwenye hazina moja ya mradi na kutolewa hufanyika kupitia mchakato mmoja katika CI/CD.

Kuweka lebo kwa tawi la Git na lebo ya Git

Wacha tuseme mkakati wa kawaida wa kuweka alama unatumika - tag-au-tawi. Kwa matawi ya Git, picha zimetambulishwa kwa jina la tawi, kwa tawi moja kwa wakati kuna picha moja iliyochapishwa kwa jina la tawi hilo. Kwa vitambulisho vya Git, picha huwekwa alama kulingana na jina la lebo.

Wakati lebo mpya ya Git imeundwa - kwa mfano, toleo jipya linapotolewa - lebo mpya ya Docker itaundwa kwa picha zote za mradi kwenye Usajili wa Docker:

• 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

Majina haya mapya ya picha hupitishwa kupitia violezo vya Helm hadi kwenye usanidi wa Kubernetes. Wakati wa kuanza kupeleka kwa amri werf deploy uwanja unasasishwa image katika Kubernetes rasilimali inadhihirisha na kuwasha upya rasilimali zinazolingana kwa sababu ya jina lililobadilishwa la picha.

tatizo: katika kesi wakati, kwa kweli, yaliyomo kwenye picha hayajabadilika tangu kutolewa hapo awali (lebo ya Git), lakini tu lebo yake ya Docker, hii hufanyika. kuzidi kuanzisha upya programu hii na, ipasavyo, muda wa kupumzika unawezekana. Ingawa hakukuwa na sababu ya kweli ya kuanza tena hii.

Kama matokeo, pamoja na mpango wa sasa wa kuweka lebo ni muhimu kuweka uzio wa hazina kadhaa tofauti za Git na shida inatokea ya kuandaa usambazaji wa hazina hizi kadhaa. Kwa ujumla, mpango kama huo unageuka kuwa umejaa na ngumu. Ni bora kuchanganya huduma nyingi kwenye hazina moja na kuunda vitambulisho vya Docker ili kusiwe na kuanza tena kwa lazima.

Kuweka tagi kwa kujitolea kwa Git

werf pia ina mkakati wa kuweka lebo unaohusishwa na ahadi za Git.

Git-commit ni kitambulisho cha yaliyomo kwenye hazina ya Git na inategemea historia ya uhariri wa faili kwenye hazina ya Git, kwa hivyo inaonekana ni sawa kuitumia kuweka tagi kwenye Usajili wa Docker.

Walakini, kuweka tagi kwa ahadi ya Git kuna shida sawa na kuweka lebo na matawi ya Git au vitambulisho vya Git:

• Ahadi tupu inaweza kuundwa ambayo haibadilishi faili zozote, lakini lebo ya Docker ya picha itabadilishwa.
• Ahadi ya kuunganisha inaweza kuundwa ambayo haibadilishi faili, lakini lebo ya Docker ya picha itabadilishwa.
• Ahadi inaweza kufanywa ambayo itabadilisha faili hizo kwenye Git ambazo hazijaingizwa kwenye picha, na lebo ya Docker ya picha itabadilishwa tena.

Kuweka tagi jina la tawi la Git haionyeshi toleo la picha

Kuna shida nyingine inayohusishwa na mkakati wa kuweka lebo kwa matawi ya Git.

Kuweka lebo kwa jina la tawi hufanya kazi mradi tu ahadi kwenye tawi hilo zinakusanywa kwa kufuatana kwa mpangilio wa matukio.

Ikiwa katika mpango wa sasa mtumiaji ataanza kuunda tena ahadi ya zamani inayohusishwa na tawi fulani, basi werf itaandika upya picha hiyo kwa kutumia lebo inayolingana ya Docker na toleo jipya la picha kwa ahadi ya zamani. Usambazaji kwa kutumia lebo hii kuanzia sasa na kuendelea huwa katika hatari ya kuvuta toleo tofauti la picha wakati wa kuanzisha upya ganda, kwa sababu hiyo programu yetu itapoteza muunganisho na mfumo wa CI na kutolandanishwa.

Kwa kuongezea, kwa kusukuma mfululizo kwenye tawi moja na muda mfupi kati yao, ahadi ya zamani inaweza kukusanywa baadaye kuliko ile mpya zaidi: toleo la zamani la picha litafuta mpya kwa kutumia lebo ya tawi la Git. Shida kama hizo zinaweza kutatuliwa na mfumo wa CI/CD (kwa mfano, katika GitLab CI bomba la mwisho linazinduliwa kwa safu ya ahadi). Hata hivyo, si mifumo yote inayounga mkono hili na lazima kuwe na njia ya kuaminika zaidi ya kuzuia tatizo hilo la msingi.

Uwekaji tagi kulingana na yaliyomo ni nini?

Kwa hivyo, uwekaji tagi kulingana na yaliyomo ni nini - kuweka tagi kwa yaliyomo.

Ili kuunda vitambulisho vya Docker, sio primitives ya Git (tawi la Git, lebo ya Git ...) ambayo hutumiwa, lakini ukaguzi unaohusishwa na:

• yaliyomo kwenye picha. Lebo ya kitambulisho cha picha inaonyesha maudhui yake. Wakati wa kujenga toleo jipya, kitambulisho hiki hakitabadilika ikiwa faili kwenye picha hazijabadilika;
• historia ya kuunda picha hii katika Git. Picha zinazohusiana na matawi tofauti ya Git na historia tofauti ya ujenzi kupitia werf zitakuwa na vitambulisho tofauti.

Kitambulisho kama hicho ndicho kinachojulikana saini ya hatua ya picha.

Kila picha ina seti ya hatua: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch na kadhalika. Kila hatua ina kitambulisho kinachoakisi yaliyomo - saini ya hatua (saini ya jukwaa).

Picha ya mwisho, inayojumuisha hatua hizi, imewekwa alama na kinachojulikana kama saini ya seti ya hatua hizi - saini ya hatua, - ambayo ni ya jumla kwa hatua zote za picha.

Kwa kila picha kutoka kwa usanidi werf.yaml kwa ujumla, kutakuwa na saini yake mwenyewe na, ipasavyo, lebo ya Docker.

Sahihi ya hatua hutatua shida hizi zote:

• Inastahimili ahadi tupu za Git.
• Sugu kwa Git hujitolea kubadilisha faili ambazo hazihusiani na picha.
• Haiongoi kwa shida ya kurekebisha toleo la sasa la picha wakati wa kuanza tena ujenzi wa ahadi za zamani za Git za tawi.

Huu sasa ndio mkakati unaopendekezwa wa kuweka lebo na ndio chaguomsingi katika mifumo yote ya CI.

Jinsi ya kuwezesha na kutumia katika werf

Amri sasa ina chaguo sambamba werf publish: --tag-by-stages-signature=true|false

Katika mfumo wa CI, mkakati wa kuweka alama umebainishwa na amri werf ci-env. Hapo awali, parameter ilielezwa kwa ajili yake werf ci-env --tagging-strategy=tag-or-branch. Sasa, ikiwa utafafanua werf ci-env --tagging-strategy=stages-signature au usibainishe chaguo hili, werf itatumia mkakati wa kuweka lebo kwa chaguo-msingi stages-signature. Timu werf ci-env itaweka kiotomatiki bendera zinazohitajika kwa amri werf build-and-publish (Au werf publish), kwa hivyo hakuna chaguzi za ziada zinazohitaji kubainishwa kwa amri hizi.

Kwa mfano, amri:

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

...inaweza kuunda picha zifuatazo:

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

Hapa 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d ni saini ya hatua za picha backendNa f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - saini ya hatua za picha frontend.

Wakati wa kutumia kazi maalum werf_container_image и werf_container_env Hakuna haja ya kubadilisha chochote katika violezo vya Helm: vitendaji hivi vitatoa kiotomatiki majina sahihi ya picha.

Usanidi wa mfano katika mfumo wa CI:

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

Habari zaidi juu ya usanidi inapatikana katika nyaraka:

• Saraka → Chapisho (chapisha);
• Kufanya kazi na CI/CD → Taarifa ya jumla → hatua-saini;
• Kuunganishwa na GitLab CI/CD → .gitlab-ci.yml.

Katika jumla ya

• Chaguo jipya werf publish --tag-by-stages-signature=true|false.
• Thamani mpya ya chaguo werf ci-env --tagging-strategy=stages-signature|tag-or-branch (ikiwa haijabainishwa, chaguo-msingi itakuwa stages-signature).
• Ikiwa hapo awali ulitumia chaguzi za kuweka lebo kwa ahadi za Git (WERF_TAG_GIT_COMMIT au chaguo werf publish --tag-git-commit COMMIT), kisha hakikisha kuwa umebadilisha hadi mkakati wa kuweka lebo hatua - saini.
• Ni bora kubadili mara moja miradi mipya kwa mpango mpya wa kuweka lebo.
• Wakati wa kuhamisha kwa werf 1.1, inashauriwa kubadili miradi ya zamani kwa mpango mpya wa kuweka lebo, lakini wa zamani. tag-au-tawi bado inaungwa mkono.

Uwekaji tagi kulingana na yaliyomo hutatua shida zote zilizoangaziwa katika kifungu:

• Upinzani wa jina la lebo ya Docker kwa ahadi tupu za Git.
• Ustahimilivu wa jina la lebo ya Docker kwa Git hujitolea kubadilisha faili zisizo na maana kwa picha.
• Haielekezi kwa shida ya kurekebisha toleo la sasa la picha wakati wa kuanza tena ujenzi wa ahadi za zamani za Git kwa matawi ya Git.

Itumie! Na usisahau kututembelea GitHubkuunda suala au kupata lililopo, kuongeza nyongeza, kuunda PR au kutazama tu maendeleo ya mradi.

PS

Soma pia kwenye blogi yetu:

• «toleo la werf 1.1: maboresho kwa mjenzi leo na mipango ya siku zijazo»
• «Kuanzisha werf 1.0 stable: GitOps ina uhusiano gani nayo, hali na mipango»
• «werf - zana yetu ya CI/CD katika Kubernetes (hakiki na ripoti ya video)";
• Msururu wa maelezo kuhusu uvumbuzi katika werf:
  • «Njia 3 za kuunganisha kwa werf: kupelekwa kwa Kubernetes na Helm "kwenye steroids"";
  • «Kutumia werf kusambaza chati changamano za Helm";
  • «Msaada wa monorepo na multirepo kwenye werf na Usajili wa Docker una uhusiano gani nayo";
  • «Sasa unaweza kuunda picha za Docker kwenye werf kwa kutumia Dockerfile ya kawaida'.

Chanzo: mapenzi.com