🥇Werf kollektorida kontentga asoslangan teglash: u nima uchun va qanday ishlaydi?

werf ilovalarni yaratish va Kubernetesga yetkazib berish uchun ochiq manbali GitOps CLI yordamchi dasturimiz. IN v1.1 versiyasi Tasvirlar kollektorida yangi xususiyat joriy etildi: tasvirlarni kontent bo'yicha belgilash yoki kontentga asoslangan teglash. Hozirgacha werf-dagi odatiy teglash sxemasi Docker tasvirlarini Git tegi, Git filiali yoki Git commiti orqali teglashni o'z ichiga olgan. Ammo bu sxemalarning barchasida yangi teglash strategiyasi tomonidan to'liq hal qilinadigan kamchiliklar mavjud. Bu haqda batafsil ma'lumot va nima uchun bu juda yaxshi - kesma ostida.

Bitta Git omboridan mikroservislar to'plamini chiqarish

Vaziyat ko'pincha dastur ko'p yoki kamroq mustaqil xizmatlarga bo'linganida yuzaga keladi. Ushbu xizmatlarning relizlari mustaqil ravishda amalga oshirilishi mumkin: bir yoki bir nechta xizmatlar bir vaqtning o'zida chiqarilishi mumkin, qolganlari esa hech qanday o'zgarishsiz ishlashda davom etishi kerak. Ammo kodni saqlash va loyihalarni boshqarish nuqtai nazaridan bunday dastur xizmatlarini yagona omborda saqlash qulayroqdir.

Xizmatlar haqiqatan ham mustaqil bo'lgan va bitta dastur bilan bog'lanmagan holatlar mavjud. Bunday holda, ular alohida loyihalarda joylashtiriladi va ularning chiqarilishi har bir loyihada alohida CI/CD jarayonlari orqali amalga oshiriladi.

Biroq, aslida, ishlab chiquvchilar ko'pincha bitta dasturni bir nechta mikroservislarga bo'lishadi, lekin har biri uchun alohida ombor va loyiha yaratish ... aniq ortiqcha. Aynan shu holat keyingi muhokama qilinadi: bir nechta bunday mikroservislar bitta loyiha omborida joylashgan va relizlar CI/CDda bitta jarayon orqali amalga oshiriladi.

Git filiali va Git tegi bo'yicha teglash

Aytaylik, eng keng tarqalgan teglash strategiyasi qo'llaniladi - teg yoki filial. Git filiallari uchun rasmlar filial nomi bilan teglanadi, bitta filial uchun bir vaqtning o'zida faqat bitta filial nomi bilan chop etilgan rasm mavjud. Git teglari uchun tasvirlar teg nomiga ko'ra teglanadi.

Yangi Git yorlig'i yaratilganda, masalan, yangi versiya chiqarilganda, Docker registridagi barcha loyiha tasvirlari uchun yangi Docker yorlig'i yaratiladi:

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

Ushbu yangi tasvir nomlari Helm shablonlari orqali Kubernetes konfiguratsiyasiga uzatiladi. Buyruq bilan tarqatishni boshlashda werf deploy maydon yangilanmoqda image Kubernetes resursida o'zgartirilgan tasvir nomi tufayli tegishli resurslarni namoyon qiladi va qayta ishga tushiradi.

muammo: agar rasmning mazmuni avvalgi chiqarilishdan beri o'zgarmagan bo'lsa (Git yorlig'i), faqat uning Docker tegi bo'lsa, bu sodir bo'ladi. ortiqcha ushbu ilovani qayta ishga tushirish va shunga mos ravishda, bir oz ishlamay qolish mumkin. Garchi bu qayta ishga tushirishni amalga oshirish uchun haqiqiy sabab yo'q edi.

Natijada, joriy teglash sxemasi bilan bir nechta alohida Git omborlarini to'sib qo'yish kerak bo'ladi va bu bir nechta omborlarni ishlab chiqarishni tashkil qilish muammosi paydo bo'ladi. Umuman olganda, bunday sxema ortiqcha yuk va murakkab bo'lib chiqadi. Keraksiz qayta ishga tushirishlar bo'lmasligi uchun ko'plab xizmatlarni bitta omborga birlashtirish va Docker teglarini yaratish yaxshiroqdir.

Git commit tomonidan teglash

werf shuningdek, Git commits bilan bog'liq teglash strategiyasiga ega.

Git-commit - bu Git ombori tarkibining identifikatori va Git omboridagi fayllarni tahrirlash tarixiga bog'liq, shuning uchun uni Docker registridagi rasmlarni teglash uchun ishlatish mantiqiy ko'rinadi.

Biroq, Git commit tomonidan teglash Git filiallari yoki Git teglari tomonidan teglash kabi kamchiliklarga ega:

Hech qanday faylni o'zgartirmaydigan bo'sh topshiriq yaratilishi mumkin, lekin rasmning Docker yorlig'i o'zgartiriladi.
Fayllarni o'zgartirmaydigan birlashtirish majburiyati yaratilishi mumkin, ammo tasvirning Docker yorlig'i o'zgaradi.
Tasvirga import qilinmagan Git fayllarini o'zgartirish majburiyatini olish mumkin va rasmning Docker yorlig'i yana o'zgartiriladi.

Git filiali nomini teglash rasm versiyasini aks ettirmaydi

Git filiallari uchun teglash strategiyasi bilan bog'liq yana bir muammo mavjud.

Filial nomi boʻyicha teg qoʻyish, agar ushbu filial boʻyicha majburiyatlar xronologik tartibda ketma-ket yigʻilsa, ishlaydi.

Agar joriy sxemada foydalanuvchi ma'lum bir filial bilan bog'langan eski majburiyatni qayta qurishni boshlasa, u holda werf eski topshiriq uchun rasmning yangi qurilgan versiyasi bilan mos keladigan Docker tegidan foydalanib tasvirni qayta yozadi. Bundan buyon ushbu tegdan foydalangan holda joylashtirishlar podkastlarni qayta ishga tushirishda tasvirning boshqa versiyasini tortib olish xavfini tug'diradi, buning natijasida bizning ilovamiz CI tizimi bilan aloqani yo'qotadi va sinxronlashtirilmaydi.

Bunga qo'shimcha ravishda, ular orasidagi qisqa vaqt oralig'ida bitta filialga ketma-ket surishlar bilan, eski majburiyat yangisiga qaraganda kechroq tuzilishi mumkin: rasmning eski versiyasi Git filiali tegi yordamida yangisini yozadi. Bunday muammolarni CI/CD tizimi hal qilish mumkin (masalan, GitLab CI-da ikkinchisining quvur liniyasi bir qator majburiyatlar uchun ishga tushiriladi). Biroq, barcha tizimlar buni qo'llab-quvvatlamaydi va bunday asosiy muammoning oldini olishning yanada ishonchli usuli bo'lishi kerak.

Kontentga asoslangan teglash nima?

Shunday qilib, kontentga asoslangan teglash nima - tasvirlarni kontent bo'yicha belgilash.

Docker teglarini yaratish uchun Git primitivlari (Git filiali, Git yorlig'i...) emas, balki quyidagilar bilan bog'liq nazorat summasi ishlatiladi:

tasvirning mazmuni. Rasm ID yorlig'i uning mazmunini aks ettiradi. Yangi versiyani yaratishda, agar rasmdagi fayllar o'zgarmagan bo'lsa, bu identifikator o'zgarmaydi;
Git-da ushbu tasvirni yaratish tarixi. Turli Git filiallari va werf orqali turli xil qurish tarixi bilan bog'langan rasmlar turli ID teglariga ega bo'ladi.

Bunday identifikator teg deyiladi tasvir bosqichi imzosi.

Har bir rasm bir qator bosqichlardan iborat: from, before-install, git-archive, install, imports-after-install, before-setup... git-latest-patch va hokazo. Har bir bosqichda uning mazmunini aks ettiruvchi identifikator mavjud - sahna imzosi (sahna imzosi).

Ushbu bosqichlardan iborat yakuniy rasm ushbu bosqichlar to'plamining imzosi deb ataladi - imzolash bosqichlari, - tasvirning barcha bosqichlari uchun umumlashtiruvchi.

Konfiguratsiyadan har bir rasm uchun werf.yaml umumiy holatda o'z imzosi va shunga mos ravishda Docker tegi bo'ladi.

Sahna imzosi ushbu muammolarni hal qiladi:

Bo'sh Git topshiriqlariga chidamli.
Git-ga chidamli, rasmga tegishli bo'lmagan fayllarni o'zgartirish majburiyatini oladi.
Filialning eski Git topshiriqlari uchun tuzilmalarni qayta ishga tushirishda tasvirning joriy versiyasini qayta ko'rib chiqish muammosiga olib kelmaydi.

Bu endi tavsiya etilgan teglash strategiyasi va barcha CI tizimlari uchun werf standarti hisoblanadi.

werf-da qanday yoqish va foydalanish

Buyruqda endi mos variant mavjud werf publish: --tag-by-stages-signature=true|false

CI tizimida teglash strategiyasi buyruq bilan belgilanadi werf ci-env. Ilgari, u uchun parametr aniqlangan werf ci-env --tagging-strategy=tag-or-branch. Endi aniqlasangiz werf ci-env --tagging-strategy=stages-signature yoki bu variantni belgilamang, werf sukut bo'yicha teglash strategiyasidan foydalanadi stages-signature. Jamoa werf ci-env avtomatik ravishda buyruq uchun kerakli bayroqlarni o'rnatadi werf build-and-publish (yoki werf publish), shuning uchun bu buyruqlar uchun qo'shimcha parametrlarni ko'rsatish shart emas.

Masalan, buyruq:

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

...quyidagi tasvirlarni yaratishi mumkin:

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

u 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d tasvir bosqichlarining imzosi hisoblanadi backendva f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - tasvir bosqichlarining imzosi frontend.

Maxsus funktsiyalardan foydalanganda werf_container_image и werf_container_env Helm shablonlarida biror narsani o'zgartirishga hojat yo'q: bu funksiyalar avtomatik ravishda to'g'ri tasvir nomlarini yaratadi.

CI tizimidagi konfiguratsiyaga misol:

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

Konfiguratsiya haqida ko'proq ma'lumot hujjatlarda mavjud:

jami

Yangi variant werf publish --tag-by-stages-signature=true|false.
Yangi variant qiymati werf ci-env --tagging-strategy=stages-signature|tag-or-branch (agar belgilanmagan bo'lsa, standart bo'ladi stages-signature).
Agar siz ilgari Git commits uchun teglash opsiyalaridan foydalangan bo'lsangiz (WERF_TAG_GIT_COMMIT yoki variant werf publish --tag-git-commit COMMIT), keyin teglash strategiyasiga o'tishni unutmang bosqichlari - imzo.
Yangi loyihalarni darhol yangi teglar sxemasiga o'tkazish yaxshiroqdir.
Werf 1.1 ga o'tishda eski loyihalarni yangi teglash sxemasiga o'tkazish tavsiya etiladi, lekin eski teg yoki filial hali ham qo'llab-quvvatlanadi.

Kontentga asoslangan teglar maqolada ko'rib chiqilgan barcha muammolarni hal qiladi:

Docker teg nomi bo'sh Git topshiriqlariga qarshilik.
Docker teg nomining Gitga chidamliligi tasvirga aloqador bo'lmagan fayllarni o'zgartiradigan majburiyatlarni bajaradi.
Git filiallari uchun eski Git majburiyatlari uchun tuzilmalarni qayta ishga tushirishda tasvirning joriy versiyasini qayta ko'rib chiqish muammosiga olib kelmaydi.

Buni ishlat! Va bizga tashrif buyurishni unutmang GitHubmuammo yaratish yoki mavjud muammoni topish, ortiqcha qo'shish, PR yaratish yoki shunchaki loyihaning rivojlanishini tomosha qilish.

PS

Shuningdek, bizning blogimizda o'qing:

Manba: www.habr.com

Werf kollektorida kontentga asoslangan teglash: u nima uchun va qanday ishlaydi?