Etiketimi i bazuar në përmbajtje në koleksionistin werf: pse dhe si funksionon?

werf është mjeti ynë me burim të hapur GitOps CLI për ndërtimin dhe dërgimin e aplikacioneve në Kubernetes. NË lëshimi v1.1 një veçori e re u prezantua në koleksionuesin e imazheve: etiketimi i imazheve sipas përmbajtjes ose etiketimi i bazuar në përmbajtje. Deri më tani, skema tipike e etiketimit në werf përfshinte etiketimin e imazheve të Docker nga etiketa Git, dega Git ose Git commit. Por të gjitha këto skema kanë disavantazhe që zgjidhen plotësisht nga strategjia e re e etiketimit. Detajet rreth tij dhe pse është kaq i mirë janë nën prerje.

Përgatitja e një grupi mikroshërbimesh nga një depo Git

Shpesh ndodh një situatë kur një aplikacion ndahet në shumë shërbime pak a shumë të pavarura. Lëshimet e këtyre shërbimeve mund të ndodhin në mënyrë të pavarur: një ose më shumë shërbime mund të lëshohen në të njëjtën kohë, ndërsa pjesa tjetër duhet të vazhdojë të funksionojë pa asnjë ndryshim. Por nga pikëpamja e ruajtjes së kodit dhe menaxhimit të projektit, është më i përshtatshëm për të mbajtur shërbime të tilla aplikacioni në një depo të vetme.

Ka situata kur shërbimet janë vërtet të pavarura dhe nuk shoqërohen me një aplikacion të vetëm. Në këtë rast, ato do të vendosen në projekte të veçanta dhe lëshimi i tyre do të kryhet përmes proceseve të veçanta CI/CD në secilin prej projekteve.

Megjithatë, në realitet, zhvilluesit shpesh ndajnë një aplikacion të vetëm në disa mikroshërbime, por krijimi i një depoje dhe projekti të veçantë për secilin... është një tepricë e qartë. Është kjo situatë që do të diskutohet më tej: disa mikroshërbime të tilla 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 Git dhe etiketës Git

Le të themi se përdoret strategjia më e zakonshme e etiketimit - etiketë-ose-degë. Për degët Git, imazhet etiketohen me emrin e degës, për një degë në një kohë ka vetëm një imazh të publikuar me emrin e asaj dege. Për etiketat Git, imazhet etiketohen sipas emrit të etiketës.

Kur krijohet një etiketë e re Git - për shembull, kur lëshohet një version i ri - do të krijohet një etiketë e re Docker për të gjitha imazhet e projektit në Regjistrin 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ëta emra të rinj imazhesh kalohen përmes shablloneve të Helm në konfigurimin e Kubernetes. Kur fillon vendosja me komandën werf deploy fusha po përditësohet image në burimin Kubernetes manifestohet dhe rifillon burimet përkatëse për shkak të emrit të ndryshuar të imazhit.

problem: në rastin kur, në fakt, përmbajtja e imazhit nuk ka ndryshuar që nga prezantimi i mëparshëm (etiketa Git), por vetëm etiketa e tij Docker, kjo ndodh tepricë rinisja e këtij aplikacioni dhe, në përputhje me rrethanat, është e mundur disa kohë joproduktive. Edhe pse nuk kishte asnjë arsye të vërtetë për të kryer këtë rifillim.

Si rezultat, me skemën aktuale të etiketimit është e nevojshme të rrethohen disa depo të veçanta Git dhe lind problemi i organizimit të përhapjes së këtyre disa depove. Në përgjithësi, një skemë e tillë rezulton të jetë e mbingarkuar dhe komplekse. Është më mirë të kombinoni shumë shërbime në një depo të vetme dhe të krijoni etiketa Docker në mënyrë që të mos ketë rifillime të panevojshme.

Etiketimi nga Git commit

werf gjithashtu ka një strategji etiketimi të lidhur me angazhimet Git.

Git-commit është një identifikues për përmbajtjen e një depoje Git dhe varet nga historia e redaktimit të skedarëve në depo Git, kështu që duket logjike ta përdorni atë për etiketimin e imazheve në Regjistrin Docker.

Sidoqoftë, etiketimi nga Git commit ka të njëjtat disavantazhe si etiketimi nga degët Git ose etiketat Git:

• Mund të krijohet një angazhim bosh që nuk ndryshon asnjë skedar, por etiketa Docker e imazhit do të ndryshohet.
• Mund të krijohet një bashkim që nuk ndryshon skedarët, por etiketa Docker e imazhit do të ndryshohet.
• Mund të bëhet një angazhim që ndryshon ato skedarë në Git që nuk importohen në imazh dhe etiketa Docker e imazhit do të ndryshohet përsëri.

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

Ekziston një problem tjetër që lidhet me strategjinë e etiketimit për degët Git.

Etiketimi sipas emrit të degës funksionon për sa kohë që angazhimet në atë degë mblidhen në mënyrë sekuenciale në rend kronologjik.

Nëse në skemën aktuale përdoruesi fillon të rindërtojë një commit të vjetër të lidhur me një degë të caktuar, atëherë werf do ta rishkruajë imazhin duke përdorur etiketën përkatëse Docker me një version të ri të ndërtuar të imazhit për kryerjen e vjetër. Vendosjet që përdorin këtë etiketë tani e tutje rrezikojnë të tërheqin një version tjetër të imazhit kur rinisin pods, si rezultat i të cilit aplikacioni ynë do të humbasë lidhjen me sistemin CI dhe do të desinkronizohet.

Për më tepër, me shtytje të njëpasnjëshme në një degë me një periudhë të shkurtër kohore ndërmjet tyre, angazhimi i vjetër mund të përpilohet më vonë se ai më i ri: versioni i vjetër i imazhit do të mbishkruajë të riun duke përdorur etiketën e degës Git. Probleme të tilla mund të zgjidhen nga një sistem CI/CD (për shembull, në GitLab CI tubacioni i këtij të fundit lëshohet për një sërë angazhimesh). Megjithatë, jo të gjitha sistemet e mbështesin këtë dhe duhet të ketë një mënyrë më të besueshme për të parandaluar një problem kaq themelor.

Çfarë është etiketimi i bazuar në përmbajtje?

Pra, çfarë është etiketimi i bazuar në përmbajtje - etiketimi i imazheve sipas përmbajtjes.

Për të krijuar etiketa Docker, nuk përdoren primitivet Git (dega Git, etiketa Git...), por një kontroll i lidhur me:

• përmbajtjen e imazhit. Etiketa ID e imazhit pasqyron përmbajtjen e saj. Kur ndërtoni një version të ri, ky identifikues nuk do të ndryshojë nëse skedarët në imazh nuk kanë ndryshuar;
• historia e krijimit të këtij imazhi në Git. Imazhet e lidhura me degë të ndryshme Git dhe histori të ndryshme ndërtimi nëpërmjet werf do të kenë etiketa të ndryshme ID.

Një etiketë e tillë identifikuese është e ashtuquajtura nënshkrimi i skenës së imazhit.

Çdo imazh përbëhet nga një grup fazash: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch etj. Çdo fazë ka një identifikues që pasqyron përmbajtjen e tij − nënshkrimi skenik (nënshkrimi i skenës).

Imazhi përfundimtar, i përbërë nga këto faza, është etiketuar me të ashtuquajturën nënshkrim të grupit të këtyre fazave - nënshkrimi i fazave, - e cila është përgjithësuese për të gjitha fazat e imazhit.

Për çdo imazh nga konfigurimi werf.yaml në rastin e përgjithshëm, do të ketë nënshkrimin e vet dhe, në përputhje me rrethanat, një etiketë Docker.

Nënshkrimi i skenës zgjidh të gjitha këto probleme:

• Rezistent ndaj angazhimeve të zbrazëta të Git.
• Resistant to Git kryen ndryshimin e skedarëve që nuk janë të rëndësishëm për imazhin.
• Nuk çon në problemin e rishikimit të versionit aktual të imazhit kur rinisni ndërtimet për kryerjet e vjetra Git të një dege.

Kjo tani është strategjia e rekomanduar e etiketimit dhe është parazgjedhja në werf për të gjitha sistemet CI.

Si të aktivizoni dhe përdorni në werf

Komanda tani ka një opsion përkatës werf publish: --tag-by-stages-signature=true|false

Në një sistem CI, strategjia e etiketimit specifikohet nga komanda werf ci-env. Më parë, parametri ishte përcaktuar për të werf ci-env --tagging-strategy=tag-or-branch. Tani, nëse specifikoni werf ci-env --tagging-strategy=stages-signature ose mos e specifikoni këtë opsion, werf do të përdorë strategjinë e etiketimit si parazgjedhje stages-signature. Ekipi werf ci-env automatikisht do të vendosë flamujt e nevojshëm për komandën werf build-and-publish (Ose werf publish), kështu që nuk duhet të specifikohen opsione shtesë 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ë imazhet e 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 backendDhe f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - nënshkrimi i fazave të imazhit frontend.

Kur përdorni funksione të veçanta werf_container_image и werf_container_env Nuk ka nevojë të ndryshoni asgjë në shabllonet e Helm: këto funksione do të gjenerojnë automatikisht emrat e saktë të imazheve.

Shembull i konfigurimit në një sistem CI:

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

Më shumë informacion mbi konfigurimin është në dispozicion në dokumentacionin:

• Drejtoria → Publikimi (publikimi);
• Puna me CI/CD → Informacion i përgjithshëm → faza-nënshkrimi;
• Integrimi me GitLab CI/CD → .gitlab-ci.yml.

Në total

• Opsion 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, parazgjedhja do të jetë stages-signature).
• Nëse keni përdorur më parë opsionet e etiketimit për Git commits (WERF_TAG_GIT_COMMIT ose opsion werf publish --tag-git-commit COMMIT), atëherë sigurohuni që të kaloni në strategjinë e etiketimit faza-nënshkrimi.
• Është më mirë të kaloni menjëherë projektet e reja në skemën e re të etiketimit.
• Kur transferoni në werf 1.1, këshillohet të kaloni projektet e vjetra në skemën e re të etiketimit, por të vjetër etiketë-ose-degë është ende i mbështetur.

Etiketimi i bazuar në përmbajtje zgjidh të gjitha problemet e mbuluara në artikull:

• Rezistenca e emrit të etiketës Docker ndaj angazhimeve të zbrazëta të Git.
• Rezistenca e emrit të etiketës Docker në Git bën që të ndryshojë skedarët që nuk kanë lidhje me imazhin.
• Nuk çon në problemin e rishikimit të versionit aktual të imazhit kur rinisni ndërtimet për angazhimet e vjetra Git për degët e Git.

Perdore! Dhe mos harroni të na vizitoni në GitHubpër të krijuar një problem ose për të gjetur një ekzistues, shtoni një plus, krijoni një PR ose thjesht shikoni zhvillimin e projektit.

PS

Lexoni edhe në blogun tonë:

• «Verf 1.1 version: përmirësime për ndërtuesin sot dhe planet për të ardhmen»
• «Prezantimi i werf 1.0 stabil: çfarë lidhje ka GitOps me të, statusin dhe planet»
• «werf - mjeti ynë për CI / CD në Kubernetes (përmbledhje dhe raport video)"?
• Një seri shënimesh rreth risive në werf:
  • «Bashkimi me tre drejtime në werf: vendosja në Kubernetes me Helm "në steroid""?
  • «Përdorimi i werf-it për të nxjerrë grafikët komplekse të Helm-it"?
  • «Mbështetje për monorepo dhe multirepo në werf dhe çfarë ka të bëjë Regjistri Docker me të"?
  • «Tani mund të ndërtoni imazhe Docker në werf duke përdorur një Dockerfile të rregullt'.

Burimi: www.habr.com