კარგად დაფიქრდით Docker-in-Docker-ის გამოყენებამდე CI-ისთვის ან სატესტო გარემოსთვის

Docker-in-Docker არის ვირტუალური Docker დემონური გარემო, რომელიც მუშაობს კონტეინერში კონტეინერის სურათების შესაქმნელად. Docker-in-Docker-ის შექმნის მთავარი მიზანი იყო თავად Docker-ის განვითარებაში დახმარება. ბევრი ადამიანი იყენებს მას Jenkins CI-ის გასაშვებად. ეს თავიდან ნორმალური ჩანს, მაგრამ შემდეგ წარმოიქმნება პრობლემები, რომელთა თავიდან აცილება შესაძლებელია Docker-ის დაყენებით Jenkins CI კონტეინერში. ეს სტატია გეტყვით, თუ როგორ უნდა გააკეთოთ ეს. თუ გაინტერესებთ საბოლოო გადაწყვეტა დეტალების გარეშე, უბრალოდ წაიკითხეთ სტატიის ბოლო ნაწილი, „პრობლემის გადაჭრა“.

Docker-in-Docker: "კარგი"

ორ წელზე მეტი ხნის წინ ჩავაბარე Docker-ში დროშა – პრივილეგირებული და დაწერა დინდის პირველი ვერსია. მიზანი იყო დახმარებოდა ძირითად გუნდს Docker-ის უფრო სწრაფად განვითარებაში. Docker-in-Docker-მდე, განვითარების ტიპიური ციკლი ასე გამოიყურებოდა:

• hackity hack;
• აშენება;
• გაშვებული Docker დემონის შეჩერება;
• ახალი Docker დემონის გაშვება;
• ტესტირება;
• გაიმეორეთ ციკლი.

თუ გინდოდათ ლამაზი, რეპროდუცირებადი ასამბლეის გაკეთება (ანუ კონტეინერში), მაშინ ის უფრო რთული გახდა:

• hackity hack;
• დარწმუნდით, რომ მუშაობს Docker-ის სამუშაო ვერსია;
• შექმენით ახალი დოკერი ძველი დოკერით;
• შეაჩერე დოკერის დემონი;
• დაიწყეთ ახალი Docker დემონი;
• ტესტი;
• შეაჩერე ახალი დოკერის დემონი;
• გაიმეორეთ.

Docker-in-Docker-ის მოსვლასთან ერთად, პროცესი უფრო მარტივი გახდა:

• hackity hack;
• შეკრება + გაშვება ერთ ეტაპზე;
• გაიმეორეთ ციკლი.

ასე არ ჯობია?

Docker-in-Docker: "ცუდი"

თუმცა, პოპულარული რწმენის საწინააღმდეგოდ, Docker-in-Docker არ არის 100% ვარსკვლავები, პონიები და unicorns. მე ვგულისხმობ არის ის, რომ არის რამდენიმე საკითხი, რომელიც დეველოპერმა უნდა იცოდეს.

ერთ-ერთი მათგანი ეხება LSM-ებს (Linux-ის უსაფრთხოების მოდულებს), როგორიცაა AppArmor და SELinux: კონტეინერის გაშვებისას, „შიდა დოკერმა“ შეიძლება შეეცადოს გამოიყენოს უსაფრთხოების პროფილები, რომლებიც კონფლიქტში მოჰყვება ან აღრევს „გარე დოკერს“. ეს არის ყველაზე რთული გადასაჭრელი პრობლემა, როდესაც ვცდილობთ შევაერთოთ ორიგინალური პრივილეგირებული დროშა. ჩემმა ცვლილებებმა იმუშავა და ყველა ტესტი გაივლიდა ჩემს Debian მანქანას და Ubuntu-ს ტესტირებულ VM-ებს, მაგრამ ისინი ავარიდებოდნენ და დაიწვებოდნენ მაიკლ კროსბის აპარატზე (მას ჰყავდა Fedora, როგორც მახსოვს). მე არ მახსოვს პრობლემის ზუსტი მიზეზი, მაგრამ შეიძლება იმიტომ, რომ მაიკი ბრძენი ბიჭია, რომელიც მუშაობს SELINUX=enforce-ით (გამოვიყენე AppArmor) და ჩემი ცვლილებები არ ითვალისწინებდა SELinux-ის პროფილებს.

Docker-in-Docker: "ბოროტი"

მეორე პრობლემა ეხება Docker შენახვის დრაივერებს. Docker-in-Docker-ის გაშვებისას, გარე Docker მუშაობს ჩვეულებრივი ფაილური სისტემის თავზე (EXT4, BTRFS, ან რაც გაქვთ) და შიდა Docker მუშაობს ასლი-ჩაწერის სისტემის თავზე (AUFS, BTRFS, Device Mapper). და ა.შ.). , იმისდა მიხედვით, თუ რა არის კონფიგურირებული გარე დოკერის გამოსაყენებლად). ეს ქმნის ბევრ კომბინაციას, რომელიც არ იმუშავებს. მაგალითად, თქვენ ვერ შეძლებთ AUFS-ის გაშვებას AUFS-ის თავზე.

თუ BTRFS-ს აწარმოებთ BTRFS-ის თავზე, მან თავიდან უნდა იმუშაოს, მაგრამ მას შემდეგ რაც იქნება ჩადგმული ქვეტომები, მშობელი ქვეტომის წაშლა ვერ მოხერხდება. Device Mapper მოდულს არ აქვს სახელთა სივრცე, ასე რომ, თუ Docker-ის რამდენიმე ინსტანცია ამუშავებს მას ერთ მანქანაზე, ისინი ყველა შეძლებენ ნახონ (და გავლენა მოახდინონ) სურათებზე ერთმანეთზე და კონტეინერის სარეზერვო მოწყობილობებზე. Ეს არის ცუდი.

არსებობს გამოსავალი მრავალი ამ პრობლემის გადასაჭრელად. მაგალითად, თუ გსურთ გამოიყენოთ AUFS შიდა Docker-ში, უბრალოდ გადააქციეთ /var/lib/docker საქაღალდე ტომად და კარგად იქნებით. Docker-მა დაამატა რამდენიმე საბაზისო სახელების სივრცე Device Mapper-ის სამიზნე სახელებში, რათა თუ Docker-ის რამდენიმე ზარი ერთსა და იმავე მოწყობილობაზე მუშაობს, ისინი ერთმანეთს არ დააბიჯებენ.

თუმცა, ასეთი დაყენება სულაც არ არის მარტივი, როგორც აქედან ჩანს სტატიები GitHub-ის dind საცავში.

Docker-in-Docker: ეს უარესდება

რაც შეეხება build cache-ს? ეს ასევე შეიძლება საკმაოდ რთული იყოს. ადამიანები ხშირად მეკითხებიან: „თუ მე ვიყენებ Docker-in-Docker-ს, როგორ შემიძლია გამოვიყენო სურათები, რომლებიც განთავსებულია ჩემს ჰოსტზე, იმის ნაცვლად, რომ ყველაფერი უკან დავიხიო ჩემს შიდა Docker-ში“?

ზოგიერთი მეწარმე ცდილობდა /var/lib/docker-ის მიბმა მასპინძლიდან Docker-in-Docker კონტეინერთან. ზოგჯერ ისინი იზიარებენ /var/lib/docker-ს მრავალ კონტეინერთან.

გსურთ თქვენი მონაცემების კორუმპირება? რადგან ეს არის ზუსტად ის, რაც დააზიანებს თქვენს მონაცემებს!

Docker დემონი აშკარად შეიქმნა იმისათვის, რომ ჰქონდეს ექსკლუზიური წვდომა /var/lib/docker-ზე. სხვა არაფერი არ უნდა „შეეხოს, დაარტყას ან აწარმოოს“ Docker ფაილი, რომელიც მდებარეობს ამ საქაღალდეში.

რატომ არის ეს ასე? რადგან ეს არის ერთ-ერთი ყველაზე რთული გაკვეთილის შედეგი, რომელიც ვისწავლეთ dotCloud-ის შემუშავებისას. dotCloud კონტეინერის ძრავა მუშაობდა რამდენიმე პროცესის წვდომით /var/lib/dotcloud ერთდროულად. მზაკვრული ხრიკები, როგორიცაა ატომური ფაილის ჩანაცვლება (ადგილობრივი რედაქტირების ნაცვლად), კოდის აკრეფა საკონსულტაციო და სავალდებულო საკეტებით და სხვა ექსპერიმენტები უსაფრთხო სისტემებით, როგორიცაა SQLite და BDB, ყოველთვის არ მუშაობდა. როდესაც ჩვენ ვაკეთებდით კონტეინერის ძრავის ხელახლა დიზაინს, რომელიც საბოლოოდ გახდა Docker, ერთ-ერთი დიდი დიზაინის გადაწყვეტილება იყო კონტეინერის ყველა ოპერაციების გაერთიანება ერთი დემონის ქვეშ, რათა თავიდან ავიცილოთ ყველა კონკურენტული სისულელე.

არასწორად არ გამიგოთ: სავსებით შესაძლებელია რაიმე კარგი, საიმედო და სწრაფი დამზადება, რომელიც მოიცავს მრავალ პროცესს და თანამედროვე პარალელურ კონტროლს. მაგრამ ჩვენ ვფიქრობთ, რომ უფრო მარტივი და ადვილია კოდის დაწერა და შენარჩუნება Docker-ის, როგორც ერთადერთი მოთამაშის გამოყენებით.

ეს ნიშნავს, რომ თუ თქვენ იზიარებთ /var/lib/docker დირექტორიას რამდენიმე Docker ინსტანციას შორის, პრობლემები შეგექმნებათ. რა თქმა უნდა, ამან შეიძლება იმუშაოს, განსაკუთრებით ტესტირების ადრეულ ეტაპებზე. ”მისმინე, დედა, მე შემიძლია გავუშვა ubuntu, როგორც დოკერი!” მაგრამ სცადეთ რაღაც უფრო რთული, როგორიცაა ერთი და იგივე სურათის ამოღება ორი განსხვავებული ინსტანციიდან და დაინახავთ, რომ სამყარო იწვის.

ეს ნიშნავს, რომ თუ თქვენი CI სისტემა ახორციელებს build-ებს და აღადგენს, ყოველ ჯერზე, როდესაც თქვენ გადატვირთავთ თქვენს Docker-in-Docker კონტეინერს, თქვენ რისკავთ ბირთვული იარაღის მის ქეში ჩაგდებას. ეს სულაც არ არის მაგარი!

გადაწყვეტა

მოდით გადავდგათ ნაბიჯი უკან. ნამდვილად გჭირდებათ Docker-in-Docker ან უბრალოდ გსურთ შეძლოთ Docker-ის გაშვება და თქვენი CI სისტემიდან კონტეინერების და სურათების აშენება და გაშვება მაშინ, როცა ეს CI სისტემა თავად არის კონტეინერში?

დადებს, რომ ადამიანების უმეტესობას სურს ეს უკანასკნელი ვარიანტი, რაც იმას ნიშნავს, რომ მათ სურთ CI სისტემა, როგორიცაა ჯენკინსი, რომ შეძლოს კონტეინერების გაშვება. და ამის გაკეთების უმარტივესი გზაა უბრალოდ ჩასვათ Docker სოკეტი თქვენს CI კონტეინერში და დააკავშიროთ იგი -v დროშასთან.

მარტივად რომ ვთქვათ, როდესაც თქვენ მართავთ თქვენს CI კონტეინერს (ჯენკინსი ან სხვა), იმის ნაცვლად, რომ რაღაც გატეხოთ Docker-in-Docker-თან ერთად, დაიწყეთ იგი ხაზით:

docker run -v /var/run/docker.sock:/var/run/docker.sock ...

ამ კონტეინერს ახლა ექნება წვდომა Docker სოკეტზე და, შესაბამისად, შეძლებს კონტეინერების გაშვებას. გარდა იმისა, რომ „ბავშვის“ კონტეინერების გაშვების ნაცვლად, ის „და-ძმის“ კონტეინერებს გაუშვებს.

სცადეთ ეს დოკერის ოფიციალური სურათის გამოყენებით (რომელიც შეიცავს Docker ორობითობას):

docker run -v /var/run/docker.sock:/var/run/docker.sock 
           -ti docker

ის გამოიყურება და მუშაობს Docker-in-Docker-ის მსგავსად, მაგრამ ის არ არის Docker-in-Docker: როდესაც ეს კონტეინერი ქმნის დამატებით კონტეინერებს, ისინი შეიქმნება ზედა დონის Docker-ში. თქვენ არ განიცდით ბუდობის გვერდით ეფექტებს და ასამბლეის ქეში გაზიარებული იქნება მრავალ ზარზე.

შენიშვნა: ამ სტატიის წინა ვერსიებში რეკომენდებულია Docker ორობითი ჰოსტიდან კონტეინერთან დაკავშირება. ეს უკვე არასანდო გახდა, რადგან Docker ძრავა აღარ ფარავს სტატიკური ან თითქმის სტატიკური ბიბლიოთეკებს.

ასე რომ, თუ გსურთ გამოიყენოთ Docker Jenkins CI-დან, გაქვთ 2 ვარიანტი:
Docker CLI-ის დაყენება სურათების შეფუთვის ძირითადი სისტემის გამოყენებით (ანუ, თუ თქვენი სურათი დაფუძნებულია Debian-ზე, გამოიყენეთ .deb პაკეტები), Docker API-ს გამოყენებით.

რამდენიმე რეკლამა 🙂

გმადლობთ, რომ დარჩით ჩვენთან. მოგწონთ ჩვენი სტატიები? გსურთ ნახოთ უფრო საინტერესო შინაარსი? მხარი დაგვიჭირეთ შეკვეთის განთავსებით ან მეგობრებისთვის რეკომენდაციით, ღრუბელი VPS დეველოპერებისთვის 4.99 დოლარიდან, საწყისი დონის სერვერების უნიკალური ანალოგი, რომელიც ჩვენ მიერ გამოგონილია თქვენთვის: მთელი სიმართლე VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps 19$-დან ან როგორ გავაზიარო სერვერი? (ხელმისაწვდომია RAID1 და RAID10-ით, 24 ბირთვამდე და 40 გბ-მდე DDR4).

Dell R730xd 2-ჯერ იაფია Equinix Tier IV მონაცემთა ცენტრში ამსტერდამში? Მხოლოდ აქ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ტელევიზორი $199-დან ნიდერლანდებში! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-დან! Წაიკითხო რაღაცის შესახებ როგორ ავაშენოთ ინფრასტრუქტურის კორპუსი. კლასი Dell R730xd E5-2650 v4 სერვერების გამოყენებით 9000 ევროს ღირებულების პენი?

წყარო: www.habr.com