هڪ monorepository جو موضوع هڪ ڀيرو کان وڌيڪ بحث ڪيو ويو آهي، ۽ ضابطي جي طور تي، تمام گهڻو فعال بحث جو سبب بڻيل آهي. ٺاهڻ هڪ اوپن سورس ٽول جي طور تي ٺاهيل ايپليڪيشن ڪوڊ ٺاهڻ جي عمل کي بهتر ڪرڻ لاءِ Git کان ڊاڪر تصويرن تائين (۽ پوءِ انهن کي ڪبرنيٽس تائين پهچائڻ)، اسان گهڻو نه ٿا سوچيو ته ڪهڙي چونڊ بهترين آهي. اسان لاءِ، مختلف راءِ جي حامين لاءِ ضروري هر شيءِ مهيا ڪرڻ بنيادي آهي (جيڪڏهن اهو عام احساس جي تضاد نه آهي، يقينا).
werf جي تازي مونو-ريپو سپورٽ هن جو هڪ سٺو مثال آهي. پر پهرين، اچو ته اهو ڄاڻون ته هي سپورٽ عام طور تي werf استعمال ڪرڻ سان لاڳاپيل آهي ۽ Docker رجسٽري کي ان سان ڇا ڪرڻو آهي ...
مسئلا
اچو ته اهڙي صورتحال جو تصور ڪريون. ڪمپني ۾ ڪيتريون ئي ترقياتي ٽيمون آهن جيڪي آزاد منصوبن تي ڪم ڪري رهيا آهن. اڪثر ايپليڪيشنون ڪبرنيٽس ۾ ڪم ڪن ٿيون ۽، مطابق، ڪنٽينر ٿيل آهن. ڪنٽينرز، تصويرون ذخيرو ڪرڻ لاء، توهان کي رجسٽري (رجسٽري) جي ضرورت آهي. ڪمپني استعمال ڪري ٿي Docker Hub هڪ واحد اڪائونٽ سان اهڙي رجسٽري. COMPANY. تمام گھڻا سورس ڪوڊ اسٽوريج سسٽم وانگر، Docker Hub nested repository hierarchy جي اجازت نٿو ڏئي، جيئن ته COMPANY/PROJECT/IMAGE. انهي صورت ۾… توهان هر پروجيڪٽ لاءِ الڳ اڪائونٽ ٺاهڻ کان سواءِ هن حد سان رجسٽري ۾ غير مونوليٿڪ ايپليڪيشنن کي ڪيئن محفوظ ڪري سگهو ٿا؟
ٿي سگهي ٿو، بيان ڪيل صورتحال ڪنهن ماڻهوءَ کان واقف هجي، پر اچو ته عام طور تي ايپليڪيشن اسٽوريج کي منظم ڪرڻ جي مسئلي تي غور ڪريون، يعني. مٿي ڏنل مثال ۽ Docker Hub جي حوالي کان سواء.
حل
جيڪڏهن اپليڪيشن monolithic، ھڪڙي تصوير ۾ اچي ٿو، پوء ڪو به سوال نه آھي ۽ اسان صرف تصويرن کي محفوظ ڪريون ٿا پروجيڪٽ جي ڪنٽينر رجسٽري ۾.
جڏهن هڪ ايپليڪيشن ڪيترن ئي حصن جي طور تي پيش ڪئي وئي آهي، microservicesته پوء هڪ خاص طريقو جي ضرورت آهي. ھڪڙي عام ويب ايپليڪيشن جي مثال تي ٻن تصويرن تي مشتمل آھي: frontend и backend - ممڪن اختيار آهن:
- تصويرن کي جدا جدا ذخيرو ۾ محفوظ ڪريو:
- هر شي کي هڪ مخزن ۾ ذخيرو ڪريو، ۽ ٽيگ ۾ تصوير جي نالي تي غور ڪريو، مثال طور، هن ريت:
NB: دراصل، اتي هڪ ٻيو اختيار آهي مختلف ذخيرو ۾ بچت سان، PROJECT-frontend и PROJECT-backend، پر اسان ان تي غور نه ڪنداسين ڇاڪاڻ ته سپورٽ جي پيچيدگي، تنظيم ۽ صارفين جي وچ ۾ حقن جي ورڇ.
werf جي حمايت
شروعات ۾، werf پاڻ کي nested repositories تائين محدود ڪيو - خوش قسمتي سان، اڪثر رجسٽرڊ هن خصوصيت جي حمايت ڪن ٿا. نسخي کان شروع شامل ڪيو ويو ڪم رجسٽري سان جنهن ۾ nesting سپورٽ نه آهي، ۽ Docker Hub انهن مان هڪ آهي. انهي نقطي کان، صارف وٽ هڪ اختيار آهي ته ايپليڪيشن تصويرون ڪيئن ذخيرو ڪجي.
اختيارن جي تحت دستياب آهي --images-repo-mode=multirepo|monorepo (default multirepo، i.e. nested repositories ۾ رکڻ). اهو نمونن کي بيان ڪري ٿو جنهن جي ذريعي تصويرون رجسٽري ۾ محفوظ ٿيل آهن. اهو ڪافي آهي ته گهربل موڊ چونڊڻ لاء جڏهن بنيادي حڪمن کي استعمال ڪندي، ۽ باقي هر شيء تبديل نه ٿيندي.
ڇو ته گھڻا werf آپشن سيٽ ڪري سگھجن ٿا ماحولياتي متغيرCI/CD سسٽم ۾، اسٽوريج موڊ عام طور تي سڄي منصوبي لاء عالمي سطح تي سيٽ ڪرڻ آسان آهي. مثال طور، GitLab جي صورت ۾ صرف پروجيڪٽ سيٽنگن ۾ هڪ ماحولي تبديلي شامل ڪريو: سيٽنگون -> CI / CD -> متغير: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
جيڪڏهن اسان تصويرن کي شايع ڪرڻ ۽ ايپليڪيشنن کي رول آئوٽ ڪرڻ بابت ڳالهايون ٿا (توهان انهن عملن بابت تفصيل سان لاڳاپيل دستاويزي آرٽيڪل ۾ پڙهي سگهو ٿا: и )، پوءِ موڊ صرف ٽيمپليٽ جو تعين ڪري ٿو جنھن سان توھان تصوير سان ڪم ڪري سگھو ٿا.
شيطان تفصيل ۾ آهي
فرق ۽ بنيادي مشڪل جڏهن نئين اسٽوريج جو طريقو شامل ڪرڻ جي رجسٽري کي صاف ڪرڻ جي عمل ۾ آهي (Werf پاران سپورٽ ڪيل خصوصيتن کي صاف ڪرڻ لاء، ڏسو ).
صفائي ڪرڻ وقت، werf ڪبرنيٽس ڪلسٽرز ۾ استعمال ٿيل تصويرن سان گڏوگڏ صارف پاران ترتيب ڏنل پاليسين کي به نظر ۾ رکي ٿو. پاليسيون حڪمت عملين ۾ ٽيگ جي ورهاڱي تي ٻڌل آهن. في الحال حمايت ڪيل حڪمت عمليون:
- 3 حڪمت عمليون جڙيل Git پرائمٽيوز جهڙوڪ ٽيگ، برانچ، ۽ ڪمٽ؛
- 1 حڪمت عملي ڪسٽم ٽيگ لاء.
آخري تصوير جي ليبل ۾ تصوير شايع ڪرڻ وقت اسان ٽيگ حڪمت عملي بابت معلومات محفوظ ڪندا آهيون. معنيٰ پاڻ کي سڏيو ويندو آهي ميٽا ٽيگ - ڪجهه پاليسين کي لاڳو ڪرڻ جي ضرورت آهي. مثال طور، جڏهن Git مخزن مان هڪ شاخ يا ٽيگ کي حذف ڪيو وڃي، اهو منطقي آهي ته لاڳاپيل کي ختم ڪرڻ غير استعمال ٿيل رجسٽري مان تصويرون، جيڪي اسان جي پاليسين جي حصي سان ڍڪيل آهن.
جڏهن هڪ مخزن ۾ محفوظ ڪريو (monorepo)، تصوير جي ٽيگ ۾، ميٽا ٽيگ کان علاوه، تصوير جو نالو پڻ محفوظ ڪري سگھجي ٿو: PROJECT:frontend-META-TAG. انهن کي الڳ ڪرڻ لاءِ، اسان ڪو به مخصوص ڌار ڪندڙ متعارف نه ڪرايو آهي، پر صرف شايع ڪرڻ وقت حتمي تصوير جي ليبل تي ضروري قدر شامل ڪيو آهي.
NB: جيڪڏھن توھان چاھيو ٿا ته werf سورس ڪوڊ ۾ بيان ڪيل ھر شيءِ کي ڏسڻ ۾، پوءِ شروعاتي نقطو ٿي سگھي ٿو .
هن آرٽيڪل ۾، اسان اسان جي طريقي جي مسئلن ۽ جواز تي وڌيڪ ڌيان نه ڏينداسين: ٽيگنگ جي حڪمت عملي بابت، ڊيٽا کي محفوظ ڪرڻ ۾ ليبلز ۽ مجموعي طور تي پبلشنگ جي عمل - اهو سڀ ڪجهه تفصيل سان بيان ڪيو ويو آهي دمتري اسٽولياروف جي تازي رپورٽ ۾: "».
اختصار ڪرڻ
اڻڄاتل رجسٽري لاءِ سپورٽ جو فقدان اسان لاءِ بلاڪ ڪرڻ وارو عنصر نه هو يا اسان لاءِ سڃاتل werf استعمال ڪندڙ - آخرڪار، توهان هميشه هڪ الڳ تصويري رجسٽري بلند ڪري سگهو ٿا (يا گوگل ڪلائوڊ ۾ مشروط ڪنٽينر رجسٽري ڏانهن سوئچ ڪريو) ... بهرحال، اهڙي پابندي کي هٽائڻ منطقي لڳي رهيو آهي ته جيئن اوزار کي وڌيڪ آسان بڻائي سگهجي وسيع DevOps ڪميونٽي. ان کي لاڳو ڪرڻ، اسان ڪنٽينر رجسٽري صاف ڪرڻ واري ميڪانيزم کي ٻيهر ڪم ڪرڻ ۾ بنيادي مشڪلات کي منهن ڏنو. هاڻي ته سڀڪجهه تيار آهي، اهو محسوس ڪرڻ سٺو لڳندو آهي ته اهو ڪنهن لاءِ آسان ٿي ويو آهي، ۽ اسان (جيئن پروجيڪٽ جي مکيه ڊولپرز) کي هن خصوصيت کي وڌيڪ سپورٽ ڪرڻ ۾ ڪا به قابل ذڪر مشڪلات نه هوندي.
اسان سان گڏ رهو ۽ تمام جلد اسان توهان کي ٻين جدت بابت ٻڌائينداسين !
پي ايس
اسان جي بلاگ تي پڻ پڙهو:
- «"؛
- «».
جو ذريعو: www.habr.com