Docker یا Podman: رفتار قریب، اختیار کا ڈھانچا مختلف

Linux پر Docker اور Podman کی اومیو یونیورسٹی کی ۲۰۲۰ کی پیمائش میں سی پی یو پر Podman کی برتری معمولی تھی اور براہ راست نظام تقریباً ۱۰ فیصد آگے تھا؛ میموری کی منتقلی کے چار میں سے تین تجربوں میں Podman معمولی آگے رہا؛ ڈسک کے درج شدہ نتائج میزبان کے مقابلے میں Docker کے لیے ۰٫۰۹ اور ۰٫۶۲ فیصد، اور Podman کے لیے ۰٫۰۳ اور ۰٫۵۵ فیصد کم تھے۔ یہ ایک Linux مشین پر منتخب پروگراموں کے نتائج ہیں، ہر ایپلی کیشن یا سرور کی رفتار کا عمومی فیصلہ نہیں۔

انتخاب میں زیادہ اہم سوال یہ ہے کہ کنٹینرز کس صارف کے اختیار سے چلیں گے اور دوسرے ٹولز ان تک کیسے پہنچیں گے۔ Podman کی سرکاری وضاحت کے مطابق مقامی استعمال کے لیے مستقل مرکزی ڈیمَن ضروری نہیں اور کنٹینر غیر مراعات یافتہ صارف چلا سکتا ہے۔ Docker کی روٹ لیس ہدایت ڈیمَن اور کنٹینرز دونوں کو غیر مراعات یافتہ صارف کے تحت چلانے کا طریقہ بتاتی ہے۔ اس لیے روٹ لیس ضرورت خود بخود ایک ہی ٹول کا فیصلہ نہیں کرتی؛ ڈیمَن کا ڈھانچا اور موجودہ ٹولز کی مطابقت بھی دیکھنی ہوگی۔

سی پی یو، میموری اور ڈسک کی پیمائش کیا بتاتی ہے؟

سی پی یو کے تجربے میں حسابی کام مکمل ہونے کا وقت ناپا گیا تھا۔ اس میں معمولی برتری سے ویب درخواستوں کا وقت، ڈیٹابیس کی کارکردگی یا کنٹینر شروع ہونے کی رفتار اخذ نہیں کی جا سکتی۔ میموری کے تجربے نے ڈیٹا منتقل کرنے کی رفتار ناپی تھی، زیر استعمال ریم کی مقدار نہیں۔ لہٰذا Podman کی اس پیمائش میں برتری کو یہ دعویٰ بنانا درست نہیں کہ وہ ہر چلتی ہوئی ایپلی کیشن میں کم میموری لیتا ہے۔

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

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

ڈیمَن سے اختیار کا فرق کیسے پیدا ہوتا ہے؟

Docker Engine کی سرکاری ساخت میں کمانڈ لائن کلائنٹ ایک طویل عرصے تک چلنے والے ڈیمَن سے رابطہ کرتا ہے؛ وہی تصاویر، کنٹینرز، نیٹ ورک اور والیوم کا انتظام کرتا ہے۔ اس سے خودکار ٹولز کو ایک واضح رابطہ ملتا ہے، مگر یہ بھی طے کرنا پڑتا ہے کہ اس رابطے تک کس عمل کی رسائی ہوگی۔ محض کنٹینر کے اندر عام صارف مقرر کر دینے سے ڈیمَن کے اختیار کی سطح نہیں بدلتی۔

Podman میں براہ راست مقامی کمانڈ کے لیے ایسی مستقل مرکزی خدمت درکار نہیں۔ غیر مراعات یافتہ صارف کے تحت چلنے والا کنٹینر اسی صارف کی اجازتوں کے دائرے میں رہتا ہے، اس لیے مشترک Linux مشین پر الگ صارفین کے کام الگ رکھنے کی صورت میں یہ ڈھانچا موزوں ہو سکتا ہے۔ یہاں فائدہ انتظامی اختیار کی حد میں ہے؛ ڈیمَن نہ ہونے سے کسی خاص ایپلی کیشن کی رفتار بڑھنے کا نتیجہ نہیں نکلتا۔

Docker کا روٹ لیس طریقہ بھی اختیار محدود کرتا ہے، لیکن اس میں صارف کے تحت چلنے والا ڈیمَن برقرار رہتا ہے۔ اس کے لیے میزبان پر صارف کی شناخت کی نقشہ بندی اور متعلقہ سہولتوں کی ترتیب درکار ہوتی ہے۔ یوں اصل تقابل «روٹ لیس بمقابلہ مراعات یافتہ» نہیں، بلکہ روٹ لیس استعمال کے دو مختلف انتظامی راستوں کا ہے: ایک میں مقامی کمانڈ براہ راست کام کرتی ہے، دوسرے میں کلائنٹ صارف کے ڈیمَن سے بات کرتا ہے۔

مشابہ کمانڈز کے باوجود مطابقت کہاں رک سکتی ہے؟

Podman کی کمانڈ لائن Docker استعمال کرنے والے کو مانوس لگتی ہے اور دونوں معیاری کنٹینر تصاویر کے ساتھ کام کرتے ہیں۔ تصویر کا دونوں میں چل جانا، البتہ، پورے ترقیاتی عمل کی مطابقت ثابت نہیں کرتا۔ اگر تعمیر یا جانچ کا ٹول Docker کے رابطے، اس کے ساکٹ، نیٹ ورک کی کسی مخصوص ترتیب یا کمانڈ کے خاص جواب پر منحصر ہے، تو صرف کمانڈ کا نام بدلنا کافی نہیں ہوگا۔

Podman کی رابطہ خدمت کی دستاویز Docker سے مطابقت رکھنے والی پروگرامنگ تہہ اور ضرورت پر ساکٹ کے ذریعے فعال ہونے والی خدمت بیان کرتی ہے۔ یہ بعض موجودہ ٹولز کو جوڑنے کا راستہ دیتی ہے، مگر ہر رابطے کی مکمل مطابقت کی ضمانت نہیں۔ اس ساکٹ تک رسائی رکھنے والا عمل متعلقہ صارف کے اختیار سے Podman کے کام انجام دے سکتا ہے، اس لیے رابطہ کھولنے کے بعد اس کی اجازتیں بھی انتظامی فیصلے کا حصہ بنتی ہیں۔

مقامی ترقی، سی آئی اور پیداوار میں کون سا انتخاب موزوں ہے؟

مقامی Linux ترقی میں Podman اچھا انتخاب ہو سکتا ہے جب ہر ڈویلپر اپنے صارف کے تحت کنٹینرز چلانا چاہتا ہو اور منصوبے کے معاون ٹولز Docker کے مخصوص رابطے پر منحصر نہ ہوں۔ اس صورت میں مستقل مرکزی ڈیمَن کے بغیر روزمرہ کام ممکن ہے۔ اگر موجودہ ترقیاتی ماحول Docker کے ٹولز کے ساتھ پہلے ہی ہموار ہے تو معمولی شائع شدہ رفتار فرق منتقلی کی مضبوط وجہ نہیں بنتا؛ Docker کا روٹ لیس طریقہ اسی ماحول میں اختیار محدود کرنے کا متبادل ہے۔

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

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

یہ بھی پڑھیں: