ProHoster > Blog > Administrim > Etiketimi e bazuar në përmbajtje në grumbulluesin werf: pse dhe si funksionon?

Etiketimi e bazuar në përmbajtje në grumbulluesin werf: pse dhe si funksionon?

Etiketimi e bazuar në përmbajtje në grumbulluesin werf: pse dhe si funksionon?

werf — mjet Ă«shtĂ« GitOps CLI pĂ«r ndihmĂ« dhe dorĂ«zimi i aplikacioneve nĂ« Kubernetes. nĂ« versionin v1.1 u prezantua njĂ« mundĂ«si e re nĂ« ndĂ«rtuesin e imazheve: etiketimi i imazheve sipas pĂ«rmbajtjes ose content-based tagging. Deri tani, skema tipike e etiketimit nĂ« werf parashikonte etiketimin e imazheve Docker sipas tag-Ă«ve Git, degĂ«ve Git ose komiteteve Git. Por tĂ« gjitha kĂ«to skema kanĂ« disavantazhe qĂ« zgjidhen plotĂ«sisht nga strategjia e re e etiketimit. Detajet pĂ«r tĂ« dhe pse Ă«shtĂ« kaq e mirĂ« — mĂ« poshtĂ«.

Depozita e një grupi mikroshërbimesh nga një depo Git

Ndodh shpesh që aplikacioni të jetë i ndarë në shumë shërbime më shumë-më pak të pavarura. Lëshimet e këtyre shërbimeve mund të ndodhin në mënyrë të pavarur: një ose disa shërbime mund të lëshohen në një herë, ndërsa të tjerët duhet të vazhdojnë të funksionojnë pa ndonjë ndryshim. Por nga këndvështrimi i ruajtjes së kodit dhe menaxhimit të projektit, është më e lehtë të mbash këto shërbime të aplikacionit në një depo të vetme.

Ka situata kur shërbimet janë vërtet të pavarura dhe nuk lidhen me një aplikacion të vetëm. Në atë rast ato do të vendosen në projekte të veçanta dhe lëshimi i tyre do të bëhet përmes proceseve të veçanta CI/CD në çdo projekt.

MegjithatĂ«, nĂ« praktikĂ«, zhvilluesit shpesh e ndajnĂ« njĂ« aplikacion tĂ« vetme nĂ« disa mikroshĂ«rbime, por tĂ« krijosh njĂ« depo dhe projekt tĂ« veçantĂ« pĂ«r çdo një  Ă«shtĂ« qartĂ« e tepruar. PĂ«r kĂ«tĂ« situatĂ« do tĂ« flitet mĂ« tutje: disa nga kĂ«to mikroshĂ«rbime ndodhen nĂ« njĂ« depo tĂ« vetme projekti dhe lĂ«shimet ndodhin pĂ«rmes njĂ« procesi tĂ« vetĂ«m nĂ« CI/CD.

Etiketimi sipas degës dhe tag-ëve Git

Supozoni se pĂ«rdoret strategjia mĂ« e zakonshme e etiketimit — tag-or-branch. PĂ«r degĂ«t Git, imazhet etiketohen me emrin e degĂ«s; pĂ«r njĂ« dege, nĂ« njĂ« moment tĂ« caktuar ekziston vetĂ«m njĂ« imazh i publikuar me emrin e kĂ«saj dege. PĂ«r tag-Ă«t Git, imazhet etiketohen pĂ«rkatĂ«sisht me emrin e tag-ut.

Kur krijohet njĂ« tag i ri Git — pĂ«r shembull, kur del njĂ« version i ri — pĂ«r tĂ« gjitha imazhet e projektit nĂ« Docker Registry do tĂ« krijohet njĂ« tag i ri 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

Këto emra të rinj të imazheve kalojnë përmes shablloneve Helm në konfigurimin Kubernetes. Gjatë fillimit të deploy-it me komandën werf deploy ndodh përditësimi i fushës image në manifestet e burimeve Kubernetes dhe rindezja e burimeve përkatëse për shkak të ndryshimit të emrit të imazhit.

Problemi: në rastin kur përmbajtja e imazhit nuk ka ndryshuar nga versioni i mëparshëm (Git-tag), por vetëm Docker-tag-u i tij është ndryshuar, ndodh rindezja e panevojshme e këtij aplikacioni dhe, si rrjedhojë, mund të ndodhi një ndalesë e caktuar. Edhe pse nuk ka pasur asnjë arsye të vërtetë për të kryer këtë rindezje.

Si pasojĂ«, me skemĂ«n aktuale tĂ« etiketimit, duhet tĂ« krijohen disa depo Git tĂ« veçanta dhe shfaqet problemi i organizimit tĂ« ndezjes sĂ« kĂ«tyre disa depo. NĂ« pĂ«rgjithĂ«si, njĂ« skemĂ« e tillĂ« del e rĂ«ndĂ« dhe e komplikuar. ËshtĂ« mĂ« mirĂ« tĂ« bashkohen shumĂ« shĂ«rbime nĂ« njĂ« depo tĂ« vetme dhe tĂ« krijohen etiketa Docker tĂ« tilla qĂ« tĂ« mos ka rindezje tĂ« panevojshme.

Etiketimi sipas Git-commit

Në werf gjithashtu ka një strategji etiketimi të lidhur me Git-commit.

Git-commit është identifikuesi i përmbajtjes së depozitës Git dhe varet nga historia e ndryshimeve të skedave në depozitën Git, prandaj duket logjike ta përdorësh atë për etiketimin e imazheve në Docker Registry.

Megjithatë, etiketimi sipas Git-commit ka të njëjtat disavantazhe si etiketimi sipas degëve Git ose Git-tag-eve:

  • Mund tĂ« ketĂ« njĂ« commit tĂ« zbrazĂ«t, i cili nuk ndryshon skedat, por Docker-tag-u i imazhit do tĂ« jetĂ« ndryshuar.
  • Mund tĂ« ketĂ« njĂ« merge-commit, i cili nuk ndryshon skedat, por Docker-tag-u i imazhit do tĂ« jetĂ« ndryshuar.
  • Mund tĂ« ketĂ« njĂ« commit, i cili ndryshon ato skeda nĂ« Git qĂ« nuk importohen nĂ« imazh, dhe Docker-tag-u i imazhit pĂ«rsĂ«ri do tĂ« ndryshojĂ«.

Etiketimi sipas emrit të degës Git nuk pasqyron versionin e imazhit.

Ka edhe një problem tjetër, i lidhur me strategjinë e etiketimit sipas degëve Git.

Etiketimi sipas emrit të degës funksionon derisa commit-et e kësaj dege përmbledhin radhazi në rend kronologjik.

Nëse në skemën aktuale përdoruesi nis ripërpunimin e një commit-i të vjetër, i lidhur me një degë të caktuar, atëherë werf do të mbivendosë imazhin sipas Docker-tag-ut me versionin e ri të mbledhur të imazhit për commit-in e vjetër. Deployment-et që përdorin këtë tag nga ky moment rrezikojnë që gjatë rindezjes së pod-eve të tërheqin një version tjetër të imazhit, për pasojë, aplikacioni ynë do të humbasë lidhjen me sistemin CI, duke u desinkronizuar.

PĂ«r mĂ« tepĂ«r, gjatĂ« push’ave tĂ« njĂ«pasnjĂ«shme nĂ« njĂ« degĂ« me njĂ« interval tĂ« vogĂ«l kohor midis tyre, komiti i vjetĂ«r mund tĂ« grumbullohet mĂ« vonĂ« se ai mĂ« i ri: versioni i vjetĂ«r i imazhit do tĂ« mbulojĂ« atĂ« mĂ« tĂ« ri nĂ« etiketĂ«n e degĂ«s Git. KĂ«to probleme mund tĂ« zgjidhen nga sistemi CI/CD (p.sh., nĂ« GitLab CI, njĂ« pipeline niset pĂ«r serinĂ« e komiteve tĂ« fundit). MegjithatĂ«, kjo nuk mbĂ«shtetet nga tĂ« gjithĂ« sistemet dhe duhet tĂ« ketĂ« njĂ« mĂ«nyrĂ« mĂ« tĂ« besueshme pĂ«r tĂ« parandaluar njĂ« problem kaq themelor.

ÇfarĂ« Ă«shtĂ« etiketimi bazuar nĂ« pĂ«rmbajtje?

Pra, çfarĂ« Ă«shtĂ« etiketimi bazuar nĂ« pĂ«rmbajtje — etiketimi i imazheve sipas pĂ«rmbajtjes.

Për të krijuar etiketat Docker, nuk përdoren primitivët e Git (dega Git, etiketë Git
), por një checksum e lidhur me:

  • pĂ«rmbajtjen e imazhit. Identifikuesi-etiketĂ« i imazhit pasqyron pĂ«rmbajtjen e tij. Kur ndĂ«rtohet njĂ« version i ri, ky identifikues nuk do tĂ« ndryshojĂ« nĂ«se skedarĂ«t nĂ« imazh nuk kanĂ« ndryshuar;
  • historinĂ« e krijimit tĂ« kĂ«tij imazhi nĂ« Git. Imazhet qĂ« lidhen me degĂ« tĂ« ndryshme Git dhe histori tĂ« ndryshme ndĂ«rtimi pĂ«rmes werf, do tĂ« kenĂ« identifikues tĂ« ndryshĂ«m etiketash.

Si një identifikues të tillë etikete shërben e ashtuquajtura nënshkrimi i fazave të imazhit.

Çdo imazh pĂ«rbĂ«het nga njĂ« grup fazash: from, before-install, git-archive, instalo, imports-after-install, before-setup,
 git-latest-patch etj. Çdo fazĂ« ka njĂ« identifikues qĂ« pasqyron pĂ«rmbajtjen e saj, — nĂ«nshkrimi i fazĂ«s (nĂ«nshkrimi i fazĂ«s).

Imazhi pĂ«rfundimtar, qĂ« pĂ«rbĂ«het nga kĂ«to faza, etiketizohet me atĂ« qĂ« quhet nĂ«nshkrimi i grupit tĂ« kĂ«tyre fazave — stages signature, — i cili Ă«shtĂ« pĂ«rmbledhĂ«s pĂ«r tĂ« gjitha fazat e imazhit.

Çdo imazh nga konfigurimi werf.yaml nĂ« pĂ«rgjithĂ«si do tĂ« ketĂ« njĂ« tĂ« tillĂ« nĂ«nshkrim dhe, pĂ«r rrjedhojĂ«, njĂ« etiketĂ« Docker.

Nënshkrimi i fazave zgjidh të gjitha problemet e përmendura:

  • ËshtĂ« e qĂ«ndrueshme ndaj komiteteve tĂ« zbrazĂ«ta Git.
  • ËshtĂ« e qĂ«ndrueshme ndaj komiteteve Git qĂ« ndryshojnĂ« skedarĂ« qĂ« nuk janĂ« tĂ« rĂ«ndĂ«sishĂ«m pĂ«r imazhin.
  • Nuk çon nĂ« problemin e mbulimit tĂ« versionit aktual tĂ« imazhit gjatĂ« rinisjes sĂ« ndĂ«rtimeve pĂ«r komitetet e vjetra tĂ« degĂ«s Git.

Tani kjo është strategjia e rekomanduar për etiketimin dhe përdoret si parazgjedhje në werf për të gjitha sistemet CI.

Si ta aktivizoni dhe përdorni në werf

Opsioni përkatës u shfaq te ekipi werf publish: --tag-by-stages-signature=true|false

Në sistemin CI, strategjia e etiketimit përcaktohet me komandën werf ci-env. Më parë për të ishte përcaktuar një parametër werf ci-env --tagging-strategy=tag-or-branch. Tani, nëse e specifikoni werf ci-env --tagging-strategy=stages-signature apo jo këtë opsion, werf do të përdorë si parazgjedhje strategjinë e etiketimit stages-signature. Komanda werf ci-env do t'i vendosë automatikisht flamujt e nevojshëm për komandën werf build-and-publish (ose werf publish), përveç kësaj, nuk ka nevojë të tregoni opsione të tjera për këto komanda.

PĂ«r shembull, komanda:

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


 mund të krijojë imazhe të mëposhtme:

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

KĂ«tu 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d — Ă«shtĂ« njĂ« nĂ«nshkrim i fazave tĂ« imazhit backend, ndĂ«rsa f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 — nĂ«nshkrim i fazave tĂ« imazhit frontend.

Kur përdoren funksione speciale werf_container_image dhe werf_container_env në shabllonet Helm nuk është e nevojshme të ndryshoni asgjë: këto funksione do të gjenerojnë automatikisht emrat e saktë të imazheve.

Shembulli i konfigurimit në sistemin CI:

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

Informacione më të plota mbi konfigurimin janë të disponueshme në dokumentacion:

Përveç kësaj

  • Opsioni i ri werf publish --tag-by-stages-signature=true|false.
  • Vlera e re e opsionit werf ci-env --tagging-strategy=stages-signature|tag-or-branch (nĂ«se nuk specifikohet, atĂ«herĂ« do tĂ« jetĂ« nga default stages-signature).
  • NĂ«se deri mĂ« tani ishin pĂ«rdorur opsione etiketimi sipas Git-komitĂ«ve (WERF_TAG_GIT_COMMIT apo opsioni werf publish --tag-git-commit COMMIT), atĂ«herĂ« Ă«shtĂ« e domosdoshme tĂ« kaloni nĂ« strategjinĂ« e etiketimit stages-signature.
  • Projektet e reja Ă«shtĂ« mĂ« mirĂ« t'i kaloni menjĂ«herĂ« nĂ« skemĂ«n e re tĂ« etiketimit.
  • Projektet e vjetra gjatĂ« kalimit nĂ« werf 1.1 Ă«shtĂ« e dĂ«shirueshme tĂ« kalojnĂ« nĂ« skemĂ«n e re tĂ« etiketimit, megjithatĂ« e vjetra tag-or-branch ende mbetet e mbĂ«shtetur.

Etiketimi të bazuar në përmbajtje zgjidh të gjitha problemet e rëna në artikull:

  • QĂ«ndrueshmĂ«ria e emrit tĂ« etiketĂ«s Docker ndaj Git-komitĂ«ve tĂ« zbrazĂ«t.
  • QĂ«ndrueshmĂ«ria e emrit tĂ« etiketĂ«s Docker ndaj Git-komitĂ«ve qĂ« ndryshojnĂ« skedarĂ« jo relevante pĂ«r imazhin.
  • Nuk çon nĂ« problem me zĂ«vendĂ«simin e versionit aktual tĂ« imazhit gjatĂ« rilansimit tĂ« ndĂ«rtimeve pĂ«r Git-komitĂ«t e vjetĂ«r pĂ«r degĂ«t Git.

Shfrytëzoni! Dhe mos harroni të na vizitoni në GitHub, për të krijuar një çështje ose gjetur një të tillë ekzistuese, të vendosni një plus, të krijoni PR ose thjesht të ndiqni zhvillimin e projektit.

P.S.

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster