🥇 ورف کلیکٹر میں مواد پر مبنی ٹیگنگ: یہ کیوں اور کیسے کام کرتی ہے؟

werf ہماری اوپن سورس GitOps CLI یوٹیلیٹی ہے جو Kubernetes کو ایپلیکیشنز بنانے اور پہنچانے کے لیے ہے۔ میں ریلیز v1.1 امیج کلیکٹر میں ایک نئی خصوصیت متعارف کرائی گئی تھی: مواد کے ذریعے تصاویر کو ٹیگ کرنا یا مواد پر مبنی ٹیگنگ. اب تک، werf میں عام ٹیگنگ اسکیم میں ڈوکر امیجز کو گٹ ٹیگ، گٹ برانچ یا گٹ کمٹ کے ذریعے ٹیگ کرنا شامل تھا۔ لیکن ان تمام اسکیموں کے نقصانات ہیں جو نئی ٹیگنگ حکمت عملی سے مکمل طور پر حل ہو گئے ہیں۔ اس کے بارے میں تفصیلات اور یہ اتنا اچھا کیوں ہے کٹ کے نیچے ہے۔

ایک گٹ ریپوزٹری سے مائیکرو سروسز کا ایک سیٹ تیار کرنا

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

ایسے حالات ہوتے ہیں جب خدمات واقعی آزاد ہوتی ہیں اور کسی ایک درخواست سے وابستہ نہیں ہوتی ہیں۔ اس صورت میں، وہ الگ الگ پروجیکٹس میں واقع ہوں گے اور ان کی رہائی ہر پروجیکٹ میں الگ الگ CI/CD عمل کے ذریعے کی جائے گی۔

تاہم، حقیقت میں، ڈویلپرز اکثر ایک ہی ایپلیکیشن کو کئی مائیکرو سروسز میں تقسیم کرتے ہیں، لیکن ہر ایک کے لیے ایک الگ ذخیرہ اور پروجیکٹ بنانا... ایک واضح حد سے زیادہ حد ہے۔ یہ وہ صورت حال ہے جس پر مزید بات کی جائے گی: ایسی کئی مائیکرو سروسز ایک ہی پروجیکٹ کے ذخیرے میں واقع ہیں اور CI/CD میں ایک ہی عمل کے ذریعے ریلیز ہوتی ہیں۔

گٹ برانچ اور گٹ ٹیگ کے ذریعہ ٹیگنگ

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

جب ایک نیا گٹ ٹیگ بنایا جاتا ہے — مثال کے طور پر، جب ایک نیا ورژن جاری کیا جاتا ہے — ایک نیا ڈوکر ٹیگ ڈوکر رجسٹری میں تمام پروجیکٹ امیجز کے لیے بنایا جائے گا:

myregistry.org/myproject/frontend:v1.1.10
myregistry.org/myproject/myservice1:v1.1.10
myregistry.org/myproject/myservice2:v1.1.10
myregistry.org/myproject/myservice3:v1.1.10
myregistry.org/myproject/myservice4:v1.1.10
myregistry.org/myproject/myservice5:v1.1.10
myregistry.org/myproject/database:v1.1.10

یہ نئے تصویری نام ہیلم ٹیمپلیٹس کے ذریعے Kubernetes کنفیگریشن میں بھیجے گئے ہیں۔ کمانڈ کے ساتھ تعیناتی شروع کرتے وقت werf deploy فیلڈ کو اپ ڈیٹ کیا جا رہا ہے۔ image تبدیل شدہ تصویری نام کی وجہ سے Kubernetes ریسورس ظاہر کرتا ہے اور متعلقہ وسائل کو دوبارہ شروع کرتا ہے۔

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

نتیجے کے طور پر، موجودہ ٹیگنگ اسکیم کے ساتھ متعدد الگ الگ گٹ ریپوزٹریوں کو باڑنا ضروری ہے اور ان متعدد ذخیروں کے رول آؤٹ کو منظم کرنے میں مسئلہ پیدا ہوتا ہے۔ عام طور پر، اس طرح کی ایک سکیم زیادہ بوجھ اور پیچیدہ ہو جاتا ہے. یہ بہتر ہے کہ بہت ساری خدمات کو ایک ہی ذخیرہ میں جوڑ کر ڈوکر ٹیگز بنائیں تاکہ کوئی غیر ضروری دوبارہ شروع نہ ہو۔

گٹ کمٹ کے ذریعہ ٹیگ کرنا

werf کے پاس ٹیگنگ کی حکمت عملی بھی Git کمٹ کے ساتھ وابستہ ہے۔

Git-commit ایک Git repository کے مشمولات کا ایک شناخت کنندہ ہے اور Git repository میں فائلوں کی ترمیم کی تاریخ پر منحصر ہے، لہذا Docker رجسٹری میں تصاویر کو ٹیگ کرنے کے لیے اسے استعمال کرنا منطقی معلوم ہوتا ہے۔

تاہم، Git کمٹ کے ذریعے ٹیگ کرنے کے وہی نقصانات ہیں جو Git برانچز یا Git ٹیگز کے ذریعے ٹیگ کرنے کے ہیں۔

ایک خالی کمٹ بنایا جا سکتا ہے جو کسی فائل کو تبدیل نہیں کرتا ہے، لیکن تصویر کا ڈوکر ٹیگ تبدیل کر دیا جائے گا۔
ایک انضمام کمٹ بنایا جاسکتا ہے جو فائلوں کو تبدیل نہیں کرتا ہے، لیکن تصویر کا ڈوکر ٹیگ تبدیل کردیا جائے گا۔
ایک عہد کیا جا سکتا ہے جو Git میں ان فائلوں کو تبدیل کرے جو امیج میں امپورٹ نہیں کی گئی ہیں، اور امیج کا Docker ٹیگ دوبارہ تبدیل کر دیا جائے گا۔

Git برانچ کا نام ٹیگ کرنا تصویری ورژن کی عکاسی نہیں کرتا ہے۔

گٹ شاخوں کے لیے ٹیگنگ کی حکمت عملی سے وابستہ ایک اور مسئلہ ہے۔

برانچ کے نام سے ٹیگ کرنا اس وقت تک کام کرتا ہے جب تک کہ اس برانچ پر کمٹ کو ترتیب وار ترتیب سے جمع کیا جاتا ہے۔

اگر موجودہ اسکیم میں صارف کسی خاص برانچ سے وابستہ پرانے کمٹ کو دوبارہ بنانا شروع کرتا ہے، تو werf پرانے کمٹ کے لیے امیج کے نئے بنے ہوئے ورژن کے ساتھ متعلقہ Docker ٹیگ کا استعمال کرتے ہوئے تصویر کو دوبارہ لکھے گا۔ اب سے اس ٹیگ کا استعمال کرتے ہوئے پوڈز کو دوبارہ شروع کرنے پر تصویر کے مختلف ورژن کو کھینچنے کا خطرہ ہے، جس کے نتیجے میں ہماری ایپلیکیشن کا CI سسٹم سے رابطہ ختم ہو جائے گا اور غیر مطابقت پذیر ہو جائے گا۔

اس کے علاوہ، ان کے درمیان مختصر وقت کے ساتھ ایک برانچ میں لگاتار دھکیلنے کے ساتھ، پرانی کمٹ کو نئی سے بعد میں مرتب کیا جا سکتا ہے: تصویر کا پرانا ورژن گٹ برانچ ٹیگ کا استعمال کرتے ہوئے نئے کو اوور رائٹ کر دے گا۔ اس طرح کے مسائل کو CI/CD سسٹم کے ذریعے حل کیا جا سکتا ہے (مثال کے طور پر GitLab CI میں بعد کی پائپ لائن کمٹ کی ایک سیریز کے لیے شروع کی جاتی ہے)۔ تاہم، تمام سسٹمز اس کی حمایت نہیں کرتے ہیں اور اس طرح کے بنیادی مسئلے کو روکنے کے لیے زیادہ قابل اعتماد طریقہ ہونا چاہیے۔

مواد پر مبنی ٹیگنگ کیا ہے؟

تو، مواد پر مبنی ٹیگنگ کیا ہے - مواد کے لحاظ سے تصاویر کو ٹیگ کرنا۔

ڈوکر ٹیگز بنانے کے لیے، یہ گٹ پرائمیٹوز (گٹ برانچ، گٹ ٹیگ...) نہیں ہے جو استعمال کیے جاتے ہیں، بلکہ اس سے منسلک ایک چیکسم:

تصویر کے مواد. تصویری ID ٹیگ اس کے مواد کی عکاسی کرتا ہے۔ نیا ورژن بناتے وقت، یہ شناخت کنندہ تبدیل نہیں ہوگا اگر تصویر میں موجود فائلیں تبدیل نہیں ہوئی ہیں۔
گٹ میں اس تصویر کو بنانے کی تاریخ. مختلف Git برانچز سے وابستہ تصاویر اور werf کے ذریعے مختلف بلڈ ہسٹری میں مختلف ID ٹیگز ہوں گے۔

اس طرح کا شناخت کنندہ ٹیگ نام نہاد ہے۔ تصویر کے مرحلے کے دستخط.

ہر تصویر مراحل کے ایک سیٹ پر مشتمل ہے: from, before-install, git-archive, install, imports-after-install, before-setup، ... git-latest-patch وغیرہ ہر مرحلے میں ایک شناخت کنندہ ہوتا ہے جو اس کے مواد کی عکاسی کرتا ہے۔ مرحلے کے دستخط (اسٹیج دستخط).

ان مراحل پر مشتمل حتمی تصویر کو ان مراحل کے سیٹ کے نام نہاد دستخط کے ساتھ ٹیگ کیا گیا ہے۔ مراحل کے دستخط, - جو تصویر کے تمام مراحل کے لیے عام کر رہا ہے۔

ترتیب سے ہر تصویر کے لیے werf.yaml عام صورت میں، اس کے اپنے دستخط ہوں گے اور، اس کے مطابق، ایک ڈاکر ٹیگ۔

اسٹیج دستخط ان تمام مسائل کو حل کرتا ہے:

خالی گٹ کمٹ کے خلاف مزاحم۔
Git کے خلاف مزاحم ایسی فائلوں کو تبدیل کرتا ہے جو تصویر سے متعلق نہیں ہیں۔
برانچ کے پرانے گٹ کمٹ کے لیے تعمیرات کو دوبارہ شروع کرنے پر تصویر کے موجودہ ورژن کو اوور ہال کرنے کا مسئلہ پیدا نہیں ہوتا ہے۔

یہ اب تجویز کردہ ٹیگنگ حکمت عملی ہے اور تمام CI سسٹمز کے لیے werf میں ڈیفالٹ ہے۔

werf میں کیسے فعال اور استعمال کریں۔

کمانڈ کے پاس اب ایک متعلقہ آپشن ہے۔ werf publish: --tag-by-stages-signature=true|false

CI سسٹم میں، ٹیگنگ کی حکمت عملی کمانڈ کے ذریعہ بیان کی جاتی ہے۔ werf ci-env. پہلے، اس کے لیے پیرامیٹر کی وضاحت کی گئی تھی۔ werf ci-env --tagging-strategy=tag-or-branch. اب، اگر آپ وضاحت کریں werf ci-env --tagging-strategy=stages-signature یا اس اختیار کی وضاحت نہ کریں، werf پہلے سے طے شدہ طور پر ٹیگنگ کی حکمت عملی استعمال کرے گا۔ stages-signature. ٹیم werf ci-env کمانڈ کے لیے ضروری جھنڈے خود بخود ترتیب دے گا۔ werf build-and-publish (یا werf publish)، لہذا ان کمانڈز کے لیے کسی اضافی اختیارات کی وضاحت کرنے کی ضرورت نہیں ہے۔

مثال کے طور پر، کمانڈ:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

... درج ذیل تصاویر بنا سکتے ہیں:

registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

یہاں 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d تصویر کے مراحل کا ایک دستخط ہے۔ backendاور f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - تصویری مراحل کے دستخط frontend.

خصوصی افعال استعمال کرتے وقت werf_container_image и werf_container_env ہیلم ٹیمپلیٹس میں کسی بھی چیز کو تبدیل کرنے کی ضرورت نہیں ہے: یہ فنکشن خود بخود صحیح تصویر کے نام تیار کریں گے۔

سی آئی سسٹم میں ترتیب کی مثال:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

ترتیب کے بارے میں مزید معلومات دستاویزات میں دستیاب ہے:

مجموعی طور پر

نیا آپشن werf publish --tag-by-stages-signature=true|false.
نئی آپشن ویلیو werf ci-env --tagging-strategy=stages-signature|tag-or-branch (اگر متعین نہیں کیا گیا ہے تو، ڈیفالٹ ہو جائے گا stages-signature).
اگر آپ نے پہلے گٹ کمٹ کے لیے ٹیگنگ کے اختیارات استعمال کیے ہیں (WERF_TAG_GIT_COMMIT یا اختیار werf publish --tag-git-commit COMMIT)، پھر ٹیگنگ کی حکمت عملی پر سوئچ کرنا یقینی بنائیں مراحل - دستخط.
بہتر ہے کہ نئے پروجیکٹس کو فوری طور پر نئی ٹیگنگ اسکیم میں تبدیل کر دیا جائے۔
werf 1.1 میں منتقل کرتے وقت، پرانے پروجیکٹس کو نئی ٹیگنگ اسکیم میں تبدیل کرنے کا مشورہ دیا جاتا ہے، لیکن پرانے ٹیگ یا شاخ اب بھی حمایت کی جاتی ہے.

مواد پر مبنی ٹیگنگ مضمون میں شامل تمام مسائل کو حل کرتی ہے:

خالی گٹ کمٹ کے خلاف ڈاکر ٹیگ نام کی مزاحمت۔
گٹ میں ڈوکر ٹیگ کے نام کی لچک اس بات کا ارتکاب کرتی ہے کہ تصویر سے غیر متعلقہ فائلوں کو تبدیل کرتا ہے۔
گٹ شاخوں کے لیے پرانے گٹ کمٹ کے لیے تعمیرات کو دوبارہ شروع کرنے پر امیج کے موجودہ ورژن کی اوور ہالنگ کا مسئلہ پیدا نہیں ہوتا ہے۔

استعمال کرو! اور ہم سے ملاقات کرنا نہ بھولیں۔ GitHub کےکوئی مسئلہ پیدا کرنے یا موجودہ کو تلاش کرنے کے لیے، ایک پلس شامل کریں، ایک PR بنائیں یا صرف پروجیکٹ کی ترقی کو دیکھیں۔

PS

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

ماخذ: www.habr.com

ورف کلیکٹر میں مواد پر مبنی ٹیگنگ: یہ کیوں اور کیسے کام کرتی ہے؟