Docker-in-Docker هڪ مجازي ڊاکر ڊيمن ماحول آهي جيڪو ڪنٽينر جي اندر اندر هلندو آهي ڪنٽينر تصويرون ٺاهڻ لاءِ. Docker-in-Docker ٺاهڻ جو بنيادي مقصد ڊڪر کي ترقي ڪرڻ ۾ مدد ڏيڻ هو. ڪيترائي ماڻهو ان کي استعمال ڪن ٿا جينڪنز سي آءِ کي هلائڻ لاءِ. اهو پهريون ڀيرو عام لڳي ٿو، پر پوءِ مسئلا پيدا ٿين ٿا جيڪي ڊاڪر کي جينڪنز سي آءِ ڪنٽينر ۾ انسٽال ڪرڻ کان بچي سگهن ٿا. هي آرٽيڪل توهان کي ٻڌائي ٿو ته اهو ڪيئن ڪجي. جيڪڏهن توهان تفصيل جي بغير حتمي حل ۾ دلچسپي رکو ٿا، صرف آرٽيڪل جو آخري حصو پڙهو، "مسئلو حل ڪرڻ."
Docker-in-Docker: "سٺو"
ٻه سال اڳ کان وڌيڪ مون ڊاکر ۾ وجهي ڇڏيو - امتياز ۽ لکيو . مقصد هو بنيادي ٽيم جي مدد ڪرڻ لاءِ ڊاڪر تيزيءَ سان. Docker-in-Docker کان اڳ، عام ترقي چڪر هن طرح نظر آيو:
- hackity hack;
- تعمير
- ڊوڙندڙ ڊڪر ڊيمن کي روڪڻ؛
- هڪ نئون ڊاکر ڊيمون لانچ ڪرڻ؛
- جاچ؛
- چڪر کي ورجايو.
جيڪڏهن توهان چاهيو ٿا ته هڪ خوبصورت، ٻيهر پيدا ٿيندڙ اسيمبلي (يعني هڪ ڪنٽينر ۾)، پوء اهو وڌيڪ پيچيده ٿي ويو:
- hackity hack;
- پڪ ڪريو ته ڊڪر جو ڪم ڪندڙ ورزن هلي رهيو آهي؛
- پراڻي Docker سان نئون Docker ٺاهيو؛
- ڊاڪر ڊيمن کي روڪيو؛
- هڪ نئون Docker daemon شروع؛
- ٽيسٽ؛
- نئين ڊاڪر ڊيمن کي روڪيو؛
- ورجائي.
Docker-in-Docker جي اچڻ سان، عمل آسان ٿي چڪو آهي:
- hackity hack;
- اسيمبلي + هڪ اسٽيج ۾ لانچ؛
- چڪر کي ورجايو.
ڇا اهو طريقو گهڻو بهتر ناهي؟
Docker-in-Docker: "خراب"
بهرحال، مشهور اعتقاد جي برعڪس، Docker-in-Docker 100٪ تارن، پوني ۽ يوني ڪورن نه آهي. منهنجو مطلب اهو آهي ته اهڙا ڪيترائي مسئلا آهن جيڪي هڪ ڊولپر کان آگاهي ٿيڻ گهرجن.
انهن مان هڪ جو خدشو آهي LSMs (لينڪس سيڪيورٽي ماڊلز) جهڙوڪ AppArmor ۽ SELinux: جڏهن هڪ ڪنٽينر هلائي رهيو آهي، "اندروني ڊڪر" شايد سيڪيورٽي پروفائلز کي لاڳو ڪرڻ جي ڪوشش ڪري سگهي ٿو جيڪي تڪرار يا "خارجي ڊاکر" کي پريشان ڪندا. اهو حل ڪرڻ لاء سڀ کان وڌيڪ ڏکيو مسئلو آهي جڏهن - امتيازي پرچم جي اصل عمل درآمد کي ضم ڪرڻ جي ڪوشش ڪئي وئي آهي. منهنجون تبديليون ڪم ڪيون ۽ سڀئي ٽيسٽون منهنجي ڊيبين مشين ۽ Ubuntu ٽيسٽ VMs تي گذري وينديون، پر اهي مائيڪل ڪراسبي جي مشين تي حادثا ۽ سڙي ويندا (هن وٽ فيڊورا هو جيئن مون کي ياد آهي). مون کي مسئلي جو صحيح سبب ياد ناهي، پر اهو ٿي سگهي ٿو ڇاڪاڻ ته مائڪ هڪ عقلمند ماڻهو آهي جيڪو ڪم ڪري ٿو SELINUX=enforce (مون AppArmor استعمال ڪيو) ۽ منهنجي تبديلين SELinux پروفائلز کي حساب ۾ نه ورتو.
Docker-in-Docker: "برائي"
ٻيو مسئلو Docker اسٽوريج ڊرائيورن سان آهي. جڏهن توهان Docker-in-Docker هلائيندا آهيو، خارجي Docker هڪ باقاعده فائل سسٽم جي مٿي تي هلندو آهي (EXT4، BTRFS، يا جيڪو توهان وٽ آهي) ۽ اندروني ڊڪر هڪ ڪاپي-آن-لائيٽ سسٽم جي مٿان هلندو آهي (AUFS، BTRFS، ڊوائيس ميپر. ، وغيره). هي ڪيترائي مجموعا ٺاهي ٿو جيڪي ڪم نه ڪندا. مثال طور، توهان AUFS کي AUFS جي چوٽي تي هلائڻ جي قابل نه هوندا.
جيڪڏهن توهان BTRFS کي BTRFS جي چوٽي تي هلائيندا آهيو، اهو پهريون ڀيرو ڪم ڪرڻ گهرجي، پر هڪ ڀيرو اتي موجود ذيلي حجم موجود آهن، والدين جي ذيلي حجم کي حذف ڪرڻ ناڪام ٿيندو. ڊيوائس ميپر ماڊل وٽ ڪا به نالي جي جاءِ نه آهي، تنهن ڪري جيڪڏهن ڪيترائي ڊڪر مثال ان کي هڪ ئي مشين تي هلائي رهيا آهن، اهي سڀئي تصويرون ڏسڻ جي قابل هوندا (۽ اثر انداز) هڪ ٻئي تي ۽ ڪنٽينر بيڪ اپ ڊوائيسز تي. هي خراب آهي.
انهن مان ڪيترن ئي مسئلن کي حل ڪرڻ لاء حل آهن. مثال طور، جيڪڏھن توھان AUFS استعمال ڪرڻ چاھيو ٿا اندروني Docker ۾، صرف ڦيرايو /var/lib/docker فولڊر کي حجم ۾ ۽ توھان ٺيڪ ٿي ويندؤ. Docker شامل ڪيو آھي ڪجھ بنيادي نالن جي جڳھن کي ڊيوائس ميپر جي ٽارگيٽ نالن ۾، انهي ڪري ته جيڪڏھن گھڻا ڊاڪر ڪالون ھڪڙي مشين تي ھلنديون آھن، اھي ھڪ ٻئي تي قدم نه ڪندا.
بهرحال، اهڙي سيٽ اپ بلڪل سادو ناهي، جيئن انهن مان ڏسي سگهجي ٿو GitHub تي ڊينڊ مخزن ۾.
Docker-in-Docker: اهو خراب ٿي ويندو آهي
تعميراتي ڪيش بابت ڇا؟ اهو پڻ ڪافي ڏکيو ٿي سگهي ٿو. ماڻهو اڪثر مون کان پڇندا آهن ”جيڪڏهن مان ڊاڪر-ان-ڊڪر هلائي رهيو آهيان ، آئون پنهنجي ميزبان تي ميزباني ڪيل تصويرون ڪيئن استعمال ڪري سگهان ٿو بجاءِ هر شي کي منهنجي اندروني ڊاکر ۾ واپس آڻڻ جي“؟
ڪجهه ڪاروباري ماڻهن کي پابند ڪرڻ جي ڪوشش ڪئي آهي /var/lib/docker ميزبان کان هڪ Docker-in-Docker ڪنٽينر تائين. ڪڏهن ڪڏهن اهي حصيداري ڪندا آهن /var/lib/docker ڪيترن ئي ڪنٽينرز سان.
ڇا توھان پنھنجي ڊيٽا کي خراب ڪرڻ چاھيو ٿا؟ ڇو ته اهو ئي آهي جيڪو توهان جي ڊيٽا کي نقصان پهچائيندو!
ڊاکر ڊيمن کي واضح طور تي /var/lib/docker تائين خاص رسائي حاصل ڪرڻ لاءِ ٺهيل هئي. هن فولڊر ۾ موجود ڪنهن به ڊاڪر فائلن کي ٻيو ڪجهه به نه ”ٽچ، پڪو، يا پروڊ“ ڪرڻ گهرجي.
ائين ڇو آهي؟ ڇاڪاڻ ته اهو نتيجو آهي هڪ سخت ترين سبق جو سکيو ويو جڏهن dotCloud کي ترقي ڪندي. ڊاٽ ڪلائوڊ ڪنٽينر انجڻ هليو ويو ڪيترن ئي عملن تائين رسائي حاصل ڪرڻ سان گڏ /var/lib/dotcloud. چالاڪ چالون جيئن ته ايٽمي فائل مٽائڻ (ان جي جاءِ تي ايڊيٽنگ جي بدران)، پيپرنگ ڪوڊ سان مشوري ۽ لازمي لاڪ، ۽ ٻيا تجربا محفوظ سسٽم سان گڏ جيئن ته SQLite ۽ BDB هميشه ڪم نه ڪندا هئا. جڏهن اسان پنهنجي ڪنٽينر انجڻ کي ٻيهر ڊزائين ڪري رهيا هئاسين، جيڪو آخرڪار ڊاڪر بڻجي ويو، هڪ وڏي ڊيزائن جي فيصلن مان هڪ هو سڀني ڪنٽينر آپريشن کي هڪ واحد ڊيمن جي تحت گڏ ڪرڻ لاءِ سڀني ڪنٽينر جي بيڪار کي ختم ڪرڻ لاءِ.
مون کي غلط نه سمجھو: اهو مڪمل طور تي ممڪن آهي ته ڪجهه سٺو، قابل اعتماد ۽ تيز ٺاهيو جنهن ۾ ڪيترائي عمل ۽ جديد متوازي ڪنٽرول شامل آهن. پر اسان سمجهون ٿا ته اهو آسان ۽ آسان آهي ڪوڊ لکڻ ۽ برقرار رکڻ لاءِ Docker استعمال ڪندي واحد پليئر.
ان جو مطلب اهو آهي ته جيڪڏهن توهان حصيداري ڪريو ٿا /var/lib/docker ڊاريڪٽري ڪيترن ئي Docker مثالن جي وچ ۾، توهان کي مسئلا هوندا. يقينا، اهو ڪم ڪري سگهي ٿو، خاص طور تي جاچ جي شروعاتي مرحلن ۾. ”ٻڌو، ما، مان اوبنٽو کي ڊاکر طور هلائي سگهان ٿو! پر ڪوشش ڪريو ڪجھ وڌيڪ پيچيده، جھڙوڪ ساڳي تصوير کي ٻن مختلف مثالن مان ڪڍڻ، ۽ توھان ڏسندؤ ته دنيا جلندي.
ان جو مطلب اهو آهي ته جيڪڏهن توهان جو CI سسٽم ٺاهي ٿو ۽ ٻيهر تعمير ڪري ٿو، هر وقت توهان پنهنجي Docker-in-Docker ڪنٽينر کي ٻيهر شروع ڪريو ٿا، توهان کي خطرو آهي ته هڪ نيوڪ ان جي ڪيش ۾ ڇڏڻ. اهو سڀ ڪجهه ٿڌو ناهي!
مسئلا حل ڪرڻ
اچو ته هڪ قدم پوئتي هلون. ڇا توهان کي واقعي Docker-in-Docker جي ضرورت آهي يا ڇا توهان صرف Docker کي هلائڻ ۽ توهان جي CI سسٽم مان ڪنٽينر ۽ تصويرون ٺاهڻ ۽ هلائڻ جي قابل ٿيڻ چاهيو ٿا جڏهن ته اهو سي آءِ سسٽم پاڻ هڪ ڪنٽينر ۾ آهي؟
مان شرط ٿو ڏيان ته گھڻا ماڻھو پوئين آپشن چاھين ٿا، مطلب ته اھي چاھين ٿا سي آءِ سسٽم جھڙوڪ جينڪنز ڪنٽينر ھلائي سگھن. ۽ اهو ڪرڻ جو آسان طريقو اهو آهي ته توهان جي CI ڪنٽينر ۾ هڪ ڊاکر ساکٽ داخل ڪريو ۽ ان کي -v پرچم سان ڳنڍيو.
سادي لفظ ۾، جڏهن توهان پنهنجو CI ڪنٽينر (جينڪنز يا ٻيو) هلائيندا آهيو، ڊاڪر-ان-ڊڪر سان گڏ ڪجهه هيڪ ڪرڻ بدران، ان کي لائن سان شروع ڪريو:
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 نه آهي: جڏهن هي ڪنٽينر اضافي ڪنٽينر ٺاهي ٿو، اهي مٿين سطح جي ڊڪر ۾ ٺاهيا ويندا. توهان nesting جي ضمني اثرات جو تجربو نه ڪندا ۽ اسيمبلي ڪيش ڪيترن ئي ڪالن ۾ حصيداري ڪئي ويندي.
نوٽ: هن آرٽيڪل جي پوئين نسخن کي ڊاکر بائنري کي ميزبان کان ڪنٽينر سان ڳنڍڻ جي صلاح ڏني وئي. اهو هاڻي ناقابل اعتبار ٿي چڪو آهي جيئن ڊڪر انجڻ هاڻي جامد يا ويجھي جامد لائبريرين کي ڍڪي نه ٿو.
تنهن ڪري، جيڪڏهن توهان استعمال ڪرڻ چاهيو ٿا Docker کان Jenkins CI، توهان وٽ آهن 2 آپشن:
ڊاڪر CLI کي انسٽال ڪرڻ بنيادي تصويري پيڪنگنگ سسٽم استعمال ڪندي (يعني جيڪڏهن توهان جي تصوير ڊيبين تي ٻڌل آهي، استعمال ڪريو .deb پيڪيجز)، Docker API استعمال ڪندي.
ڪجھ اشتهار 🙂
اسان سان گڏ رهڻ لاء توهان جي مهرباني. ڇا توهان اسان جا مضمون پسند ڪندا آهيو؟ وڌيڪ دلچسپ مواد ڏسڻ چاهيو ٿا؟ آرڊر ڏيڻ يا دوستن کي سفارش ڪندي اسان جي مدد ڪريو، , داخلا-سطح سرورز جو هڪ منفرد اينالاگ، جيڪو اسان توهان لاءِ ايجاد ڪيو هو: (RAID1 ۽ RAID10 سان دستياب آهي، 24 ڪور تائين ۽ 40GB DDR4 تائين).
ڊيل R730xd 2x سستا Equinix Tier IV ڊيٽا سينٽر ۾ Amsterdam ۾؟ صرف هتي هالينڊ ۾! ڊيل R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 کان! جي باري ۾ پڙهو
جو ذريعو: www.habr.com