Docker-in-Docker ایک ورچوئلائزڈ ڈوکر ڈیمون ماحول ہے جو کنٹینر کی تصاویر بنانے کے لیے کنٹینر کے اندر ہی چلتا ہے۔ Docker-in-Docker بنانے کا بنیادی مقصد خود Docker کی ترقی میں مدد کرنا تھا۔ بہت سے لوگ اسے جینکنز سی آئی چلانے کے لیے استعمال کرتے ہیں۔ یہ پہلے تو عام معلوم ہوتا ہے، لیکن پھر مسائل پیدا ہوتے ہیں جن سے جینکنز سی آئی کنٹینر میں ڈوکر انسٹال کر کے بچا جا سکتا ہے۔ یہ مضمون آپ کو بتاتا ہے کہ یہ کیسے کریں۔ اگر آپ تفصیلات کے بغیر حتمی حل میں دلچسپی رکھتے ہیں، تو صرف مضمون کا آخری حصہ، "مسئلہ حل کرنا" پڑھیں۔
Docker-in-Docker: "اچھا"
دو سال سے زیادہ پہلے میں نے ڈوکر میں ڈال دیا تھا۔ - مراعات یافتہ اور لکھا . مقصد بنیادی ٹیم کو ڈوکر کو تیزی سے تیار کرنے میں مدد کرنا تھا۔ Docker-in-Docker سے پہلے، عام ترقی کا چکر اس طرح نظر آتا تھا:
- ہیکیٹی ہیک
- تعمیر
- چلتے ہوئے ڈوکر ڈیمون کو روکنا؛
- ایک نیا ڈوکر ڈیمون لانچ کرنا؛
- جانچ
- سائیکل کو دوبارہ کریں.
اگر آپ ایک خوبصورت، تولیدی اسمبلی بنانا چاہتے ہیں (یعنی کنٹینر میں)، تو یہ مزید پیچیدہ ہو گیا:
- ہیکیٹی ہیک
- یقینی بنائیں کہ ڈوکر کا ورکنگ ورژن چل رہا ہے۔
- پرانے ڈاکر کے ساتھ نیا ڈوکر بنائیں۔
- ڈوکر ڈیمون کو روکیں؛
- ایک نیا ڈوکر ڈیمون شروع کریں؛
- پرکھ؛
- نئے ڈوکر ڈیمون کو روکیں؛
- دہرائیں
Docker-in-Docker کی آمد کے ساتھ، یہ عمل آسان ہو گیا ہے:
- ہیکیٹی ہیک
- اسمبلی + ایک مرحلے میں لانچ؛
- سائیکل کو دوبارہ کریں.
کیا یہ اس طرح زیادہ بہتر نہیں ہے؟
Docker-in-Docker: "خراب"
تاہم، عام خیال کے برعکس، Docker-in-Docker 100% ستارے، ٹٹو اور ایک تنگاوالا نہیں ہے۔ میرا مطلب یہ ہے کہ بہت سارے مسائل ہیں جن سے ایک ڈویلپر کو آگاہ ہونے کی ضرورت ہے۔
ان میں سے ایک LSMs (Linux سیکیورٹی ماڈیولز) جیسے AppArmor اور SELinux سے متعلق ہے: کنٹینر چلاتے وقت، "اندرونی ڈاکر" ایسے سیکیورٹی پروفائلز کو لاگو کرنے کی کوشش کر سکتا ہے جو "بیرونی ڈاکر" کو متصادم یا الجھا دیں۔ - مراعات یافتہ پرچم کے اصل نفاذ کو ضم کرنے کی کوشش کرتے وقت یہ حل کرنا سب سے مشکل مسئلہ ہے۔ میری تبدیلیوں نے کام کیا اور تمام ٹیسٹ میری Debian مشین اور Ubuntu ٹیسٹ VMs پر گزریں گے، لیکن وہ مائیکل کروسبی کی مشین پر کریش ہو جائیں گے اور جل جائیں گے (اس کے پاس فیڈورا تھا جیسا کہ مجھے یاد ہے)۔ مجھے مسئلہ کی صحیح وجہ یاد نہیں ہے، لیکن یہ اس لیے ہوسکتا ہے کہ مائیک ایک عقلمند آدمی ہے جو SELINUX=enforce کے ساتھ کام کرتا ہے (میں نے AppArmor استعمال کیا تھا) اور میری تبدیلیوں نے SELinux پروفائلز کو خاطر میں نہیں لایا۔
Docker-in-Docker: "Evil"
دوسرا مسئلہ ڈوکر اسٹوریج ڈرائیوروں کا ہے۔ جب آپ Docker-in-Docker چلاتے ہیں، تو بیرونی Docker ایک باقاعدہ فائل سسٹم (EXT4، BTRFS، یا جو کچھ بھی آپ کے پاس ہے) کے اوپر چلتا ہے اور اندرونی Docker ایک کاپی آن رائٹ سسٹم (AUFS، BTRFS، Device Mapper) کے اوپر چلتا ہے۔ ، وغیرہ)، اس بات پر منحصر ہے کہ بیرونی ڈوکر کو استعمال کرنے کے لیے کنفیگر کیا گیا ہے)۔ اس سے بہت سے مجموعے بنتے ہیں جو کام نہیں کریں گے۔ مثال کے طور پر، آپ AUFS کو AUFS کے اوپر نہیں چلا سکیں گے۔
اگر آپ BTRFS کو BTRFS کے اوپر چلاتے ہیں، تو اسے پہلے کام کرنا چاہیے، لیکن ایک بار جب نیسٹڈ سب والیوم ہو جائیں تو پیرنٹ سب والیوم کو حذف کرنا ناکام ہو جائے گا۔ ڈیوائس میپر ماڈیول میں کوئی نام کی جگہ نہیں ہے، لہذا اگر ایک سے زیادہ ڈوکر مثالیں اسے ایک ہی مشین پر چلا رہے ہیں، تو وہ سب ایک دوسرے پر اور کنٹینر بیک اپ ڈیوائسز پر تصاویر کو دیکھ سکیں گے (اور اثر انداز) ہوں گے۔ یہ برا ہے.
ان میں سے بہت سے مسائل کو حل کرنے کے لیے حل موجود ہیں۔ مثال کے طور پر، اگر آپ اندرونی ڈوکر میں AUFS استعمال کرنا چاہتے ہیں، تو صرف /var/lib/docker فولڈر کو حجم میں تبدیل کریں اور آپ ٹھیک ہو جائیں گے۔ ڈوکر نے ڈیوائس میپر کے ٹارگٹ ناموں میں کچھ بنیادی نام کی جگہیں شامل کی ہیں تاکہ اگر ایک ہی مشین پر متعدد ڈاکر کالز چل رہی ہوں تو وہ ایک دوسرے پر قدم نہیں رکھیں گی۔
تاہم، اس طرح کا سیٹ اپ بالکل آسان نہیں ہے، جیسا کہ ان سے دیکھا جا سکتا ہے۔ GitHub پر ڈنڈ ریپوزٹری میں۔
Docker-in-Docker: یہ بدتر ہو جاتا ہے۔
تعمیر کیشے کے بارے میں کیا خیال ہے؟ یہ بھی کافی مشکل ہو سکتا ہے۔ لوگ اکثر مجھ سے پوچھتے ہیں کہ "اگر میں Docker-in-Docker چلا رہا ہوں، تو میں اپنے میزبان پر میزبانی کی گئی تصاویر کو اپنے اندرونی Docker میں واپس لانے کے بجائے کیسے استعمال کر سکتا ہوں"؟
کچھ کاروباری لوگوں نے /var/lib/docker کو میزبان سے Docker-in-Docker کنٹینر سے باندھنے کی کوشش کی ہے۔ بعض اوقات وہ ایک سے زیادہ کنٹینرز کے ساتھ /var/lib/docker کا اشتراک کرتے ہیں۔
کیا آپ اپنے ڈیٹا کو خراب کرنا چاہتے ہیں؟ کیونکہ یہ بالکل وہی ہے جو آپ کے ڈیٹا کو نقصان پہنچائے گا!
ڈوکر ڈیمون کو واضح طور پر /var/lib/docker تک خصوصی رسائی حاصل کرنے کے لیے ڈیزائن کیا گیا تھا۔ اس فولڈر میں موجود کسی بھی ڈوکر فائلوں کو کسی اور چیز کو "ٹچ، پوک، یا پروڈ" نہیں کرنا چاہیے۔
ایسا کیوں ہے؟ کیونکہ یہ ڈاٹ کلاؤڈ کو تیار کرتے وقت سیکھے گئے ایک مشکل ترین سبق کا نتیجہ ہے۔ ڈاٹ کلاؤڈ کنٹینر انجن ایک ساتھ /var/lib/dotcloud تک رسائی حاصل کرنے کے متعدد عملوں کے ذریعے چلتا ہے۔ چالاک چالیں جیسے کہ ایٹم فائل کی تبدیلی (جگہ جگہ ایڈیٹنگ کے بجائے)، ایڈوائزری اور لازمی تالے کے ساتھ پیپرنگ کوڈ، اور محفوظ سسٹمز جیسے SQLite اور BDB کے ساتھ دیگر تجربات ہمیشہ کام نہیں کرتے تھے۔ جب ہم اپنے کنٹینر انجن کو دوبارہ ڈیزائن کر رہے تھے، جو آخرکار ڈوکر بن گیا، ڈیزائن کے بڑے فیصلوں میں سے ایک یہ تھا کہ تمام کنٹینر آپریشنز کو ایک ہی ڈیمون کے تحت اکٹھا کیا جائے تاکہ تمام ہم آہنگی کی بکواس کو ختم کیا جا سکے۔
مجھے غلط مت سمجھو: کچھ اچھا، قابل اعتماد اور تیز بنانا مکمل طور پر ممکن ہے جس میں متعدد عمل اور جدید متوازی کنٹرول شامل ہو۔ لیکن ہمارے خیال میں ڈوکر کو واحد کھلاڑی کے طور پر استعمال کرتے ہوئے کوڈ لکھنا اور برقرار رکھنا آسان اور آسان ہے۔
اس کا مطلب ہے کہ اگر آپ /var/lib/docker ڈائرکٹری کو متعدد Docker مثالوں کے درمیان شیئر کرتے ہیں تو آپ کو پریشانی ہوگی۔ یقیناً، یہ کام کر سکتا ہے، خاص طور پر جانچ کے ابتدائی مراحل میں۔ "سنو، ماں، میں ایک ڈاکر کے طور پر اوبنٹو چلا سکتا ہوں!" لیکن کچھ زیادہ پیچیدہ کرنے کی کوشش کریں، جیسے کہ ایک ہی تصویر کو دو مختلف مثالوں سے کھینچنا، اور آپ کو دنیا جلتی ہوئی نظر آئے گی۔
اس کا مطلب یہ ہے کہ اگر آپ کا CI نظام تعمیرات اور دوبارہ تعمیر کرتا ہے، ہر بار جب آپ اپنے Docker-in-Docker کنٹینر کو دوبارہ شروع کرتے ہیں، تو آپ کو اس کے کیشے میں جوہری گرنے کا خطرہ ہوتا ہے۔ یہ بالکل ٹھنڈا نہیں ہے!
حل
آئیے ایک قدم پیچھے ہٹیں۔ کیا آپ کو واقعتا Docker-in-Docker کی ضرورت ہے یا کیا آپ صرف Docker کو چلانے اور اپنے CI سسٹم سے کنٹینرز اور امیجز بنانے اور چلانے کے قابل ہونا چاہتے ہیں جبکہ وہ CI سسٹم خود ایک کنٹینر میں ہے؟
میں شرط لگاتا ہوں کہ زیادہ تر لوگ مؤخر الذکر آپشن چاہتے ہیں، یعنی وہ چاہتے ہیں کہ جینکنز جیسا سی آئی سسٹم کنٹینرز چلانے کے قابل ہو۔ اور ایسا کرنے کا سب سے آسان طریقہ یہ ہے کہ اپنے CI کنٹینر میں صرف ایک Docker ساکٹ ڈالیں اور اسے -v پرچم کے ساتھ منسلک کریں۔
سیدھے الفاظ میں، جب آپ اپنا CI کنٹینر (Jenkins یا دیگر) چلاتے ہیں، Docker-in-Docker کے ساتھ کسی چیز کو ہیک کرنے کے بجائے، اسے لائن سے شروع کریں:
docker run -v /var/run/docker.sock:/var/run/docker.sock ...اس کنٹینر کو اب ڈوکر ساکٹ تک رسائی حاصل ہوگی اور اس وجہ سے وہ کنٹینرز چلا سکے گا۔ سوائے اس کے کہ "چائلڈ" کنٹینرز چلانے کے بجائے، یہ "سائبلنگ" کنٹینرز لانچ کرے گا۔
آفیشل ڈوکر امیج (جس میں ڈوکر بائنری ہے) کا استعمال کرتے ہوئے اسے آزمائیں:
docker run -v /var/run/docker.sock:/var/run/docker.sock
-ti dockerیہ Docker-in-Docker کی طرح لگتا ہے اور کام کرتا ہے، لیکن یہ Docker-in-Docker نہیں ہے: جب یہ کنٹینر اضافی کنٹینرز بنائے گا، تو وہ اعلیٰ سطح کے Docker میں بنائے جائیں گے۔ آپ نیسٹنگ کے ضمنی اثرات کا تجربہ نہیں کریں گے اور اسمبلی کیشے کو متعدد کالوں میں شیئر کیا جائے گا۔
نوٹ: اس مضمون کے پچھلے ورژن نے ڈوکر بائنری کو میزبان سے کنٹینر سے جوڑنے کا مشورہ دیا تھا۔ یہ اب ناقابل اعتبار ہو گیا ہے کیونکہ ڈوکر انجن اب جامد یا قریب جامد لائبریریوں کا احاطہ نہیں کرتا ہے۔
لہذا، اگر آپ جینکنز سی آئی سے ڈوکر استعمال کرنا چاہتے ہیں، تو آپ کے پاس 2 اختیارات ہیں:
بنیادی تصویری پیکیجنگ سسٹم کا استعمال کرتے ہوئے Docker CLI انسٹال کرنا (یعنی اگر آپ کی تصویر Debian پر مبنی ہے تو .deb پیکیجز استعمال کریں)، Docker API کا استعمال کرتے ہوئے۔
کچھ اشتہارات 🙂
ہمارے ساتھ رہنے کے لیے آپ کا شکریہ۔ کیا آپ کو ہمارے مضامین پسند ہیں؟ مزید دلچسپ مواد دیکھنا چاہتے ہیں؟ آرڈر دے کر یا دوستوں کو مشورہ دے کر ہمارا ساتھ دیں، , انٹری لیول سرورز کا ایک انوکھا اینالاگ، جو ہم نے آپ کے لیے ایجاد کیا تھا: (RAID1 اور RAID10 کے ساتھ دستیاب، 24 کور تک اور 40GB DDR4 تک)۔
ایمسٹرڈیم میں Equinix Tier IV ڈیٹا سینٹر میں Dell R730xd 2 گنا سستا؟ صرف یہاں نیدرلینڈ میں! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 سے! کے بارے میں پڑھا
ماخذ: www.habr.com