ProHoster > Blogs > Administrācija > Satura marÄ·Ä“Å”ana werf savācējā: kāpēc un kā tā darbojas?

Satura marÄ·Ä“Å”ana werf savācējā: kāpēc un kā tā darbojas?

Satura marÄ·Ä“Å”ana werf savācējā: kāpēc un kā tā darbojas?

werf ir mÅ«su atvērtā pirmkoda GitOps CLI utilÄ«ta lietojumprogrammu izveidei un piegādei Kubernetes. IN laidiens v1.1 attēlu savācējā tika ieviesta jauna funkcija: attēlu atzÄ«mÄ“Å”ana pēc satura vai uz saturu balstÄ«ta marÄ·Ä“Å”ana. LÄ«dz Å”im tipiskā werf marÄ·Ä“Å”anas shēma ietvēra Docker attēlu marÄ·Ä“Å”anu, izmantojot Git tag, Git branch vai Git commit. Taču visām Ŕīm shēmām ir trÅ«kumi, kurus pilnÄ«bā atrisina jaunā marÄ·Ä“Å”anas stratēģija. SÄ«kāka informācija par to un to, kāpēc tas ir tik labs, ir atrodams.

Mikropakalpojumu kopas izvērÅ”ana no viena Git repozitorija

Bieži rodas situācija, kad lietojumprogramma tiek sadalÄ«ta daudzos vairāk vai mazāk neatkarÄ«gos servisos. Å o pakalpojumu izlaiÅ”ana var notikt neatkarÄ«gi: vienu vai vairākus pakalpojumus var izlaist vienlaikus, bet pārējiem jāturpina darboties bez izmaiņām. Bet no koda glabāŔanas un projektu vadÄ«bas viedokļa Ŕādus lietojumprogrammu pakalpojumus ir ērtāk turēt vienā repozitorijā.

Pastāv situācijas, kad pakalpojumi ir patiesi neatkarīgi un nav saistīti ar vienu pieteikumu. Šajā gadījumā tie tiks izvietoti atseviŔķos projektos un to izlaiŔana tiks veikta, izmantojot atseviŔķus CI/CD procesus katrā no projektiem.

Tomēr patiesÄ«bā izstrādātāji nereti sadala vienu aplikāciju vairākos mikropakalpojumos, taču katram izveidot atseviŔķu repozitoriju un projektu... ir nepārprotama pārpÅ«le. TieÅ”i Ŕī situācija tiks apspriesta tālāk: vairāki Ŕādi mikropakalpojumi atrodas vienā projektu repozitorijā, un izlaidumi notiek, izmantojot vienu procesu CI/CD.

AtzÄ«mÄ“Å”ana pēc Git filiāles un Git taga

Pieņemsim, ka tiek izmantota visizplatÄ«tākā marÄ·Ä“Å”anas stratēģija. tag-vai-zars. Git filiālēm attēli tiek atzÄ«mēti ar filiāles nosaukumu, vienai filiālei vienlaikus ir tikai viens publicēts attēls ar Ŕīs filiāles nosaukumu. Git tagiem attēli tiek marķēti atbilstoÅ”i taga nosaukumam.

Kad tiek izveidots jauns Git tags, piemēram, kad tiek izlaista jauna versija, visiem projekta attēliem Docker reģistrā tiks izveidots jauns Docker tags:

  • 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

Å ie jaunie attēlu nosaukumi caur Helm veidnēm tiek nodoti Kubernetes konfigurācijai. Uzsākot izvietoÅ”anu ar komandu werf deploy lauks tiek atjaunināts image Kubernetes resursa manifestos un atbilstoÅ”o resursu restartÄ“Å”anu mainÄ«tā attēla nosaukuma dēļ.

problēma: gadÄ«jumā, ja faktiski attēla saturs nav mainÄ«jies kopÅ” iepriekŔējās izlaiÅ”anas (Git tags), bet tikai tā Docker tags, tas notiek papildus restartējot Å”o lietojumprogrammu, un attiecÄ«gi ir iespējama dÄ«kstāve. Lai gan nebija Ä«sta iemesla veikt Å”o restartÄ“Å”anu.

Rezultātā ar paÅ”reizējo marÄ·Ä“Å”anas shēmu ir nepiecieÅ”ams norobežot vairākas atseviŔķas Git repozitorijus, un rodas problēma, organizējot Å”o vairāku krātuvju izlaiÅ”anu. Kopumā Ŕāda shēma izrādās pārslogota un sarežģīta. Labāk ir apvienot daudzus pakalpojumus vienā repozitorijā un izveidot Docker tagus, lai nebÅ«tu nevajadzÄ«gu restartÄ“Å”anu.

AtzīmēŔana, izmantojot Git commit

werf ir arÄ« marÄ·Ä“Å”anas stratēģija, kas saistÄ«ta ar Git saistÄ«bām.

Git-commit ir Git repozitorija satura identifikators un ir atkarÄ«gs no failu rediģēŔanas vēstures Git repozitorijā, tāpēc Ŕķiet loÄ£iski to izmantot attēlu marÄ·Ä“Å”anai Docker reÄ£istrā.

Tomēr atzÄ«mÄ“Å”anai ar Git commit ir tādi paÅ”i trÅ«kumi kā atzÄ«mÄ“Å”anai ar Git filiālēm vai Git tagiem:

  • Var izveidot tukÅ”u apņemÅ”anos, kas nemaina nevienu failu, bet attēla Docker tags tiks mainÄ«ts.
  • Var izveidot sapludināŔanas apņemÅ”anos, kas nemaina failus, bet attēla Docker tags tiks mainÄ«ts.
  • Var tikt izveidota apņemÅ”anās, kas maina tos Git failus, kas nav importēti attēlā, un attēla Docker tags tiks mainÄ«ts vēlreiz.

Git filiāles nosaukuma atzÄ«mÄ“Å”ana neatspoguļo attēla versiju

Ir vēl viena problēma, kas saistÄ«ta ar Git filiāļu marÄ·Ä“Å”anas stratēģiju.

AtzÄ«mÄ“Å”ana pēc filiāles nosaukuma darbojas tik ilgi, kamēr Ŕīs filiāles saistÄ«bas tiek apkopotas secÄ«gi hronoloÄ£iskā secÄ«bā.

Ja paÅ”reizējā shēmā lietotājs sāk atjaunot veco apņemÅ”anos, kas saistÄ«ta ar noteiktu atzaru, tad werf pārrakstÄ«s attēlu, izmantojot atbilstoÅ”o Docker tagu ar jaunizveidotu attēla versiju vecajai izpildei. Izvietojot Å”o tagu, turpmāk pastāv risks, ka, restartējot aplikumus, tiks izvilkta cita attēla versija, kā rezultātā mÅ«su lietojumprogramma zaudēs savienojumu ar CI sistēmu un tiks desinhronizēta.

Turklāt, veicot secÄ«gus virzienus vienā zarā ar Ä«su laika periodu starp tiem, vecā apņemÅ”anās var tikt apkopota vēlāk nekā jaunākā: vecā attēla versija pārrakstÄ«s jauno, izmantojot Git filiāles tagu. Šādas problēmas var atrisināt, izmantojot CI/CD sistēmu (piemēram, GitLab CI tiek palaists pēdējās konveijera izpildes sērija). Tomēr ne visas sistēmas to atbalsta, un ir jābÅ«t uzticamākam veidam, kā novērst Ŕādu bÅ«tisku problēmu.

Kas ir uz saturu balstīta marķēŔana?

Tātad, kas ir uz saturu balstÄ«ta tagu pievienoÅ”ana - attēlu atzÄ«mÄ“Å”ana pēc satura.

Lai izveidotu Docker tagus, tiek izmantoti nevis Git primitīvi (Git filiāle, Git tags...), bet gan kontrolsumma, kas saistīta ar:

  • attēla saturu. Attēla ID tags atspoguļo tā saturu. Veidojot jaunu versiju, Å”is identifikators nemainÄ«sies, ja attēla faili nav mainÄ«juÅ”ies;
  • Ŕī attēla izveides vēsture programmā Git. Attēliem, kas saistÄ«ti ar dažādām Git filiālēm un atŔķirÄ«gu bÅ«vÄ“Å”anas vēsturi, izmantojot werf, bÅ«s atŔķirÄ«gi ID tagi.

Šāds identifikatora tags ir tā sauktais attēla skatuves paraksts.

Katrs attēls sastāv no vairākiem posmiem: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch utt. Katram posmam ir identifikators, kas atspoguļo tā saturu āˆ’ skatuves paraksts (skatuves paraksts).

GalÄ«gais attēls, kas sastāv no Å”iem posmiem, ir atzÄ«mēts ar tā saukto Å”o posmu kopas parakstu - posmu paraksts, - kas ir vispārinoÅ”s visiem attēla posmiem.

Katram attēlam no konfigurācijas werf.yaml vispārīgā gadījumā būs savs paraksts un attiecīgi Docker tags.

Skatuves paraksts atrisina visas Ŕīs problēmas:

  • IzturÄ«gs pret tukŔām Git saistÄ«bām.
  • IzturÄ«gs pret Git saistÄ«bām, kas maina failus, kas nav saistÄ«ti ar attēlu.
  • Neizraisa problēmas, kas saistÄ«tas ar paÅ”reizējās attēla versijas pārskatÄ«Å”anu, restartējot bÅ«vējumus vecajām filiāles Git saistÄ«bām.

Tagad Ŕī ir ieteicamā marÄ·Ä“Å”anas stratēģija, un tā ir noklusējuma werf vērtÄ«ba visām CI sistēmām.

Kā iespējot un izmantot werf

Komandai tagad ir atbilstoŔa opcija werf publish: --tag-by-stages-signature=true|false

CI sistēmā marÄ·Ä“Å”anas stratēģiju nosaka komanda werf ci-env. IepriekÅ” tam tika noteikts parametrs werf ci-env --tagging-strategy=tag-or-branch. Tagad, ja norādāt werf ci-env --tagging-strategy=stages-signature vai nenorādiet Å”o opciju, werf pēc noklusējuma izmantos marÄ·Ä“Å”anas stratēģiju stages-signature. Komanda werf ci-env automātiski iestatÄ«s komandai nepiecieÅ”amos karogus werf build-and-publish (Vai werf publish), tāpēc Ŕīm komandām nav jānorāda papildu opcijas.

Piemēram, komanda:

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

...var izveidot Ŕādus attēlus:

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

Šeit 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d ir attēla posmu paraksts backendUn f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - attēla posmu paraksts frontend.

Izmantojot Ä«paÅ”as funkcijas werf_container_image Šø werf_container_env Helm veidnēs nekas nav jāmaina: Ŕīs funkcijas automātiski Ä£enerēs pareizos attēlu nosaukumus.

Konfigurācijas piemērs CI sistēmā:

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

PlaŔāka informācija par konfigurāciju ir pieejama dokumentācijā:

Kopā

  • Jauna iespēja werf publish --tag-by-stages-signature=true|false.
  • Jauna opcijas vērtÄ«ba werf ci-env --tagging-strategy=stages-signature|tag-or-branch (ja nav norādÄ«ts, noklusējuma vērtÄ«ba bÅ«s stages-signature).
  • Ja iepriekÅ” izmantojāt atzÄ«mÄ“Å”anas opcijas Git saistÄ«bām (WERF_TAG_GIT_COMMIT vai opcija werf publish --tag-git-commit COMMIT), pēc tam noteikti pārslēdzieties uz atzÄ«mÄ“Å”anas stratēģiju posmi-paraksts.
  • Labāk ir nekavējoties pārslēgt jaunus projektus uz jauno marÄ·Ä“Å”anas shēmu.
  • Pārejot uz werf 1.1, vecos projektus vēlams pārslēgt uz jauno marÄ·Ä“Å”anas shēmu, bet veco tag-vai-zars joprojām tiek atbalstÄ«ts.

Satura marÄ·Ä“Å”ana atrisina visas rakstā aplÅ«kotās problēmas:

  • Docker taga nosaukuma izturÄ«ba pret tukŔām Git saistÄ«bām.
  • Docker taga nosaukuma noturÄ«ba pret Git apņemas mainÄ«t failus, kas nav saistÄ«ti ar attēlu.
  • Neizraisa problēmas, kas saistÄ«tas ar paÅ”reizējās attēla versijas pārskatÄ«Å”anu, restartējot veco Git saistÄ«bu bÅ«vējumus Git filiālēm.

Lieto to! Un neaizmirstiet mÅ«s apmeklēt plkst GitHubizveidot problēmu vai atrast esoÅ”u, ielikt plusu, izveidot PR vai vienkārÅ”i vērot projekta attÄ«stÄ«bu.

PS

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru