werf میں monorepo اور multirepo کے لیے سپورٹ اور ڈاکر رجسٹری کا اس سے کیا تعلق ہے

ایک مونو ریپوزٹری کے موضوع پر ایک سے زیادہ بار بات کی گئی ہے اور، ایک اصول کے طور پر، بہت فعال تنازعہ کا سبب بنتا ہے۔ بنا کر werf ایک اوپن سورس ٹول کے طور پر جسے Git سے Docker امیجز تک ایپلیکیشن کوڈ بنانے کے عمل کو بہتر بنانے کے لیے ڈیزائن کیا گیا ہے (اور پھر انہیں Kubernetes تک پہنچانا)، ہم اس بارے میں زیادہ نہیں سوچتے کہ کون سا انتخاب بہترین ہے۔ ہمارے لیے، مختلف آراء کے حامیوں کے لیے ضروری ہر چیز فراہم کرنا بنیادی بات ہے (اگر یہ عقل سے متصادم نہیں ہے، یقیناً)۔

werf کی حالیہ مونو ریپو سپورٹ اس کی ایک اچھی مثال ہے۔ لیکن پہلے، آئیے یہ معلوم کریں کہ اس سپورٹ کا عام طور پر werf استعمال کرنے سے کیا تعلق ہے اور Docker رجسٹری کا اس سے کیا تعلق ہے ...

مسائل

آئیے ایسی صورت حال کا تصور کریں۔ کمپنی کے پاس کئی ترقیاتی ٹیمیں ہیں جو آزاد منصوبوں پر کام کر رہی ہیں۔ زیادہ تر ایپلیکیشنز Kubernetes پر چلتی ہیں اور اس لیے کنٹینرائزڈ ہیں۔ کنٹینرز، تصاویر کو ذخیرہ کرنے کے لیے، آپ کو ایک رجسٹری (رجسٹری) کی ضرورت ہے۔ اس طرح کی رجسٹری کے طور پر، کمپنی ایک اکاؤنٹ کے ساتھ Docker Hub استعمال کرتی ہے۔ COMPANY. زیادہ تر سورس کوڈ اسٹوریج سسٹمز کی طرح، Docker Hub نیسٹڈ ریپوزٹری کے درجہ بندی کی اجازت نہیں دیتا ہے۔، جیسا کہ COMPANY/PROJECT/IMAGE. اس صورت میں… آپ ہر پروجیکٹ کے لیے علیحدہ اکاؤنٹ بنائے بغیر اس حد کے ساتھ رجسٹری میں غیر یک سنگی ایپلی کیشنز کو کیسے اسٹور کرسکتے ہیں؟

شاید، بیان کردہ صورتحال کسی کو خود ہی واقف ہے، لیکن آئیے عام طور پر ایپلی کیشن اسٹوریج کو منظم کرنے کے مسئلے پر غور کریں، یعنی مذکورہ بالا مثال اور ڈوکر حب کے حوالے کے بغیر۔

حل

اگر درخواست یک سنگی، ایک تصویر میں آتا ہے، پھر کوئی سوال نہیں ہوتا اور ہم صرف تصاویر کو پروجیکٹ کے کنٹینر رجسٹری میں محفوظ کرتے ہیں۔

جب ایک درخواست کو متعدد اجزاء کے طور پر پیش کیا جاتا ہے، مائیکرو سروسز، پھر ایک خاص نقطہ نظر کی ضرورت ہے۔ دو تصاویر پر مشتمل ایک عام ویب ایپلیکیشن کی مثال پر: frontend и backend - ممکنہ اختیارات ہیں:

1. الگ الگ نیسٹڈ ریپوزٹریز میں تصاویر اسٹور کریں:

   

2. ہر چیز کو ایک ذخیرہ میں ذخیرہ کریں، اور ٹیگ میں تصویر کے نام پر غور کریں، مثال کے طور پر، درج ذیل:

   

NB: درحقیقت، مختلف ذخیروں میں بچت کے ساتھ ایک اور آپشن ہے، PROJECT-frontend и PROJECT-backendلیکن ہم صارفین کے درمیان تعاون، تنظیم اور حقوق کی تقسیم کی پیچیدگی کی وجہ سے اس پر غور نہیں کریں گے۔

werf کی حمایت

ابتدائی طور پر، werf نے خود کو نیسٹڈ ریپوزٹریز تک محدود رکھا - خوش قسمتی سے، زیادہ تر رجسٹریاں اس خصوصیت کی حمایت کرتی ہیں۔ ورژن سے شروع ہو رہا ہے۔ v1.0.4-alpha.3، رجسٹریوں کے ساتھ کام شامل کیا جس میں گھونسلے کی حمایت نہیں کی جاتی ہے۔، اور Docker Hub ان میں سے ایک ہے۔ اس وقت سے، صارف کے پاس یہ انتخاب ہوتا ہے کہ ایپلی کیشن کی تصاویر کو کیسے اسٹور کیا جائے۔

آپشن کے تحت عمل درآمد دستیاب ہے۔ --images-repo-mode=multirepo|monorepo (پہلے سے طے شدہ multirepo، یعنی نیسٹڈ ریپوزٹریز میں اسٹوریج)۔ یہ ان نمونوں کی وضاحت کرتا ہے جن کے ذریعے تصاویر کو رجسٹری میں محفوظ کیا جاتا ہے۔ بنیادی حکموں کا استعمال کرتے وقت مطلوبہ موڈ کو منتخب کرنے کے لئے کافی ہے، اور باقی سب کچھ تبدیل نہیں ہوگا.

کیونکہ زیادہ تر ورف آپشنز سیٹ کیے جا سکتے ہیں۔ ماحولیاتی تغیراتCI/CD سسٹمز میں، اسٹوریج موڈ عام طور پر پورے پروجیکٹ کے لیے عالمی سطح پر سیٹ کرنا آسان ہوتا ہے۔ مثال کے طور پر، GitLab کے معاملے میں پروجیکٹ کی ترتیبات میں صرف ایک ماحولیاتی متغیر شامل کریں: ترتیبات -> CI / CD -> متغیرات: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

اگر ہم تصاویر شائع کرنے اور ایپلیکیشنز کو رول آؤٹ کرنے کے بارے میں بات کرتے ہیں (آپ متعلقہ دستاویزات کے مضامین میں ان عملوں کے بارے میں تفصیل سے پڑھ سکتے ہیں: اشاعت کا عمل и تعیناتی کا عمل)، پھر موڈ مکمل طور پر اس ٹیمپلیٹ کا تعین کرتا ہے جس کے ذریعے آپ تصویر کے ساتھ کام کر سکتے ہیں۔

شیطان تفصیلات میں ہے۔

ایک نیا اسٹوریج طریقہ شامل کرتے وقت فرق اور بنیادی مشکل رجسٹری کی صفائی کے عمل میں ہے۔ (Werf کے ذریعہ سپورٹ شدہ صاف کرنے کی خصوصیات کے لئے، دیکھیں صفائی کا عمل).

صفائی کرتے وقت، werf Kubernetes کلسٹرز میں استعمال ہونے والی تصاویر کے ساتھ ساتھ صارف کی طرف سے تشکیل کردہ پالیسیوں کو بھی مدنظر رکھتا ہے۔ پالیسیاں ٹیگز کی حکمت عملیوں کی تقسیم پر مبنی ہیں۔ فی الحال تعاون یافتہ حکمت عملی:

1. 3 حکمت عملی جو گٹ پرائمیٹوز سے منسلک ہیں جیسے ٹیگ، برانچ، اور کمٹ؛
2. صوابدیدی حسب ضرورت ٹیگز کے لیے 1 حکمت عملی۔

حتمی تصویر کے لیبل میں تصویر شائع کرتے وقت ہم ٹیگ کی حکمت عملی کے بارے میں معلومات محفوظ کرتے ہیں۔ معنی خود نام نہاد ہے۔ میٹا ٹیگ - کچھ پالیسیوں کو لاگو کرنے کی ضرورت ہے۔ مثال کے طور پر، جب گٹ ریپوزٹری سے برانچ یا ٹیگ کو حذف کرتے ہیں، تو متعلقہ کو حذف کرنا منطقی ہے غیر استعمال شدہ رجسٹری کی تصاویر، جو ہماری پالیسیوں کے حصے میں آتی ہیں۔

جب ایک ذخیرہ میں محفوظ کیا جاتا ہے (monorepo)، تصویر کے ٹیگ میں، میٹا ٹیگ کے علاوہ، تصویر کا نام بھی ذخیرہ کیا جا سکتا ہے: PROJECT:frontend-META-TAG. ان کو الگ کرنے کے لیے، ہم نے کوئی مخصوص الگ کرنے والا متعارف نہیں کرایا، لیکن شائع کرتے وقت حتمی تصویر کے لیبل میں صرف ضروری قدر شامل کی۔

NB: اگر آپ werf سورس کوڈ میں بیان کردہ ہر چیز کو دیکھنے میں دلچسپی رکھتے ہیں، تو نقطہ آغاز ہوسکتا ہے۔ PR 1684.

اس مضمون میں، ہم اپنے نقطہ نظر کے مسائل اور جواز پر زیادہ توجہ نہیں دیں گے: ٹیگنگ کی حکمت عملیوں، ڈیٹا کو لیبلز میں ذخیرہ کرنے اور مجموعی طور پر اشاعت کے عمل کے بارے میں - یہ سب کچھ دیمتری اسٹولیاروف کی ایک حالیہ رپورٹ میں تفصیل سے بیان کیا گیا ہے:werf Kubernetes میں CI/CD کے لیے ہمارا ٹول ہے۔'.

مختصر کرنے کے لئے

غیر اندراج شدہ رجسٹریوں کے لیے تعاون کا فقدان ہمارے لیے یا ہمارے جاننے والے صارفین کے لیے مسدود کرنے والا عنصر نہیں تھا - بہر حال، آپ ہمیشہ ایک علیحدہ تصویری رجسٹری اٹھا سکتے ہیں (یا گوگل کلاؤڈ میں مشروط کنٹینر رجسٹری پر سوئچ کر سکتے ہیں)... تاہم، اس طرح کی پابندی کو ہٹانا منطقی معلوم ہوتا ہے تاکہ ٹول کے وسیع تر DevOps کمیونٹی کے لیے زیادہ آسان ہو۔ اس پر عمل درآمد کرتے ہوئے، ہمیں کنٹینر رجسٹری کلین اپ میکانزم کو دوبارہ کام کرنے میں بنیادی دشواری کا سامنا کرنا پڑا۔ اب جب کہ سب کچھ تیار ہے، یہ جان کر خوشی ہوئی کہ یہ کسی کے لیے آسان ہو گیا ہے، اور ہمیں (پروجیکٹ کے اہم ڈویلپرز کے طور پر) اس خصوصیت کو مزید سپورٹ کرنے میں کوئی قابل توجہ مشکلات نہیں ہوں گی۔

ہمارے ساتھ رہیں اور بہت جلد ہم آپ کو دیگر اختراعات کے بارے میں بتائیں گے۔ werf!

PS

ہمارے بلاگ پر بھی پڑھیں:

• «اب آپ باقاعدہ Dockerfile کا استعمال کرتے ہوئے werf میں Docker امیجز بنا سکتے ہیں۔؛ "
• «werf - Kubernetes میں CI/CD کے لیے ہمارا ٹول (جائزہ اور ویڈیو رپورٹ)'.

ماخذ: www.habr.com