موضوع یک مخزن بیش از یک بار مورد بحث قرار گرفته است و به عنوان یک قاعده، جنجال های بسیار فعالی ایجاد می کند. با ایجاد به عنوان یک ابزار منبع باز طراحی شده برای بهبود فرآیند ساخت کد برنامه از تصاویر Git به Docker (و سپس تحویل آنها به Kubernetes)، ما زیاد به بهترین انتخاب فکر نمی کنیم. برای ما، ارائه هر چیزی که لازم است برای طرفداران عقاید مختلف (البته اگر این با عقل سلیم مغایرت نداشته باشد) مقدم است.
پشتیبانی اخیر مونو-ریپوی werf نمونه خوبی از این موضوع است. اما ابتدا، بیایید بفهمیم که چگونه این پشتیبانی به طور کلی با استفاده از werf مرتبط است و Docker Registry با آن چه ارتباطی دارد ...
مسائل
بیایید چنین وضعیتی را تصور کنیم. این شرکت دارای تیم های توسعه زیادی است که روی پروژه های مستقل کار می کنند. اکثر برنامه‌ها بر روی Kubernetes اجرا می‌شوند و در نتیجه کانتینری هستند. برای ذخیره ظروف، تصاویر، به یک رجیستری (رجیستری) نیاز دارید. این شرکت از Docker Hub به عنوان یک رجیستری با یک حساب واحد استفاده می کند COMPANY. مشابه اکثر سیستم های ذخیره سازی کد منبع، Docker Hub اجازه سلسله مراتب مخزن تودرتو را نمی دهد، مانند COMPANY/PROJECT/IMAGE. در این صورت ... چگونه می توانید برنامه های غیر یکپارچه را در رجیستری با این محدودیت ذخیره کنید بدون اینکه برای هر پروژه یک حساب جداگانه ایجاد کنید؟
شاید وضعیت توصیف شده برای کسی آشنا باشد، اما بیایید موضوع سازماندهی ذخیره سازی برنامه را به طور کلی در نظر بگیریم، یعنی. بدون ارجاع به مثال بالا و داکر هاب.
راه حل ها
اگر برنامه یکپارچه، در یک تصویر می آید، سپس هیچ سوالی وجود ندارد و ما به سادگی تصاویر را در رجیستری کانتینر پروژه ذخیره می کنیم.
هنگامی که یک برنامه کاربردی به صورت چند مؤلفه ارائه می شود، میکروسرویس ها، سپس رویکرد خاصی مورد نیاز است. به عنوان مثال یک برنامه وب معمولی متشکل از دو تصویر: frontend и backend - گزینه های ممکن عبارتند از:
- ذخیره تصاویر در مخازن تو در تو جداگانه:
- همه چیز را در یک مخزن ذخیره کنید و نام تصویر را در تگ به عنوان مثال به صورت زیر در نظر بگیرید:
NB: در واقع، گزینه دیگری با ذخیره در مخازن مختلف وجود دارد، PROJECT-frontend и PROJECT-backend، اما به دلیل پیچیدگی پشتیبانی، سازماندهی و توزیع حقوق بین کاربران، آن را در نظر نخواهیم گرفت.
پشتیبانی werf
در ابتدا، werf خود را به مخازن تو در تو محدود کرد - خوشبختانه، اکثر رجیستری ها از این ویژگی پشتیبانی می کنند. شروع از نسخه ، اضافه شده کار با رجیستری که در آن تودرتو پشتیبانی نمی شودو Docker Hub یکی از آنهاست. از آن نقطه به بعد، کاربر حق دارد که چگونه تصاویر برنامه را ذخیره کند.
پیاده سازی در زیر گزینه موجود است --images-repo-mode=multirepo|monorepo (پیش فرض multirepo، یعنی ذخیره سازی در مخازن تو در تو). الگوهای ذخیره تصاویر در رجیستری را مشخص می کند. کافی است هنگام استفاده از دستورات اولیه حالت مورد نظر را انتخاب کنید و بقیه موارد بدون تغییر باقی می مانند.
زیرا اکثر گزینه های werf قابل تنظیم هستند متغیرهای محیطیدر سیستم‌های CI/CD، حالت ذخیره‌سازی معمولاً به راحتی برای کل پروژه تنظیم می‌شود. مثلا، در مورد GitLab فقط یک متغیر محیطی را در تنظیمات پروژه اضافه کنید: تنظیمات -> CI / CD -> متغیرها: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
اگر در مورد انتشار تصاویر و ارائه برنامه ها صحبت می کنیم (می توانید در مورد این فرآیندها به طور مفصل در مقالات اسناد مربوطه بخوانید: и )، سپس حالت صرفاً الگوی را تعیین می کند که با آن می توانید با تصویر کار کنید.
شیطان در جزئیات است
تفاوت و مشکل اصلی در هنگام اضافه کردن یک روش ذخیره سازی جدید در فرآیند تمیز کردن رجیستری است (برای ویژگی‌های پاکسازی که توسط werf پشتیبانی می‌شوند، مراجعه کنید ).
هنگام تمیز کردن، werf تصاویر استفاده شده در خوشه‌های Kubernetes و همچنین سیاست‌های پیکربندی شده توسط کاربر را در نظر می‌گیرد. سیاست ها بر اساس تقسیم برچسب ها به استراتژی ها است. استراتژی های پشتیبانی شده در حال حاضر:
- 3 استراتژی مرتبط با Git اولیه مانند برچسب، شاخه و commit.
- 1 استراتژی برای تگ های سفارشی دلخواه.
هنگام انتشار تصویر در برچسب های تصویر نهایی، اطلاعات مربوط به استراتژی برچسب را ذخیره می کنیم. معنی خود به اصطلاح است متا تگ - ملزم به اعمال برخی از سیاست ها. به عنوان مثال، هنگام حذف یک شاخه یا برچسب از یک مخزن Git، منطقی است که موارد مرتبط را حذف کنید. استفاده نشده تصاویر از رجیستری، که تحت پوشش بخشی از خط مشی های ما قرار دارد.
هنگامی که در یک مخزن ذخیره می شود (monorepo)، در تگ تصویر، علاوه بر متا تگ، نام تصویر را نیز می توان ذخیره کرد: PROJECT:frontend-META-TAG. برای جداسازی آنها جداکننده خاصی معرفی نکردیم، بلکه در هنگام انتشار به برچسب تصویر نهایی مقدار لازم را اضافه کردیم.
NB: اگر شما علاقه مند به مشاهده هر چیزی هستید که در کد منبع werf توضیح داده شده است، نقطه شروع می تواند باشد .
در این مقاله، ما به مشکلات و توجیه رویکرد خود توجه بیشتری نخواهیم کرد: در مورد استراتژی های برچسب گذاری، ذخیره داده ها در برچسب ها و فرآیند انتشار به طور کلی - همه اینها در گزارش اخیر دیمیتری استولیاروف به تفصیل شرح داده شده است:'.
به طور خلاصه
فقدان پشتیبانی از رجیستری های غیر تودرتو برای ما یا کاربران werf شناخته شده برای ما یک عامل مسدود کننده نبود - در نهایت، همیشه می توانید یک رجیستری تصویر جداگانه ایجاد کنید (یا به یک رجیستری Container مشروط در Google Cloud تغییر دهید) ... با این حال، حذف چنین محدودیتی منطقی به نظر می رسید تا ابزار برای جامعه گسترده تر DevOps راحت تر باشد. با اجرای آن، ما با مشکل اصلی در کار مجدد مکانیزم پاکسازی رجیستری کانتینر مواجه شدیم. اکنون که همه چیز آماده است، درک این موضوع خوب است که برای کسی آسان تر شده است و ما (به عنوان توسعه دهندگان اصلی پروژه) در پشتیبانی بیشتر از این ویژگی مشکل خاصی نخواهیم داشت.
با ما همراه باشید و به زودی در مورد سایر نوآوری ها به شما خواهیم گفت !
PS
در وبلاگ ما نیز بخوانید:
- «"؛
- «'.
منبع: www.habr.com