اب آپ باقاعدہ Dockerfile کا استعمال کرتے ہوئے werf میں Docker امیجز بنا سکتے ہیں۔

کبھی نہیں سے دیر بہتر. یا ہم نے ایپلی کیشن امیجز بنانے کے لیے باقاعدہ Dockerfiles کی حمایت نہ کر کے تقریباً ایک سنگین غلطی کی ہے۔

ہم بات کریں گے۔ werf - GitOps یوٹیلیٹی جو کسی بھی CI/CD سسٹم کے ساتھ ضم ہوتی ہے اور پورے ایپلیکیشن لائف سائیکل کا انتظام فراہم کرتی ہے، اجازت دیتا ہے:

• تصاویر جمع اور شائع کریں،
• Kubernetes میں ایپلی کیشنز تعینات کریں،
• خصوصی پالیسیوں کا استعمال کرتے ہوئے غیر استعمال شدہ تصاویر کو حذف کریں۔

پروجیکٹ کا فلسفہ کم سطح کے ٹولز کو ایک واحد متحد نظام میں جمع کرنا ہے جو DevOps انجینئرز کو ایپلی کیشنز پر کنٹرول فراہم کرتا ہے۔ اگر ممکن ہو تو، موجودہ یوٹیلیٹیز (جیسے ہیلم اور ڈوکر) کو استعمال کیا جانا چاہیے۔ اگر کسی مسئلے کا کوئی حل نہیں ہے، تو ہم اس کے لیے ضروری ہر چیز تخلیق اور مدد کر سکتے ہیں۔

پس منظر: آپ کا اپنا امیج کلیکٹر

werf میں تصویر جمع کرنے والے کے ساتھ ایسا ہی ہوا: معمول کے مطابق Dockerfile ہمارے لیے کافی نہیں تھی۔ اگر آپ پروجیکٹ کی تاریخ پر ایک سرسری نظر ڈالیں تو یہ مسئلہ پہلے ہی werf کے پہلے ورژن میں ظاہر ہوا تھا (پھر بھی ڈیپ کے طور پر جانا جاتا ہے).

ڈوکر امیجز میں ایپلی کیشنز بنانے کے لیے ایک ٹول بناتے ہوئے، ہم نے جلدی سے محسوس کیا کہ Dockerfile ہمارے لیے کچھ خاص کاموں کے لیے موزوں نہیں ہے:

1. درج ذیل معیاری اسکیم کے مطابق عام چھوٹی ویب ایپلیکیشنز بنانے کی ضرورت:
   • سسٹم وائڈ ایپلیکیشن انحصار انسٹال کریں،
   • ایپلیکیشن انحصاری لائبریریوں کا ایک بنڈل انسٹال کریں،
   • اثاثے جمع کرنا،
   • اور سب سے اہم بات، تصویر میں موجود کوڈ کو جلدی اور مؤثر طریقے سے اپ ڈیٹ کریں۔
2. جب پروجیکٹ فائلوں میں تبدیلیاں کی جاتی ہیں، بلڈر کو فوری طور پر تبدیل شدہ فائلوں پر پیچ لگا کر ایک نئی پرت بنانا ہوگی۔
3. اگر کچھ فائلیں بدل گئی ہیں، تو متعلقہ منحصر مرحلے کو دوبارہ بنانا ضروری ہے۔

آج ہمارے کلکٹر کے پاس اور بھی بہت سے امکانات ہیں، لیکن یہ ابتدائی خواہشات اور خواہشات تھیں۔

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

روبی میں ڈیپ کے لیے پرانی ترتیب

YAML پر werf کے لیے موجودہ تشکیل

وقت کے ساتھ ساتھ کلکٹر کا طریقہ کار بھی بدلتا رہا۔ سب سے پہلے، ہم نے اپنی ترتیب سے فلائی پر ایک عارضی ڈاکر فائل تیار کی، اور پھر ہم نے عارضی کنٹینرز اور کمٹ میں اسمبلی ہدایات کو چلانا شروع کیا۔

NB: اس وقت، ہمارا کلکٹر، جو اپنی تشکیل (YAML میں) کے ساتھ کام کرتا ہے اور اسے Stapel کلکٹر کہا جاتا ہے، پہلے ہی کافی طاقتور ٹول میں تیار ہو چکا ہے۔ اس کی تفصیلی تفصیل علیحدہ مضامین کی مستحق ہے، اور بنیادی تفصیلات اس میں مل سکتی ہیں۔ دستاویزات.

مسئلے سے آگاہی

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

اس سوال کا جواب دینے کے بجائے، ہم ایک حل پیش کرتے ہیں۔ کیا ہوگا اگر آپ کے پاس پہلے سے ہی Dockerfile (یا Dockerfiles کا ایک سیٹ) ہے اور آپ werf استعمال کرنا چاہتے ہیں؟

NB: ویسے، آپ werf کیوں استعمال کرنا چاہیں گے؟ اہم خصوصیات ذیل میں آتی ہیں:

• مکمل ایپلیکیشن مینجمنٹ سائیکل بشمول تصویر کی صفائی؛
• ایک ہی ترتیب سے ایک ساتھ کئی امیجز کی اسمبلی کا انتظام کرنے کی صلاحیت؛
• ہیلم سے مطابقت رکھنے والے چارٹس کے لیے بہتر تعیناتی کا عمل۔

ان کی مزید مکمل فہرست یہاں پر مل سکتی ہے۔ منصوبے کا صفحہ.

لہذا، اگر پہلے ہم اپنی ترتیب میں ڈاکر فائل کو دوبارہ لکھنے کی پیشکش کرتے، اب ہم خوشی سے کہیں گے: "Werf کو اپنی Dockerfiles بنانے دیں!"

استعمال کیسے کریں

اس خصوصیت کا مکمل نفاذ ریلیز میں ظاہر ہوا۔ werf v1.0.3-beta.1. عام اصول آسان ہے: صارف werf config میں موجودہ Dockerfile کا راستہ بتاتا ہے، اور پھر کمانڈ چلاتا ہے۔ werf build... اور یہ ہے - werf تصویر کو جمع کرے گا۔ آئیے ایک خلاصہ مثال دیکھیں۔

آئیے اگلے کا اعلان کرتے ہیں۔ Dockerfile منصوبے کی جڑ میں:

FROM ubuntu:18.04
RUN echo Building ...

اور ہم اعلان کریں گے۔ werf.yamlجو اس کو استعمال کرتا ہے۔ Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

سب! بائیں رن werf build:

اس کے علاوہ، آپ درج ذیل کا اعلان کر سکتے ہیں۔ werf.yaml ایک ساتھ مختلف ڈاکر فائلوں سے کئی تصاویر بنانے کے لیے:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

آخر میں، یہ اضافی تعمیراتی پیرامیٹرز کو پاس کرنے کی بھی حمایت کرتا ہے، جیسے --build-arg и --add-host - werf تشکیل کے ذریعے۔ ڈاکر فائل امیج کنفیگریشن کی مکمل تفصیل دستیاب ہے۔ دستاویزات کا صفحہ.

یہ کس طرح کام کرتا ہے؟

تعمیراتی عمل کے دوران، ڈوکر میں مقامی پرتوں کا معیاری کیش کام کرتا ہے۔ تاہم، اہم بات یہ ہے کہ werf بھی Dockerfile کنفیگریشن کو اس کے انفراسٹرکچر میں ضم کرتا ہے۔. اس کا کیا مطلب ہے؟

1. ڈاکر فائل سے بنی ہر تصویر ایک مرحلے پر مشتمل ہوتی ہے جسے کہا جاتا ہے۔ dockerfile (آپ اس بارے میں مزید پڑھ سکتے ہیں کہ werf میں کون سے مراحل ہیں۔ یہاں).
2. اسٹیج کے لیے dockerfile werf ایک دستخط کا حساب لگاتا ہے جو Dockerfile کنفیگریشن کے مندرجات پر منحصر ہوتا ہے۔ جب ڈاکر فائل کنفیگریشن بدل جاتی ہے تو اسٹیج کے دستخط بدل جاتے ہیں۔ dockerfile اور werf ایک نئے Dockerfile config کے ساتھ اس مرحلے کی دوبارہ تعمیر کا آغاز کرتا ہے۔ اگر دستخط تبدیل نہیں ہوتا ہے، تو werf تصویر کو کیشے سے لیتا ہے۔ (Werf میں دستخطوں کے استعمال کے بارے میں مزید تفصیلات میں بیان کیا گیا ہے۔ یہ رپورٹ).
3. اگلا، جمع کردہ تصاویر کو کمانڈ کے ساتھ شائع کیا جا سکتا ہے۔ werf publish (یا werf build-and-publish) اور اسے Kubernetes میں تعیناتی کے لیے استعمال کریں۔ ڈاکر رجسٹری میں شائع شدہ تصاویر کو معیاری ورف کلین اپ ٹولز کا استعمال کرتے ہوئے صاف کیا جائے گا، یعنی پرانی تصاویر (N دن سے زیادہ پرانی)، غیر موجود Git شاخوں سے وابستہ تصاویر، اور دیگر پالیسیاں خود بخود صاف ہو جائیں گی۔

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

• اشاعت کا عمل;
• Kubernetes کی تعیناتی کے عمل کے ساتھ انضمام;
• صفائی کا عمل.

نوٹس اور احتیاطی تدابیر

1. بیرونی URL ADD میں تعاون یافتہ نہیں ہے۔

فی الحال کسی ڈائریکٹیو میں بیرونی یو آر ایل استعمال کرنے کی سہولت نہیں ہے۔ ADD. جب مخصوص URL پر وسائل تبدیل ہوتے ہیں تو Werf دوبارہ تعمیر شروع نہیں کرے گا۔ ہم جلد ہی اس خصوصیت کو شامل کرنے کا ارادہ رکھتے ہیں۔

2. آپ تصویر میں .git شامل نہیں کر سکتے

عام طور پر، ایک ڈائریکٹری شامل کرنا .git تصویر میں - ایک شیطانی برا عمل اور اس کی وجہ یہ ہے:

1. اگر .git آخری تصویر میں رہتا ہے، یہ اصولوں کی خلاف ورزی کرتا ہے۔ 12 فیکٹر ایپ: چونکہ حتمی تصویر کو کسی ایک کمٹ سے منسلک کرنا ضروری ہے، اس لیے ایسا کرنا ممکن نہیں ہونا چاہیے۔ git checkout صوابدیدی عہد
2. .git تصویر کے سائز کو بڑھاتا ہے (ذخیرہ اس حقیقت کی وجہ سے بڑا ہوسکتا ہے کہ ایک بار اس میں بڑی فائلیں شامل کی گئیں اور پھر حذف کردی گئیں)۔ صرف ایک مخصوص عہد سے وابستہ ورک ٹری کا سائز گٹ میں آپریشنز کی تاریخ پر منحصر نہیں ہوگا۔ اس صورت میں، اضافہ اور بعد میں ہٹانا .git حتمی تصویر سے کام نہیں کرے گا: تصویر اب بھی ایک اضافی پرت حاصل کرے گی - اس طرح ڈوکر کام کرتا ہے۔
3. ڈوکر ایک غیر ضروری تعمیر نو کا آغاز کر سکتا ہے، یہاں تک کہ اگر ایک ہی عہد تعمیر کیا جا رہا ہو، لیکن مختلف کام کے درختوں سے۔ مثال کے طور پر، GitLab الگ الگ کلون ڈائریکٹریز بناتا ہے۔ /home/gitlab-runner/builds/HASH/[0-N]/yourproject جب متوازی اسمبلی کو فعال کیا جاتا ہے۔ اضافی reassembly حقیقت یہ ہے کہ ڈائریکٹری کی وجہ سے ہو جائے گا .git ایک ہی ذخیرہ کے مختلف کلون ورژن میں مختلف ہے، چاہے ایک ہی کمٹ بنایا گیا ہو۔

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

عام طور پر صرف کچھ ضروری فائلوں کو شامل کرنا ہدایات کے ذریعے ADD کسی بھی صورت میں تحریر کی کارکردگی اور وشوسنییتا کو بڑھاتا ہے۔ Dockerfile، اور اس کے لیے جمع کیش کے استحکام کو بھی بہتر بناتا ہے۔ Dockerfile، Git میں غیر متعلقہ تبدیلیوں کے لئے۔

کل

مخصوص ضروریات کے لیے اپنے بلڈر کو لکھنے کا ہمارا ابتدائی راستہ مشکل، دیانت دار اور سیدھا تھا: معیاری Dockerfile کے اوپر بیساکھی استعمال کرنے کے بجائے، ہم نے اپنا حل حسب ضرورت نحو کے ساتھ لکھا۔ اور اس کے فوائد تھے: اسٹیپل کلیکٹر اپنے کام کو بالکل ٹھیک کرتا ہے۔

تاہم، ہمارے اپنے بلڈر کو لکھنے کے عمل میں، ہم نے موجودہ Dockerfiles کے لیے سپورٹ کو کھو دیا۔ اس خامی کو اب دور کر دیا گیا ہے، اور مستقبل میں ہم اپنے کسٹم سٹیپل بلڈر کے ساتھ ڈوکر فائل سپورٹ کو ڈسٹری بیوٹڈ بلڈز اور Kubernetes استعمال کرتے ہوئے تعمیرات کے لیے تیار کرنے کا ارادہ رکھتے ہیں (یعنی Kubernetes کے اندر رنرز پر بناتا ہے، جیسا کہ kaniko میں کیا جاتا ہے)۔

لہذا، اگر آپ کے پاس اچانک کچھ ڈوکر فائلیں پڑی ہیں ... کوشش کریں werf!

PS موضوع پر دستاویزات کی فہرست

• فوری آغاز کے لیے رہنما;
• dockerfile بلڈر کنفیگریشنز;
• werf میں مرحلے کا آلہ;
• تصویر کی اشاعت کا عمل;
• Kubernetes کی تعیناتی کے عمل کے ساتھ انضمام;
• صفائی کا عمل;
• ڈاکر فائل کے متبادل کے طور پر سٹیپل بلڈر.

ہمارے بلاگ میں بھی پڑھیں: "werf - Kubernetes میں CI/CD کے لیے ہمارا ٹول (جائزہ اور ویڈیو رپورٹ)'.

ماخذ: www.habr.com