Docker-in-Docker یو مجازی شوی ډاکر ډیمون دی چې پخپله کانټینر کې د کانټینر عکسونو جوړولو لپاره روان دی. د ډاکر-ان-ډاکر رامینځته کولو اصلي هدف د ډاکر پخپله وده کې مرسته کول وو. ډیری خلک دا د جینکنز CI چلولو لپاره کاروي. دا په لومړي سر کې نورمال ښکاري ، مګر بیا ستونزې رامینځته کیږي چې د جینکنز CI کانټینر کې د ډاکر په نصبولو سره مخنیوی کیدی شي. دا مقاله تشریح کوي چې دا څنګه ترسره کړئ. که تاسو د توضیحاتو پرته وروستي حل کې علاقه لرئ ، یوازې د ستونزې حل کولو مقالې وروستۍ برخه ولولئ.
ډاکر په ډاکر: ښه
دوه کاله دمخه ما په ډاکر کې واچاوه - امتياز او ليکل . موخه دا وه چې د اصلي ټیم سره مرسته وکړي چې د ډاکر ګړندی وده وکړي. د Docker-in-Docker څخه مخکې، د پراختیا عادي دوره وه:
- hackity hack;
- مجلس (جوړول)؛
- د ډاکر ډیمون چلول بند کړئ؛
- د نوي ډاکر ډیمون پیل کول؛
- ازموینه
- دوره تکرار.
که تاسو غواړئ یو ښکلی، د بیا تولید وړ مجلس جوړ کړئ (چې په کانتینر کې دی)، نو دا خورا پیچلې شوه:
- hackity hack;
- ډاډ ترلاسه کړئ چې د ډاکر کاري نسخه روانه ده؛
- د زاړه ډاکر سره نوی ډاکر جوړ کړئ؛
- د ډاکر ډیمون مخه ونیسئ؛
- نوی ډاکر ډیمون پیل کړئ؛
- ازموینه
- د نوي ډاکر ډیمون مخه ونیسئ؛
- تکرار
د Docker-in-Docker په راتګ سره، پروسه ساده شوې ده:
- hackity hack;
- مجلس + په یو ګام کې پیل کول؛
- دوره تکرار.
دا دومره ښه نه ده؟
په ډاکر کې ډاکر: "خراب"
په هرصورت، د مشهور باور برعکس، ډاکر-ان-ډاکر 100٪ ستوري، ټوني او یونیکورن ندي. زما مطلب دا دی چې یو څو مسلې شتون لري چې یو پراختیا کونکی باید خبر وي.
یو د LSMs (لینکس امنیت ماډلونه) لکه AppArmor او SELinux اندیښنه لري: کله چې کانټینر چلوي ، "داخلي ډاکر" ممکن د امنیت پروفایلونو پلي کولو هڅه وکړي چې د "بهرني ډاکر" سره شخړه یا مبهم کړي. دا د حل کولو ترټولو سخته ستونزه ده کله چې د --privileged بیرغ اصلي پلي کولو سره یوځای کولو هڅه کوي. زما بدلونونه کار کوي او ټولې ازموینې به زما د ډیبیان ماشین کې هم تیریږي او د اوبنټو VMs ازموینه کوي ، مګر دوی به د مایکل کراسبي ماشین کې غورځیدلي او سوځوي (هغه تر هغه ځایه چې زما په یاد دي فیډورا درلوده). زه د ستونزې اصلي لامل په یاد نه لرم، مګر دا ممکن وي ځکه چې مایک یو هوښیار سړی دی چې د SELINUX=enforce سره کار کوي (ما AppArmor کارولی) او زما بدلونونه د SELinux پروفایلونو ته درناوی نه کوي.
په ډاکر کې ډاکر: "شر"
دویمه ستونزه د ډاکر ذخیره کولو چلوونکو پورې اړه لري. کله چې تاسو Docker-in-Docker چلوئ، بهرنی ډاکر د منظم فایل سیسټم (EXT4، BTRFS، یا هر هغه څه چې تاسو یې لرئ) په سر کې پرمخ ځي، پداسې حال کې چې داخلي ډاکر د کاپي لیکلو سیسټم (AUFS، BTRFS، د وسیلې میپر، او داسې نور). په دې حالت کې، ډیری ترکیبونه شتون لري چې کار نه کوي. د مثال په توګه، تاسو نشئ کولی د AUFS په سر کې AUFS چل کړئ.
که تاسو د BTRFS په سر کې BTRFS پرمخ وړئ، دا باید په لومړي سر کې کار وکړي، مګر یوځل چې د نیست شوي فرعي حجم شتون ولري، اصلي فرعي حجم نشي حذف کیدی. د وسیلې میپر ماډل بې نوم دی ، نو که چیرې ډیری ډاکر مثالونه دا په ورته ماشین کې وکاروي ، نو دوی به ټول د دې وړتیا ولري چې د یو بل عکسونه (او نفوذ) وګوري او د کانټینر بیک اپ وسیلو. دا بد دی.
د دې ډیری ستونزو د حل لپاره د حل لارې شتون لري. د مثال په توګه ، که تاسو غواړئ په داخلي ډاکر کې AUFS وکاروئ ، نو یوازې /var/lib/docker فولډر حجم ته واړوئ او تاسو به ښه یاست. ډاکر د وسیلې میپر هدف نومونو کې ځینې بیس نوم ځایونه اضافه کړي ترڅو که چیرې په ورته ماشین کې ډیری ډاکر زنګونه وشي ، نو دوی به یو بل ته "مرحله" ونه کړي.
په هرصورت ، دا تنظیم کول خورا اسانه ندي ، لکه څنګه چې تاسو له دې څخه لیدلی شئ په GitHub کې د ډینډ ذخیره کې.
په ډاکر کې ډاکر: بدتر کیدل
د جوړونې کیچ په اړه څه؟ دا هم خورا پیچلې کیدی شي. خلک ډیری وختونه له ما څخه پوښتنه کوي "که زه د ډاکر ان ډاکر چلوم ، نو زه څنګه کولی شم زما په کوربه کې کوربه شوي عکسونه وکاروم د دې پرځای چې زما په داخلي ډاکر کې هرڅه راوباسي"؟
ځینې متشبثینو هڅه کړې چې /var/lib/docker له کوربه څخه د Docker-in-Docker کانټینر سره وصل کړي. ځینې وختونه دوی د ډیری کانټینرونو سره /var/lib/docker شریکوي.
غواړئ ډاټا فاسد کړئ؟ ځکه چې دا هغه څه دي چې ستاسو ډاټا فاسد کوي!
د ډاکر ډیمون په واضح ډول ډیزاین شوی و چې /var/lib/docker ته ځانګړي لاسرسی ولري. نور هیڅ شی باید په دې فولډر کې د ډاکر فایلونو "لمس ، پوک یا احساس ونه کړي".
ولې داسې ده؟ ځکه چې دا د ډاټ کلاډ په پراختیا کې د زده کړل شوي یو له خورا سخت درسونو پایله ده. د ډاټ کلاډ کانټینر انجن په ورته وخت کې /var/lib/dotcloud ته د لاسرسي ډیری پروسو سره کار کوي. چالاک چلونه لکه د اټومي فایل بدلول (په ځای کې د ترمیم پرځای)، د مشورتي او لازمي لاکونو سره مرچ کوډ، او د خوندي سیسټمونو لکه SQLite او BDB سره نورې تجربې تل کار نه کوي. کله چې موږ د خپل کانټینر انجن له سره ډیزاین کوو، کوم چې په پای کې ډاکر شو، د ډیزاین اصلي پریکړو څخه یوه دا وه چې ټول کانټینر عملیات د یو واحد ډیمون لاندې راټول کړي ترڅو د دې ټول همغږي بې ځایه خبرې له منځه یوسي.
ما غلط مه کوئ: دا په بشپړ ډول ممکنه ده چې یو څه ښه، معتبر او ګړندی جوړ کړئ چې ډیری پروسې او عصري موازي کنټرول پکې شامل وي. مګر موږ فکر کوو چې د یوازینی لوبغاړي په توګه د ډاکر سره کوډ لیکل او ساتل اسانه او اسانه دي.
دا پدې مانا ده چې که تاسو د ډیری ډاکر مثالونو کې /var/lib/docker لارښود شریک کړئ، تاسو به په ستونزه کې یاست. البته، دا کار کولی شي، په ځانګړې توګه د ازموینې په لومړیو مرحلو کې. "واورئ، ما، زه د ډاکر سره اوبنټو چلولی شم!" مګر یو څه ډیر پیچلي هڅه وکړئ ، لکه د دوه مختلف مثالونو څخه ورته عکس راوباسئ ، او تاسو به وګورئ چې نړۍ سوځیدلی.
دا پدې مانا ده چې که ستاسو د CI سیسټم جوړونه او بیا رغونه کوي، نو هرکله چې تاسو خپل د Docker-in-Docker کانټینر بیا پیل کړئ، تاسو د هغې زیرمه کې د اټومي بم د غورځولو خطر پرمخ وړئ. دا په بشپړه توګه ښه نه ده!
ستونزه حل کول
راځئ چې یو ګام بیرته واخلو. ایا تاسو واقعیا Docker-in-Docker ته اړتیا لرئ ، یا تاسو یوازې غواړئ د ډاکر چلولو وړ اوسئ ، د بیلګې په توګه ستاسو د CI سیسټم څخه کانټینرونه او عکسونه رامینځته کول او چلول ، پداسې حال کې چې دا CI سیسټم پخپله په کانټینر کې دی؟
زه شرط لرم چې ډیری خلک وروستی اختیار غواړي، د بیلګې په توګه دوی د جینکنز په څیر د 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 نه دی: کله چې دا کانټینر اضافي کانټینرونه رامینځته کوي، دوی به په لوړ پوړ ډاکر کې جوړ شي. تاسو به د ځړولو ضمني اغیزې تجربه نه کړئ ، او د مجلس کیچ به په ډیری تلیفونونو کې شریک شي.
یادونه: د دې مقالې مخکینۍ نسخې د کوربه څخه کانټینر ته د ډاکر بائنری لینک کولو مشوره ورکړه. دا اوس د اعتبار وړ نه دی ځکه چې د ډاکر انجن نور جامد یا نږدې جامد کتابتونونو ته نه غځوي.
نو که تاسو غواړئ د جینکنز CI څخه ډاکر وکاروئ تاسو 2 اختیارونه لرئ:
د لومړني عکس بسته کولو سیسټم په کارولو سره د ډاکر CLI نصب کول (د مثال په توګه که ستاسو عکس د Debian پراساس وي ، د .deb کڅوړې وکاروئ) ، د Docker API په کارولو سره.
ځینې اعلانونه 🙂
له موږ سره د پاتې کیدو لپاره مننه. ایا تاسو زموږ مقالې خوښوي؟ غواړئ نور په زړه پورې مینځپانګه وګورئ؟ د امر په ورکولو یا ملګرو ته وړاندیز کولو سره زموږ ملاتړ وکړئ ، , د ننوتلو کچې سرورونو یو ځانګړی انلاګ ، کوم چې زموږ لخوا ستاسو لپاره اختراع شوی و: (د RAID1 او RAID10 سره شتون لري، تر 24 کور پورې او تر 40GB DDR4 پورې).
ډیل R730xd په امستردام کې د Equinix Tier IV ډیټا مرکز کې 2 ځله ارزانه؟ یوازې دلته په هالنډ کې! ډیل R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - له $ 99 څخه! په اړه ولولئ
سرچینه: www.habr.com