Mono-repozitoriy mavzusi bir necha marta muhokama qilingan va qoida tariqasida juda faol bahs-munozaralarga sabab bo'ladi. Yaratish orqali Git-dan Docker-ga ilova kodini yaratish (keyin ularni Kubernetes-ga etkazib berish) jarayonini yaxshilash uchun mo'ljallangan ochiq manbali vosita sifatida biz qaysi tanlov yaxshiroq ekanligi haqida ko'p o'ylamaymiz. Biz uchun har xil fikrlar tarafdorlari uchun zarur bo'lgan hamma narsani ta'minlash birinchi navbatda (agar bu sog'lom fikrga zid bo'lmasa, albatta).
werfning so'nggi mono-repo qo'llab-quvvatlashi bunga yaxshi misoldir. Birinchidan, keling, ushbu yordam odatda werf-dan foydalanish bilan qanday bog'liqligini va Docker Registry bu bilan qanday aloqasi borligini aniqlaymiz ...
Muammolar
Keling, bunday vaziyatni tasavvur qilaylik. Kompaniyada mustaqil loyihalar ustida ishlaydigan ko'plab rivojlanish guruhlari mavjud. Ko'pgina ilovalar Kubernetes-da ishlaydi va shuning uchun konteynerlashtirilgan. Konteynerlarni, tasvirlarni saqlash uchun sizga registr (ro'yxatga olish kitobi) kerak. Bunday ro'yxatga olish kitobi sifatida kompaniya Docker Hub-dan bitta hisob qaydnomasi bilan foydalanadi COMPANY. Ko'pgina manba kodlarini saqlash tizimlariga o'xshash, Docker Hub ichki omborlar ierarxiyasiga ruxsat bermaydi, kabi COMPANY/PROJECT/IMAGE. Bunday holda... har bir loyiha uchun alohida hisob yaratmasdan qanday qilib monolit bo'lmagan ilovalarni ushbu cheklov bilan registrda saqlashingiz mumkin?
Ehtimol, tasvirlangan vaziyat kimgadir tanishdir, lekin keling, umuman olganda, ilovalarni saqlashni tashkil etish masalasini ko'rib chiqaylik, ya'ni. yuqoridagi misol va Docker Hub ga havolasiz.
Yechimlar
Agar dastur monolit, bitta rasmda keladi, keyin hech qanday savol yo'q va biz shunchaki tasvirlarni loyihaning konteyner registriga saqlaymiz.
Ilova bir nechta komponentlar sifatida taqdim etilganda, mikroservislar, keyin ma'lum bir yondashuv talab qilinadi. Ikkita rasmdan iborat odatiy veb-ilova misolida: frontend ΠΈ backend - mumkin bo'lgan variantlar:
- Tasvirlarni alohida joylashtirilgan omborlarda saqlang:
- Hamma narsani bitta omborda saqlang va tegdagi rasm nomini ko'rib chiqing, masalan, quyidagicha:
NB: Aslida, turli xil omborlarda saqlashning yana bir varianti bor, PROJECT-frontend ΠΈ PROJECT-backend, lekin biz buni qo'llab-quvvatlash, tashkil etish va foydalanuvchilar o'rtasida huquqlarni taqsimlashning murakkabligi tufayli ko'rib chiqmaymiz.
werf qo'llab-quvvatlash
Dastlab, werf o'zini ichki omborlar bilan chekladi - xayriyatki, ko'pchilik registrlar bu xususiyatni qo'llab-quvvatlaydi. Versiyadan boshlab , unda registrlar bilan ishlash qo'shildi joylashtirish qo'llab-quvvatlanmaydi, va Docker Hub ulardan biri. Shu vaqtdan boshlab foydalanuvchi dastur tasvirlarini qanday saqlashni tanlash huquqiga ega.
Amalga oshirish variant ostida mavjud --images-repo-mode=multirepo|monorepo (standart multirepo, ya'ni. ichki omborlarda saqlash). Bu ro'yxatga olish kitobida tasvirlar saqlanadigan naqshlarni belgilaydi. Asosiy buyruqlardan foydalanganda kerakli rejimni tanlash kifoya, qolgan hamma narsa o'zgarishsiz qoladi.
Chunki ko'pchilik werf opsiyalarini o'rnatish mumkin atrof-muhit o'zgaruvchilari, CI / CD tizimlarida saqlash rejimi odatda butun loyiha uchun global miqyosda o'rnatilishi oson. Masalan, GitLab misolida faqat loyiha sozlamalarida muhit o'zgaruvchisini qo'shing: Sozlamalar -> CI / CD -> O'zgaruvchilar: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Agar biz rasmlarni nashr qilish va ilovalarni tarqatish haqida gapiradigan bo'lsak (siz ushbu jarayonlar haqida tegishli hujjatlar maqolalarida batafsil o'qishingiz mumkin: ΠΈ ), keyin rejim faqat rasm bilan ishlashingiz mumkin bo'lgan shablonni belgilaydi.
Shayton tafsilotlarda
Yangi saqlash usulini qo'shishda farq va asosiy qiyinchilik ro'yxatga olish kitobini tozalash jarayonida (werf tomonidan qo'llab-quvvatlanadigan tozalash xususiyatlari uchun qarang ).
Tozalashda werf Kubernetes klasterlarida ishlatiladigan tasvirlarni, shuningdek, foydalanuvchi tomonidan sozlangan siyosatlarni hisobga oladi. Siyosat teglarni strategiyalarga bo'linishga asoslanadi. Hozirda qo'llab-quvvatlanadigan strategiyalar:
- Teg, filial va majburiyat kabi Git primitivlari bilan bog'langan 3 ta strategiya;
- O'zboshimchalik bilan maxsus teglar uchun 1 strategiya.
Tasvirni yakuniy rasmning teglarida nashr qilishda teg strategiyasi haqidagi ma'lumotlarni saqlaymiz. Ma'noning o'zi shunday deb ataladi meta teg - Ba'zi siyosatlarni qo'llash uchun talab qilinadi. Misol uchun, Git omboridan filial yoki tegni o'chirishda, tegishli bo'lgan narsalarni o'chirish mantiqan to'g'ri keladi foydalanilmagan bizning siyosatimizning bir qismi bo'lgan registrdagi tasvirlar.
Bitta omborda saqlanganda (monorepo), rasm tegida meta tegdan tashqari tasvir nomi ham saqlanishi mumkin: PROJECT:frontend-META-TAG. Ularni ajratish uchun biz biron bir alohida ajratgichni kiritmadik, balki nashr qilishda yakuniy rasmning yorlig'iga kerakli qiymatni qo'shdik.
NB: Agar siz werf manba kodida tasvirlangan hamma narsani ko'rib chiqishga qiziqsangiz, unda boshlang'ich nuqta bo'lishi mumkin .
Ushbu maqolada biz muammolarga va yondashuvimizni asoslashga ko'proq e'tibor bermaymiz: yorliqlash strategiyalari, ma'lumotlarni yorliqlarda saqlash va umuman nashr qilish jarayoni - bularning barchasi Dmitriy Stolyarovning yaqinda e'lon qilgan hisobotida batafsil tavsiflangan: "".
Xulosa
Kirilmagan registrlarni qo'llab-quvvatlamaslik biz yoki bizga ma'lum bo'lgan werf foydalanuvchilari uchun blokirovka qiluvchi omil emas edi - axir, siz har doim alohida rasm registrini yaratishingiz mumkin (yoki Google Cloud-da shartli konteyner registriga o'tishingiz) ... Biroq, Bunday cheklovni olib tashlash, vosita kengroq DevOps hamjamiyatiga qulayroq bo'lishi uchun mantiqiy tuyuldi. Uni amalga oshirishda biz konteyner registrini tozalash mexanizmini qayta ishlashda asosiy qiyinchilikka duch keldik. Endi hamma narsa tayyor, bu kimgadir osonroq bo'lganini tushunish juda yoqimli va biz (loyihaning asosiy ishlab chiquvchilari sifatida) ushbu xususiyatni qo'llab-quvvatlashda sezilarli qiyinchiliklarga duch kelmaymiz.
Biz bilan qoling va tez orada biz sizga boshqa innovatsiyalar haqida aytib beramiz !
PS
Shuningdek, bizning blogimizda o'qing:
- Β«";
- Β«".
Manba: www.habr.com