🥇پشتیبانی از مونوروپو و چند مخزنی در werf و ارتباط رجیستری داکر با آن

موضوع مونوریپو بارها مورد بحث قرار گرفته است و به طور معمول، بحث‌های نسبتاً فعالی را ایجاد می‌کند. ورف به عنوان یک ابزار متن‌باز که برای بهبود فرآیند ساخت کد برنامه از گیت به تصاویر داکر (و متعاقباً تحویل آنها به کوبرنتیز) طراحی شده است، ما زمان زیادی را صرف گمانه‌زنی در مورد بهترین انتخاب نمی‌کنیم. دغدغه اصلی ما فراهم کردن هر آنچه برای طرفداران نظرات مختلف لازم است، می‌باشد (البته تا زمانی که با عقل سلیم در تضاد نباشد).

پشتیبانی اخیر از mono-repo در werf نمونه خوبی از این موضوع است. اما ابتدا، بیایید ببینیم که این پشتیبانی چگونه به استفاده از werf مربوط می‌شود و Docker Registry چه ارتباطی با آن دارد...

مسائل

بیایید این وضعیت را تصور کنیم. یک شرکت چندین تیم توسعه دارد که روی پروژه‌های مستقل کار می‌کنند. اکثر برنامه‌ها روی Kubernetes اجرا می‌شوند و بنابراین کانتینری شده‌اند. برای ذخیره کانتینرها و تصاویر به یک رجیستری نیاز است. این شرکت از Docker Hub به عنوان رجیستری خود، با یک حساب کاربری واحد، استفاده می‌کند. COMPANYمشابه اکثر سیستم‌های ذخیره‌سازی کد منبع، داکر هاب اجازه سلسله مراتب مخزن تو در تو را نمی‌دهد.، مانند COMPANY/PROJECT/IMAGEدر آن صورت... چگونه می‌توانیم برنامه‌های غیر یکپارچه را با این محدودیت در رجیستری ذخیره کنیم، بدون اینکه برای هر پروژه حساب جداگانه‌ای ایجاد کنیم؟

این وضعیت ممکن است برای برخی آشنا باشد، اما بیایید بدون اشاره به مثال بالا و Docker Hub، به طور کلی به موضوع سازماندهی فضای ذخیره‌سازی برنامه‌ها نگاه کنیم.

راه حل ها

اگر برنامه به صورت یکپارچه، در یک تصویر واحد ارائه می‌شود، پس هیچ سوالی پیش نمی‌آید و ما به سادگی تصاویر را در رجیستری کانتینر پروژه ذخیره می‌کنیم.

وقتی یک برنامه به صورت چندین کامپوننت ارائه می‌شود، میکروسرویس ها، سپس باید یک رویکرد خاص انتخاب شود. با استفاده از مثال یک برنامه وب معمولی که شامل دو تصویر است: frontend и backend - گزینه‌های ممکن عبارتند از:

تصاویر را در مخازن تو در تو و جداگانه ذخیره کنید:
همه چیز را در یک مخزن ذخیره کنید و نام تصویر را در تگ قرار دهید، برای مثال، مانند این:

NB: در واقع، گزینه دیگری با ذخیره در مخازن مختلف وجود دارد، PROJECT-frontend и PROJECT-backend، اما ما به دلیل پیچیدگی پشتیبانی، سازماندهی و توزیع حقوق بین کاربران، آن را در نظر نمی‌گیریم.

پشتیبانی در ورف

در ابتدا، werf خود را به مخازن تو در تو محدود می‌کرد - خوشبختانه، اکثر رجیستری‌ها از این ویژگی پشتیبانی می‌کنند. شروع با نسخه نسخه 1.0.4-alpha.3، کار با رجیستری‌هایی که در آنها لانه سازی پشتیبانی نمی شودو Docker Hub یکی از آنهاست. از این پس، کاربران می‌توانند نحوه ذخیره تصاویر برنامه را انتخاب کنند.

اجرا به صورت اختیاری در دسترس است --images-repo-mode=multirepo|monorepo (به طور پیش‌فرض multirepo(یعنی ذخیره در مخازن تو در تو). این قالب‌هایی را تعریف می‌کند که تصاویر توسط آنها در رجیستری ذخیره می‌شوند. کافیست هنگام استفاده از دستورات اولیه، حالت مورد نظر را انتخاب کنید و سایر موارد بدون تغییر باقی خواهند ماند.

از آنجا که اکثر گزینه‌های werf قابل تنظیم هستند متغیرهای محیطیدر سیستم‌های CI/CD، معمولاً تنظیم حالت ذخیره‌سازی به صورت سراسری برای کل پروژه آسان است. برای مثال، در مورد GitLab کافی است یک متغیر محیطی در تنظیمات پروژه اضافه کنید: تنظیمات -> CI / CD -> متغیرها: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

صحبت از انتشار تصاویر و راه‌اندازی برنامه‌ها شد (می‌توانید جزئیات این فرآیندها را در مقالات مربوط به مستندات بخوانید: فرآیند انتشار и فرآیند استقرار) ، سپس حالت منحصراً الگویی را تعیین می‌کند که می‌توانید با آن با تصویر کار کنید.

شیطان در جزئیات است

تفاوت و مشکل اصلی هنگام اضافه کردن یک روش ذخیره‌سازی جدید، در فرآیند تمیز کردن رجیستری است. (برای قابلیت‌های تمیزکاری پشتیبانی‌شده توسط werf، به [مراجعه کنید]) روند تمیز کردن).

هنگام پاکسازی، werf تصاویر استفاده شده در کلاسترهای Kubernetes و همچنین سیاست‌های پیکربندی شده توسط کاربر را در نظر می‌گیرد. سیاست‌ها بر اساس تقسیم برچسب‌ها به استراتژی‌ها هستند. استراتژی‌های پشتیبانی شده در حال حاضر:

۳ استراتژی مربوط به اصول اولیه گیت مانند تگ، شاخه و کامیت؛
۱ استراتژی برای تگ‌های سفارشی.

ما اطلاعات استراتژی برچسب را هنگام انتشار یک تصویر در برچسب‌های تصویر نهایی ذخیره می‌کنیم. خودِ مقدار، به اصطلاح ... است. متا تگ — برای اعمال برخی سیاست‌ها ضروری است. برای مثال، هنگام حذف یک شاخه یا برچسب از مخزن گیت، منطقی است که شاخه‌ها یا برچسب‌های مرتبط را نیز حذف کنید. استفاده نشده تصاویری از رجیستری، که تحت پوشش بخشی از سیاست‌های ما است.

هنگام ذخیره در یک مخزن (monorepo) علاوه بر متا تگ، تگ تصویر می‌تواند نام تصویر را نیز ذخیره کند: PROJECT:frontend-META-TAGبرای جدا کردن آنها، ما هیچ جداکننده خاصی را معرفی نکردیم، بلکه صرفاً مقدار لازم را به برچسب تصویر نهایی هنگام انتشار اضافه کردیم.

NBاگر علاقه‌مند به بررسی هر آنچه در کد منبع werf شرح داده شده است هستید، می‌توانید از اینجا شروع کنید. روابط عمومی 1684.

در این مقاله، ما توجه بیشتری به مشکلات و توجیه رویکرد خود نخواهیم کرد: در مورد استراتژی‌های برچسب‌گذاری، ذخیره‌سازی داده‌ها در برچسب‌ها و فرآیند انتشار به طور کلی - همه این موارد به تفصیل در گزارش اخیر دیمیتری استولیاروف شرح داده شده است: «werf ابزار ما برای CI/CD در Kubernetes است'.

به طور خلاصه

عدم پشتیبانی از رجیستری‌های غیر تو در تو برای ما یا هیچ یک از کاربران werf که می‌شناسیم، عامل بازدارنده‌ای نبود - همیشه می‌توان یک رجیستری تصویر جداگانه راه‌اندازی کرد (یا به چیزی مانند Container Registry در Google Cloud تغییر داد). با این حال، حذف این محدودیت برای قابل استفاده‌تر کردن این ابزار توسط جامعه گسترده‌تر DevOps منطقی به نظر می‌رسید. هنگام پیاده‌سازی آن، با چالش اصلی در طراحی مجدد مکانیسم پاکسازی رجیستری کانتینر مواجه شدیم. اکنون که همه چیز آماده است، خوب است بدانیم که کارها برای کسی آسان‌تر شده است و ما (به عنوان توسعه‌دهندگان اصلی پروژه) هیچ مشکل قابل توجهی را در پشتیبانی بیشتر از این ویژگی پیش‌بینی نمی‌کنیم.

با ما همراه باشید و در آینده نزدیک از نوآوری‌های دیگر برایتان خواهیم گفت. ورف!