🥇 ويرف ۾ مونوريپو ۽ ملٽي ريپو سپورٽ ۽ ڊاڪر رجسٽري جو ان سان ڇا تعلق آهي

مونوريپو جي موضوع تي ڪيترائي ڀيرا بحث ڪيو ويو آهي ۽، ضابطي جي طور تي، ڪافي سرگرم بحثن جو سبب بڻجندو آهي. werf هڪ اوپن سورس ٽول جي طور تي جيڪو گٽ کان ڊاڪر تصويرن ۾ ايپليڪيشن ڪوڊ ٺاهڻ جي عمل کي بهتر بڻائڻ لاءِ ٺاهيو ويو آهي (۽ بعد ۾ انهن کي ڪبرنيٽس تائين پهچائڻ)، اسان گهڻو وقت اهو اندازو لڳائڻ ۾ نه گذاريندا آهيون ته ڪهڙو انتخاب بهترين آهي. اسان جو بنيادي خدشو مختلف راين جي حمايت ڪندڙن لاءِ ضروري هر شيءِ فراهم ڪرڻ آهي (جيستائين اهو عام فهم جي خلاف نه هجي، يقيناً).

وي آر ايف ۾ تازو شامل ڪيل مونو-ريپو سپورٽ ان جي هڪ سٺي مثال آهي. پر پهرين، اچو ته اهو معلوم ڪريون ته هي سپورٽ وي آر ايف جي استعمال سان ڪيئن لاڳاپيل آهي ۽ ڊڪر رجسٽري جو ان سان ڪهڙو تعلق آهي...

مسئلا

اچو ته هن صورتحال جو تصور ڪريون. هڪ ڪمپني وٽ ڪيتريون ئي ترقياتي ٽيمون آهن جيڪي آزاد منصوبن تي ڪم ڪري رهيون آهن. گهڻيون ايپليڪيشنون ڪبرنيٽس تي هلن ٿيون ۽ تنهن ڪري ڪنٽينرائزڊ آهن. ڪنٽينر ۽ تصويرن کي ذخيرو ڪرڻ لاءِ هڪ رجسٽري جي ضرورت آهي. ڪمپني هڪ اڪائونٽ سان، ڊوڪر هب کي پنهنجي رجسٽري طور استعمال ڪري ٿي. COMPANY. گھڻن سورس ڪوڊ اسٽوريج سسٽم وانگر، ڊاڪر هب نيسٽڊ ريپوزٽري هيئرارچيز جي اجازت نٿو ڏئي.، جيئن ته COMPANY/PROJECT/IMAGEانهي صورت ۾... اسان هر منصوبي لاءِ الڳ اڪائونٽ ٺاهڻ کان سواءِ، هن حد سان رجسٽري ۾ غير مونوليٿڪ ايپليڪيشنن کي ڪيئن ذخيرو ڪري سگهون ٿا؟

هي صورتحال ڪجهه ماڻهن لاءِ واقف ٿي سگهي ٿي، پر اچو ته مٿي ڏنل مثال ۽ ڊاڪر هب جي حوالي کان سواءِ، عام طور تي ايپليڪيشن اسٽوريج کي منظم ڪرڻ جي مسئلي تي نظر وجهون.

حل

جيڪڏهن درخواست هڪجهڙائي سان، هڪ واحد تصوير ۾ فراهم ڪئي ويندي آهي، پوءِ ڪو به سوال پيدا نه ٿيندو آهي ۽ اسان صرف تصويرن کي پروجيڪٽ جي ڪنٽينر رجسٽري ۾ محفوظ ڪندا آهيون.

جڏهن هڪ ايپليڪيشن ڪيترن ئي حصن جي طور تي پيش ڪئي ويندي آهي، microservices، پوءِ هڪ مخصوص طريقو چونڊڻ گهرجي. ٻن تصويرن تي مشتمل هڪ عام ويب ايپليڪيشن جي مثال کي استعمال ڪندي: frontend и backend — ممڪن آپشن آهن:

تصويرون الڳ الڳ نيسٽڊ ريپوزٽريز ۾ محفوظ ڪريو:
هر شيءِ کي هڪ ذخيري ۾ ذخيرو ڪريو، ۽ ٽيگ ۾ تصوير جو نالو شامل ڪريو، مثال طور، هن طرح:

NB: اصل ۾، مختلف ذخيرن ۾ محفوظ ڪرڻ سان هڪ ٻيو آپشن آهي، PROJECT-frontend и PROJECT-backend، پر اسان ان تي غور نه ڪنداسين ڇاڪاڻ ته استعمال ڪندڙن جي وچ ۾ مدد، تنظيم ۽ حقن جي ورڇ جي پيچيدگي جي ڪري.

وي آر ايف تي سپورٽ

شروعات ۾، werf پاڻ کي نيسٽڊ ريپوزٽريز تائين محدود ڪيو - خوشقسمتيءَ سان، گهڻيون رجسٽريون هن خصوصيت جي حمايت ڪن ٿيون. ورجن سان شروع ڪندي v1.0.4-alpha.3، رجسٽرين سان ڪم شامل ڪيو ويو جنهن ۾ نيسٽنگ جي سهولت نه آهي.، ۽ ڊاڪر هب انهن مان هڪ آهي. هاڻي کان، صارفين وٽ ايپليڪيشن تصويرون ڪيئن ذخيرو ڪرڻ جو انتخاب آهي.

لاڳو ڪرڻ هڪ آپشن جي طور تي موجود آهي --images-repo-mode=multirepo|monorepo (ڊفالٽ طور تي multirepo(يعني، نيسٽڊ ريپوزٽريز ۾ اسٽور ڪرڻ). اهو ٽيمپليٽ کي بيان ڪري ٿو جنهن ذريعي تصويرون رجسٽري ۾ محفوظ ڪيون وينديون آهن. بنيادي حڪمن کي استعمال ڪندي صرف گهربل موڊ چونڊيو، ۽ باقي سڀ ڪجهه تبديل نه ٿيندو.

ڇاڪاڻ ته گھڻا werf آپشن سيٽ ڪري سگھجن ٿا ماحولياتي متغيرCI/CD سسٽم ۾، اسٽوريج موڊ عام طور تي سڄي منصوبي لاءِ عالمي سطح تي سيٽ ڪرڻ آسان آهي. مثال طور، GitLab جي صورت ۾ پروجيڪٽ سيٽنگز ۾ هڪ ماحولياتي متغير شامل ڪرڻ ڪافي آهي: سيٽنگون -> سي آءِ / سي ڊي -> متغير: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

تصويرن جي اشاعت ۽ ايپليڪيشنن جي رول آئوٽ جي ڳالهه ڪندي (توهان انهن عملن بابت تفصيل سان لاڳاپيل دستاويزي مضمونن ۾ پڙهي سگهو ٿا: اشاعت جو عمل и عمل کي ترتيب ڏيو)، پوءِ موڊ خاص طور تي ٽيمپليٽ کي طئي ڪري ٿو جنهن ذريعي توهان تصوير سان ڪم ڪري سگهو ٿا.

شيطان تفصيل ۾ آهي

نئون اسٽوريج طريقو شامل ڪرڻ وقت فرق ۽ مکيه ڏکيائي رجسٽري کي صاف ڪرڻ جي عمل ۾ آهي. (وي آر ايف جي مدد سان صفائي جي صلاحيتن لاءِ، ڏسو صفائي جو عمل).

صفائي ڪرڻ وقت، werf ڪبرنيٽس ڪلسٽرز ۾ استعمال ٿيندڙ تصويرن کي، ۽ گڏوگڏ صارف پاران ترتيب ڏنل پاليسين کي به نظر ۾ رکي ٿو. پاليسيون ٽيگ کي حڪمت عملين ۾ ورهائڻ تي ٻڌل آهن. في الحال سپورٽ ٿيل حڪمت عمليون:

گٽ پرائميٽوز سان لاڳاپيل 3 حڪمت عمليون جهڙوڪ ٽيگ، برانچ، ۽ ڪمٽ؛
ڪسٽم ٽيگ لاءِ 1 حڪمت عملي.

اسان آخري تصوير جي ليبلز ۾ تصوير شايع ڪرڻ وقت ٽيگ حڪمت عملي جي معلومات محفوظ ڪندا آهيون. قدر پاڻ کي سڏيو ويندو آهي ميٽا ٽيگ — ڪجهه پاليسين کي لاڳو ڪرڻ لاءِ ضروري آهي. مثال طور، جڏهن Git ريپوزٽري مان برانچ يا ٽيگ کي حذف ڪيو وڃي، ته اهو سمجهه ۾ اچي ٿو ته لاڳاپيل کي به ختم ڪيو وڃي. غير استعمال ٿيل رجسٽري جون تصويرون، جيڪي اسان جي پاليسين جي حصي ۾ شامل آهن.

جڏهن هڪ مخزن ۾ محفوظ ڪيو وڃي (monorepo)، ميٽا ٽيگ کان علاوه، تصويري ٽيگ تصوير جو نالو پڻ محفوظ ڪري سگھي ٿو: PROJECT:frontend-META-TAGانهن کي الڳ ڪرڻ لاءِ، اسان ڪو به مخصوص جدا ڪندڙ متعارف نه ڪرايو، پر صرف اشاعت تي آخري تصوير جي ليبل ۾ ضروري قدر شامل ڪئي.

NB: جيڪڏهن توهان werf سورس ڪوڊ ۾ بيان ڪيل هر شيءِ کي ڏسڻ ۾ دلچسپي رکو ٿا، ته پوءِ هڪ شروعاتي نقطو ٿي سگهي ٿو اسهيو 1684.

هن آرٽيڪل ۾، اسان پنهنجي طريقي جي مسئلن ۽ جواز تي وڌيڪ ڌيان نه ڏينداسين: ٽيگنگ حڪمت عملين، ليبلز ۾ ڊيٽا محفوظ ڪرڻ ۽ عام طور تي اشاعت جي عمل بابت - اهو سڀ ڪجهه دمتري اسٽولياروف جي تازي رپورٽ ۾ تفصيل سان بيان ڪيو ويو آهي: "werf اسان جو اوزار آهي CI/CD لاءِ Kubernetes ۾».

اختصار ڪرڻ

غير نيسٽڊ رجسٽري لاءِ سپورٽ جي کوٽ اسان لاءِ يا اسان جي ڄاڻ وارن ڪنهن به وي آر ايف استعمال ڪندڙن لاءِ ڊيل بريڪر نه هئي - اهو هميشه ممڪن آهي ته هڪ الڳ تصوير رجسٽري قائم ڪئي وڃي (يا گوگل ڪلائوڊ ۾ ڪنٽينر رجسٽري جهڙي ڪنهن شيءِ ڏانهن سوئچ ڪيو وڃي). بهرحال، هن حد کي هٽائڻ منطقي لڳي رهيو هو ته جيئن ٽول کي وسيع DevOps ڪميونٽي پاران وڌيڪ استعمال لائق بڻايو وڃي. ان کي لاڳو ڪرڻ دوران، اسان ڪنٽينر رجسٽري جي صفائي جي ميڪانيزم کي ٻيهر ڊزائين ڪرڻ ۾ مکيه چئلينج کي منهن ڏنو. هاڻي جڏهن ته سڀ ڪجهه تيار آهي، اهو ڄاڻڻ سٺو آهي ته شيون ڪنهن لاءِ آسان ٿي ويون آهن، ۽ اسان (پروجيڪٽ جي ليڊ ڊولپرز جي حيثيت سان) هن خصوصيت کي وڌيڪ سپورٽ ڪرڻ ۾ ڪنهن به اهم مشڪلاتن جي توقع نٿا ڪريون.

ڏسندا رهو ۽ اسان توهان کي ويجهي مستقبل ۾ ٻين جدتن بابت ٻڌائينداسين. werf!