د monorepository موضوع له یو ځل څخه زیات بحث شوی او د یوې قاعدې په توګه، د خورا فعال تناقض لامل کیږي. په جوړولو سره د خلاصې سرچینې وسیلې په توګه ډیزاین شوی ترڅو د غوښتنلیک کوډ رامینځته کولو پروسې ته وده ورکړي له ګیټ څخه ډاکر عکسونو ته (او بیا یې Kubernetes ته وړاندې کوي) ، موږ پدې اړه ډیر فکر نه کوو چې کوم انتخاب غوره دی. زموږ لپاره، دا لومړنی دی چې د مختلفو نظرونو د ملاتړو لپاره اړین هرڅه چمتو کړو (که دا د عقل سره مخالفت نه کوي، البته).
د werf وروستی مونو ریپو ملاتړ د دې ښه مثال دی. مګر لومړی ، راځئ چې معلومه کړو چې دا ملاتړ په عمومي ډول د ویرف کارولو پورې اړه لري او د ډاکر راجسټري دې سره څه کوي ...
مسلې
راځئ چې داسې یو حالت تصور کړو. شرکت ډیری پرمختیایی ټیمونه لري چې په خپلواکو پروژو کار کوي. ډیری غوښتنلیکونه په Kubernetes چلیږي او له همدې امله کانټینر شوي دي. د کانټینرونو، انځورونو ذخیره کولو لپاره، تاسو راجستر (رجسټری) ته اړتیا لرئ. د ورته راجسټری په توګه ، شرکت د یو واحد حساب سره Docker Hub کاروي COMPANY. د ډیری سرچینې کوډ ذخیره کولو سیسټمونو سره ورته، د ډاکر هب د نیست شوي ذخیره کولو درجه بندي ته اجازه نه ورکوي، لکه COMPANY/PROJECT/IMAGE. پدې حالت کې ... تاسو څنګه کولی شئ د هرې پروژې لپاره جلا حساب رامینځته کولو پرته د دې محدودیت سره په راجسټری کې غیر واحد غوښتنلیکونه ذخیره کړئ؟
ښایي، بیان شوی وضعیت په لومړي سر کې یو چا ته پیژندل شوی وي، مګر راځئ چې په عمومي توګه د غوښتنلیک ذخیره کولو تنظیم کولو مسله په پام کې ونیسو، د بیلګې په توګه. پرته د پورتنۍ مثال او ډاکر هب ته مراجعه وکړئ.
د حل لارې
که غوښتنلیک monolithic، په یو عکس کې راځي ، بیا هیڅ پوښتنې شتون نلري او موږ په ساده ډول د پروژې کانټینر ثبت کې عکسونه خوندي کوو.
کله چې یو غوښتنلیک د ډیری برخو په توګه وړاندې کیږي، کوچني خدمتونهنو بیا یو مشخص چلند ته اړتیا ده. د یو عادي ویب غوښتنلیک په مثال کې چې دوه عکسونه لري: frontend и backend - ممکنه انتخابونه دا دي:
- انځورونه په جلا ځاله کې ذخیره کړئ:
- هرڅه په یوه ذخیره کې ذخیره کړئ، او په ټګ کې د عکس نوم په پام کې ونیسئ، د بیلګې په توګه، په لاندې ډول:
NB: په حقیقت کې، په مختلفو زیرمو کې د خوندي کولو سره یو بل اختیار شتون لري، PROJECT-frontend и PROJECT-backend، مګر موږ به دا د ملاتړ ، تنظیم او د کاروونکو ترمینځ د حقونو د ویش پیچلتیا له امله په پام کې ونیسو.
د werf ملاتړ
په پیل کې، werf خپل ځان د ځنځیر ذخیره کولو پورې محدود کړ - خوشبختانه، ډیری راجسترونه د دې ځانګړتیا ملاتړ کوي. له نسخې څخه پیل کول , اضافه کار د راجسترونو سره په کوم کې ځړول نه ملاتړ کیږي، او ډاکر هب یو له دوی څخه دی. له دې ځایه، کاروونکي د غوښتنلیک عکسونو ذخیره کولو څرنګوالي انتخاب لري.
پلي کول د اختیار لاندې شتون لري --images-repo-mode=multirepo|monorepo (ډیفالټ multirepo، i.e. په نیست شوي زیرمو کې ذخیره کول). دا هغه نمونې تعریفوي چې له مخې یې عکسونه په ثبت کې زیرمه شوي. دا کافي ده چې مطلوب حالت غوره کړئ کله چې لومړني حکمونه وکاروئ ، او نور هرڅه به بدل نشي.
ځکه چې ډیری werf اختیارونه ټاکل کیدی شي د چاپیریال متغیرات، په CI / CD سیسټمونو کې ، د ذخیره کولو حالت معمولا د ټولې پروژې لپاره په نړیواله کچه تنظیم کول اسانه دي. د مثال په ډول، د GitLab په قضیه کې یوازې د پروژې ترتیباتو کې د چاپیریال متغیر اضافه کړئ: ترتیبات -> CI / CD -> تغیرات: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
که موږ د عکسونو خپرولو او د غوښتنلیکونو په اړه وغږیږو (تاسو کولی شئ د دې پروسې په اړه په اړوندو اسنادو مقالو کې په تفصیل سره ولولئ: и )، بیا موډ یوازې هغه ټیمپلیټ ټاکي چې تاسو یې د عکس سره کار کولی شئ.
شیطان په تفصیل کې دی
توپیر او اصلي ستونزه کله چې د نوي ذخیره کولو میتود اضافه کول د راجسټری پاکولو په پروسه کې دي (د پاکولو ځانګړتیاو لپاره چې د werf لخوا ملاتړ کیږي، وګورئ ).
کله چې پاکول، werf د Kubernetes کلسترونو کې کارول شوي عکسونه په پام کې نیسي، او همدارنګه د کارونکي لخوا ترتیب شوي پالیسۍ. پالیسۍ په ستراتیژیو کې د ټاګونو ویش پر بنسټ والړ دي. اوس مهال ملاتړ شوي ستراتیژیانې:
- 3 ستراتیژۍ چې د Git پریمیټیو لخوا تړل شوي لکه ټګ، څانګه، او ژمن؛
- د خپلمنځي ګمرکي ټګونو لپاره 1 ستراتیژي.
موږ د ټاګ ستراتیژۍ په اړه معلومات خوندي کوو کله چې عکس د وروستي عکس لیبل کې خپروو. معنی پخپله ورته ویل کیږي میټا ټګ - د ځینو پالیسیو پلي کولو ته اړتیا ده. د مثال په توګه ، کله چې د Git ذخیره څخه څانګه یا ټاګ حذف کول ، نو د اړونده حذف کول منطقي دي غیر استعمال شوی د راجستر څخه انځورونه، کوم چې زموږ د پالیسیو د یوې برخې لخوا پوښل شوي.
کله چې په یوه ذخیره کې خوندي شي (monorepo)، د عکس په ټګ کې، د میټا ټګ سربیره، د عکس نوم هم زیرمه کیدی شي: PROJECT:frontend-META-TAG. د دوی د جلا کولو لپاره، موږ کوم ځانګړی جلا کوونکی معرفي نه کړ، مګر په ساده ډول د خپریدو پر مهال د وروستي عکس لیبل ته اړین ارزښت اضافه کړ.
NB: که تاسو د werf سرچینې کوډ کې بیان شوي هرڅه ته د کتلو لیوالتیا لرئ، نو د پیل ټکی کیدی شي .
په دې مقاله کې، موږ به زموږ د تګلارې ستونزې او توجیه کولو ته ډیر پام ونه کړو: د ټیګ کولو ستراتیژیو په اړه، په لیبلونو کې د معلوماتو ذخیره کول او په ټوله کې د خپرولو بهیر - دا ټول د دیمیتري سټولیاروف لخوا په وروستي راپور کې په تفصیل سره تشریح شوي: "".
لنډیز
د غیر منظم شوي راجسترونو لپاره د ملاتړ نشتوالی زموږ یا د werf کاروونکو لپاره چې موږ ته پیژندل شوي د بندولو فکتور نه و - په هرصورت ، تاسو کولی شئ تل د جلا عکس راجسټری پورته کړئ (یا په ګوګل کلاوډ کې مشروط کانټینر راجسټری ته لاړ شئ) ... په هرصورت ، د دې ډول محدودیت لرې کول منطقي بریښي ترڅو د وسیلې لپاره د پراخه DevOps ټولنې لپاره خورا اسانه وي. د دې پلي کولو سره، موږ د کانټینر د راجسټری پاکولو میکانیزم په بیا کار کولو کې له اصلي ستونزو سره مخ شو. اوس چې هرڅه چمتو دي، دا ښه ده چې پوه شو چې دا د یو چا لپاره اسانه شوی، او موږ (د پروژې اصلي پراختیا کونکو په توګه) به د دې ځانګړتیا په نور مالتړ کې د پام وړ ستونزې ونه لرو.
زموږ سره پاتې شئ او ډیر ژر به تاسو ته د نورو نوښتونو په اړه ووایم !
PS
زموږ په بلاګ کې هم ولولئ:
- «»
- «".
سرچینه: www.habr.com