ڈیلیوری ٹولز کا ارتقاء، یا ڈوکر، ڈیب، جار اور مزید کے بارے میں خیالات

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

کوئی بھی پروڈکٹ، چاہے وہ کچھ بھی ہو، کسی نہ کسی طرح پروڈکٹ کے سرورز تک پہنچنا چاہیے، اسے کنفیگر اور لانچ کیا جانا چاہیے۔ اس مضمون کے بارے میں یہی ہوگا۔

میں ایک تاریخی تناظر میں سوچوں گا، "میں جو دیکھتا ہوں وہ وہی ہے جس کے بارے میں میں گاتا ہوں،" میں نے کیا دیکھا جب میں نے پہلی بار کوڈ لکھنا شروع کیا اور اب میں کیا دیکھتا ہوں، ہم خود اس وقت کیا استعمال کر رہے ہیں اور کیوں۔ مضمون میں مکمل مطالعہ کا بہانہ نہیں ہے، کچھ نکات چھوٹ گئے ہیں، یہ میرا ذاتی نظریہ ہے کہ کیا تھا اور اب کیا ہے۔

تو، اچھے پرانے دنوں میں... ڈیلیوری کا سب سے قدیم طریقہ جو مجھے ملا وہ ٹیپ ریکارڈرز سے کیسٹ ٹیپس تھا۔ میرے پاس کمپیوٹر BK-0010.01 تھا...

کیلکولیٹر کا دور

نہیں، اس سے بھی پہلے کا لمحہ تھا، ایک کیلکولیٹر بھی تھا۔ ایم کے 61 и ایم کے 52.

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

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

کیلکولیٹر میں سب سے بڑے پروگرام کا سائز 105 قدم تھا، اور MK-52 میں مستقل میموری کا سائز 512 قدم تھا۔

ویسے اگر ان کیلکولیٹروں کے شائقین ہیں جو اس مضمون کو پڑھ رہے ہیں تو مضمون لکھنے کے دوران مجھے اینڈرائیڈ کے لیے کیلکولیٹر ایمولیٹر اور اس کے لیے پروگرام دونوں ملے۔ ماضی کی طرف آگے!

• ایمولیٹر MK-61 برائے Android
• MK-61 کے لیے پروگرام کیٹلاگ

MK-52 کے بارے میں ایک مختصر بحث (وکی پیڈیا سے)

MK-52 نے Soyuz TM-7 خلائی جہاز پر خلا میں اڑان بھری۔ آن بورڈ کمپیوٹر کے ناکام ہونے کی صورت میں اسے لینڈنگ کی رفتار کا حساب لگانے کے لیے استعمال کیا جانا تھا۔

52 سے، Electronika-Astro میموری توسیعی یونٹ کے ساتھ MK-1988 نیوی کے جہازوں کو نیوی گیشنل کمپیوٹنگ کٹ کے حصے کے طور پر فراہم کیا جاتا رہا ہے۔

پہلا ذاتی کمپیوٹر

آئیے واپس زمانے کی طرف چلتے ہیں۔ BC-0010. یہ واضح ہے کہ وہاں زیادہ میموری تھی، اور کاغذ کے ٹکڑے سے کوڈ ٹائپ کرنا اب کوئی آپشن نہیں رہا تھا (حالانکہ پہلے میں نے ایسا ہی کیا تھا، کیونکہ اس کے علاوہ کوئی دوسرا ذریعہ نہیں تھا)۔ ٹیپ ریکارڈرز کے لیے آڈیو کیسٹس سافٹ ویئر کو ذخیرہ کرنے اور پہنچانے کا اہم ذریعہ بن رہے ہیں۔

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

قابل اعتماد اور بڑے اسٹوریج میڈیا کا ظہور

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

ڈیلیوری کی قسم بنیادی طور پر تبدیل ہو رہی ہے: انسٹالر پروگرام ظاہر ہوتے ہیں جو سسٹم کو ترتیب دینے کے ساتھ ساتھ ہٹانے کے بعد صفائی کے عمل کو منظم کرتے ہیں، کیونکہ پروگراموں کو صرف میموری میں نہیں پڑھا جاتا، بلکہ پہلے سے ہی مقامی اسٹوریج میں کاپی کیا جاتا ہے، جہاں سے آپ کو ضرورت ہوتی ہے۔ اگر ضروری ہو تو غیر ضروری چیزوں کو صاف کرنے کے قابل ہو.

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

اس وقت، لینکس کا وجود میرے لیے ابھی کھلا نہیں تھا؛ میں MS DOS اور، بعد میں، Windows کی دنیا میں رہتا تھا، اور Borland Pascal اور Delphi میں لکھا، کبھی کبھی C++ کی طرف دیکھتا تھا۔ بہت سے لوگوں نے اس وقت مصنوعات کی فراہمی کے لیے InstallShield کا استعمال کیا۔ ru.wikipedia.org/wiki/InstallShield، جس نے سافٹ ویئر کی تعیناتی اور ترتیب دینے کے تمام تفویض کردہ کاموں کو کامیابی سے حل کیا۔

انٹرنیٹ کا دور

آہستہ آہستہ، سافٹ ویئر سسٹمز کی پیچیدگی مزید پیچیدہ ہوتی جا رہی ہے؛ یک سنگی اور ڈیسک ٹاپ ایپلی کیشنز سے تقسیم شدہ نظاموں، پتلے کلائنٹس اور مائیکرو سروسز میں منتقلی ہوتی ہے۔ اب آپ کو صرف ایک پروگرام نہیں بلکہ ان کا ایک سیٹ ترتیب دینے کی ضرورت ہے، اور تاکہ وہ سب مل کر کام کریں۔

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

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

مجھے وہ اوقات یاد ہیں جب ہماری کمپنی میں جہاں میں نے اس وقت کام کیا تھا (میں اس کا نام نہیں بتاؤں گا)، چیونٹی کے ذریعے تعمیر کرنے کے بجائے (ماون ابھی تک مقبول نہیں تھا یا بالکل موجود نہیں تھا)، لوگوں نے آسانی سے IDE میں جار اکٹھے کیے اور اطمینان سے کام کیا۔ یہ SVN میں ہے۔ اس کے مطابق، تعیناتی میں فائل کو SVN سے بازیافت کرنا اور SSH کے ذریعے مطلوبہ مشین میں کاپی کرنا شامل تھا۔ یہ بہت سادہ اور اناڑی ہے۔

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

RPM اور DEB پیکجز

دوسری طرف، انٹرنیٹ کی ترقی کے ساتھ، UNIX جیسے نظاموں نے زیادہ سے زیادہ مقبولیت حاصل کرنا شروع کردی، خاص طور پر، یہ وہ وقت تھا جب میں نے RedHat Linux 6 کو تقریباً 2000 میں دریافت کیا۔ قدرتی طور پر، سافٹ ویئر کی فراہمی کے لیے کچھ ذرائع بھی موجود تھے؛ ویکیپیڈیا کے مطابق، RPM بطور مرکزی پیکیج مینیجر 1995 میں، RedHat Linux 2.0 کے ورژن میں پہلے ہی ظاہر ہو چکا تھا۔ اور تب سے لے کر آج تک یہ نظام RPM پیکجوں کی شکل میں پہنچایا گیا ہے اور کافی کامیابی سے موجود اور ترقی پذیر ہے۔

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

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

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

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

لہذا، کلاؤڈ ڈویلپرز کی یہ نئی نسل، جو نہ تو DEB اور نہ ہی RPM کو جانتی تھی، نے بھی آہستہ آہستہ ترقی کی، تجربہ حاصل کیا، مصنوعات زیادہ پیچیدہ ہو گئیں، اور FTP، bash اسکرپٹس اور اسی طرح کے طلباء کے دستکاریوں کے مقابلے میں کچھ زیادہ معقول ترسیل کے طریقوں کی ضرورت تھی۔
اور یہ وہ جگہ ہے جہاں ڈوکر تصویر میں آتا ہے، ورچوئلائزیشن، وسائل کی حد بندی اور ترسیل کے طریقہ کار کا ایک مرکب۔ یہ اب فیشن اور جوان ہے، لیکن کیا ہر چیز کے لیے اس کی ضرورت ہے؟ کیا یہ ایک علاج ہے؟

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

میں اپنے تجربے کو شیئر کرنے کی کوشش کروں گا کہ ہم نے ڈوکر کو کیسے نافذ کیا اور اس کے نتیجے میں کیا ہوا۔

خود لکھے ہوئے اسکرپٹ

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

لیکن اسکرپٹ کے کئی نقصانات ہیں:

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

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

یہ سب واضح طور پر اس تعیناتی کے طریقہ کار کے اطلاق کی حد کو صرف آسان ترین نظاموں تک محدود کرتا ہے۔ اس کو بدلنے کا وقت آگیا ہے۔

میں Docker

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

ہمیں کن تکلیفوں کا سامنا کرنا پڑا؟

• برج موڈ میں نیٹ ورک کے مسائل
• کنٹینر میں لاگز کو دیکھنا تکلیف دہ ہے (اگر وہ میزبان مشین کے فائل سسٹم میں الگ سے محفوظ نہیں ہیں)
• ElasticSearch کبھی کبھار کنٹینر کے اندر عجیب طور پر جم جاتی ہے، وجہ کا تعین نہیں ہوسکا، کنٹینر سرکاری ہے
• کنٹینر کے اندر شیل کا استعمال کرنا ضروری ہے - سب کچھ بہت کم ہے، کوئی واقف اوزار نہیں ہیں
• جمع کنٹینرز کا بڑا سائز - ذخیرہ کرنے کے لئے مہنگا
• کنٹینرز کے بڑے سائز کی وجہ سے، متعدد ورژن کو سپورٹ کرنا مشکل ہے۔
• دوسرے طریقوں (اسکرپٹس یا ڈیب پیکجز) کے برعکس طویل تعمیر کا وقت

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

جیسا کہ پریکٹس نے دکھایا ہے، حقیقت میں یہ ضروری نہیں ہے، ڈیب پیکیج 90٪ معاملات میں کافی ہے۔

اچھا پرانا ڈیب کب ناکام ہوتا ہے اور ہمیں واقعی کب ڈوکر کی ضرورت ہوتی ہے؟

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

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

اسنیپ پیکجز

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

نتیجے کے طور پر، ہم اب ڈیب پیکجز اور ڈوکر کنٹینرز دونوں کو ایک معقول امتزاج میں استعمال کرتے ہیں، جو شاید، بعض صورتوں میں ہم اسنیپ پیکجز سے بدل دیں گے۔

سروے میں صرف رجسٹرڈ صارفین ہی حصہ لے سکتے ہیں۔ سائن ان، برائے مہربانی.

آپ ترسیل کے لیے کیا استعمال کرتے ہیں؟

• خود لکھے ہوئے اسکرپٹ

• دستی طور پر FTP میں کاپی کریں۔

• deb پیکیجز

• آر پی ایم پیکجز

• سنیپ پیکجز

• ڈاکر کی تصاویر

• ورچوئل مشین کی تصاویر

• پورے HDD کو کلون کریں۔

• کٹھ پتلی

• جواب دہ

• دیگر

109 صارفین نے ووٹ دیا۔ 32 صارفین غیر حاضر رہے۔

ماخذ: www.habr.com