គិតដោយប្រុងប្រយ័ត្នមុនពេលប្រើ 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 វដ្តនៃការអភិវឌ្ឍន៍ធម្មតាមើលទៅដូចនេះ៖

• ការលួចចូល hack;
• សាងសង់;
• បញ្ឈប់ដេមិន Docker ដែលកំពុងដំណើរការ;
• បើកដំណើរការដេមិន Docker ថ្មី;
• ការធ្វើតេស្ត;
• ធ្វើវដ្តម្តងទៀត។

ប្រសិនបើអ្នកចង់បង្កើតការជួបប្រជុំគ្នាដ៏ស្រស់ស្អាត និងអាចផលិតឡើងវិញបាន (នោះគឺនៅក្នុងធុងមួយ) នោះវាកាន់តែស្មុគស្មាញ៖

• ការលួចចូល hack;
• ត្រូវប្រាកដថាកំណែការងាររបស់ Docker កំពុងដំណើរការ។
• បង្កើត Docker ថ្មីជាមួយ Docker ចាស់;
• បញ្ឈប់ Docker ដេមិន;
• ចាប់ផ្តើមដេមិន Docker ថ្មី;
• តេស្ត;
• បញ្ឈប់ដេមិន Docker ថ្មី;
• ធ្វើម្តងទៀត។

ជាមួយនឹងការមកដល់នៃ Docker-in-Docker ដំណើរការបានក្លាយទៅជាសាមញ្ញជាងមុន៖

• ការលួចចូល hack;
• ការជួបប្រជុំគ្នា + ការបើកដំណើរការក្នុងដំណាក់កាលមួយ;
• ធ្វើវដ្តម្តងទៀត។

វិធីនេះមិនប្រសើរជាងទេ?

Docker-in-Docker: "អាក្រក់"

ទោះយ៉ាងណាក៏ដោយ ផ្ទុយទៅនឹងជំនឿដ៏ពេញនិយម Docker-in-Docker មិនមែនជាតារា 100% សត្វសេះ និងសត្វចម្លែកនោះទេ។ អ្វី​ដែល​ខ្ញុំ​ចង់​និយាយ​គឺ​ថា​មាន​បញ្ហា​ជា​ច្រើន​ដែល​អ្នក​អភិវឌ្ឍន៍​ត្រូវ​ដឹង​។

មួយក្នុងចំណោមពួកគេទាក់ទងនឹង LSMs (ម៉ូឌុលសុវត្ថិភាពលីនុច) ដូចជា AppArmor និង SELinux៖ នៅពេលដំណើរការកុងតឺន័រ "Docker ខាងក្នុង" អាចព្យាយាមអនុវត្តទម្រង់សុវត្ថិភាពដែលនឹងប៉ះទង្គិចឬច្រឡំ "Docker ខាងក្រៅ" ។ នេះគឺជាបញ្ហាលំបាកបំផុតក្នុងការដោះស្រាយ នៅពេលដែលព្យាយាមបញ្ចូលគ្នានូវការអនុវត្តដើមនៃទង់ -privileged ។ ការផ្លាស់ប្តូររបស់ខ្ញុំបានដំណើរការ ហើយការធ្វើតេស្តទាំងអស់នឹងហុចនៅលើម៉ាស៊ីន Debian និង Ubuntu test VMs របស់ខ្ញុំ ប៉ុន្តែពួកគេនឹងគាំង និងឆេះនៅលើម៉ាស៊ីនរបស់ Michael Crosby (គាត់មាន Fedora ដូចដែលខ្ញុំចងចាំ)។ ខ្ញុំមិនអាចចាំពីមូលហេតុពិតប្រាកដនៃបញ្ហានោះទេ ប៉ុន្តែវាប្រហែលជាដោយសារតែ Mike គឺជាមនុស្សឆ្លាតម្នាក់ដែលធ្វើការជាមួយ SELINUX=enforce (ខ្ញុំបានប្រើ AppArmor) ហើយការផ្លាស់ប្តូររបស់ខ្ញុំមិនបានយកទម្រង់ SELinux ទៅក្នុងគណនីនោះទេ។

Docker-in-Docker: "អាក្រក់"

បញ្ហាទីពីរគឺជាមួយកម្មវិធីបញ្ជាផ្ទុក Docker ។ នៅពេលអ្នកដំណើរការ Docker-in-Docker នោះ Docker ខាងក្រៅដំណើរការនៅផ្នែកខាងលើនៃប្រព័ន្ធឯកសារធម្មតា (EXT4, BTRFS ឬអ្វីដែលអ្នកមាន) ហើយ Docker ខាងក្នុងដំណើរការនៅលើប្រព័ន្ធចម្លងលើការសរសេរ (AUFS, BTRFS, Device Mapper ល។ ) អាស្រ័យលើអ្វីដែលត្រូវបានកំណត់រចនាសម្ព័ន្ធដើម្បីប្រើ Docker ខាងក្រៅ)។ នេះបង្កើតបន្សំជាច្រើនដែលនឹងមិនដំណើរការ។ ឧទាហរណ៍ អ្នកនឹងមិនអាចដំណើរការ AUFS នៅលើ AUFS បានទេ។

ប្រសិនបើអ្នកដំណើរការ BTRFS នៅលើកំពូលនៃ BTRFS វាគួរតែដំណើរការដំបូង ប៉ុន្តែនៅពេលដែលមានបណ្តុំរងដែលបានដាក់រួច ការលុបភាគរងមេនឹងបរាជ័យ។ ម៉ូឌុលកម្មវិធីផែនទីឧបករណ៍មិនមានចន្លោះឈ្មោះទេ ដូច្នេះប្រសិនបើករណី Docker ច្រើនកំពុងដំណើរការវានៅលើម៉ាស៊ីនតែមួយ ពួកវាទាំងអស់នឹងអាចមើលឃើញ (និងមានឥទ្ធិពល) រូបភាពនៅលើគ្នាទៅវិញទៅមក និងនៅលើឧបករណ៍បម្រុងទុកកុងតឺន័រ។ នេះ​ជា​រឿង​អាក្រក់។

មានវិធីដោះស្រាយជាច្រើន ដើម្បីដោះស្រាយបញ្ហាទាំងនេះ។ ឧទាហរណ៍ ប្រសិនបើអ្នកចង់ប្រើ AUFS នៅក្នុង Docker ខាងក្នុង គ្រាន់តែបង្វែរថតឯកសារ /var/lib/docker ទៅជាភាគ នោះអ្នកនឹងមិនអីទេ។ Docker បានបន្ថែមចន្លោះឈ្មោះមូលដ្ឋានមួយចំនួនទៅឈ្មោះគោលដៅឧបករណ៍ Mapper ដូច្នេះប្រសិនបើការហៅ Docker ច្រើនកំពុងដំណើរការនៅលើម៉ាស៊ីនតែមួយ ពួកគេនឹងមិនឈានជើងគ្នាទៅវិញទៅមកទេ។

ទោះជាយ៉ាងណាក៏ដោយ ការរៀបចំបែបនេះមិនសាមញ្ញទេ ដូចដែលអាចមើលឃើញពីចំណុចទាំងនេះ អត្ថបទ នៅក្នុងឃ្លាំង dind នៅលើ GitHub ។

Docker-in-Docker៖ វាកាន់តែអាក្រក់ទៅៗ

ចុះ​ឃ្លាំង​សម្ងាត់​បង្កើត​វិញ? នេះក៏អាចជាការលំបាកផងដែរ។ មនុស្សតែងតែសួរខ្ញុំថា "ប្រសិនបើខ្ញុំកំពុងដំណើរការ Docker-in-Docker តើខ្ញុំអាចប្រើរូបភាពដែលបង្ហោះនៅលើម៉ាស៊ីនរបស់ខ្ញុំ ជំនួសឱ្យការទាញអ្វីៗគ្រប់យ៉ាងចូលទៅក្នុង Docker ខាងក្នុងរបស់ខ្ញុំវិញ"?

មនុស្សដែលមានគំនិតច្នៃប្រឌិតមួយចំនួនបានព្យាយាមចង /var/lib/docker ពី host ទៅ Docker-in-Docker container។ ពេលខ្លះពួកគេចែករំលែក /var/lib/docker ជាមួយធុងច្រើន។

តើអ្នកចង់ខូចទិន្នន័យរបស់អ្នកទេ? ព្រោះនេះជាអ្វីដែលបំផ្លាញទិន្នន័យរបស់អ្នក!

ដេមិន Docker ត្រូវបានរចនាឡើងយ៉ាងច្បាស់លាស់ដើម្បីឱ្យមានការចូលប្រើផ្តាច់មុខទៅកាន់ /var/lib/docker ។ គ្មាន​អ្វី​ផ្សេង​ទៀត​ដែល​គួរ "ប៉ះ ចាក់ ឬ​ផលិត" ឯកសារ Docker ដែល​មាន​ទីតាំង​ក្នុង​ថត​នេះ​ទេ។

ហេតុ​អ្វី​បាន​ជា​យ៉ាង​នេះ? ដោយសារតែនេះគឺជាលទ្ធផលនៃមេរៀនដ៏លំបាកបំផុតមួយដែលបានរៀនខណៈពេលដែលកំពុងអភិវឌ្ឍ dotCloud ។ ម៉ាស៊ីនកុងតឺន័រ dotCloud ដំណើរការដោយដំណើរការជាច្រើនដែលចូលប្រើ /var/lib/dotcloud ក្នុងពេលដំណាលគ្នា។ ល្បិចបោកបញ្ឆោតដូចជាការជំនួសឯកសារអាតូមិក (ជំនួសឱ្យការកែសម្រួលនៅនឹងកន្លែង) ការបញ្ចូលកូដដោយការណែនាំ និងការចាក់សោជាកាតព្វកិច្ច និងការពិសោធន៍ផ្សេងទៀតជាមួយប្រព័ន្ធសុវត្ថិភាពដូចជា SQLite និង BDB មិនតែងតែដំណើរការទេ។ នៅពេលដែលយើងកំពុងរចនាឡើងវិញនូវម៉ាស៊ីនកុងតឺន័ររបស់យើង ដែលទីបំផុតបានក្លាយទៅជា Docker ការសម្រេចចិត្តរចនាដ៏ធំមួយគឺការបង្រួបបង្រួមប្រតិបត្តិការកុងតឺន័រទាំងអស់នៅក្រោមដេមិនតែមួយ ដើម្បីកម្ចាត់ចោលនូវភាពសមហេតុសមផលរួមទាំងអស់។

កុំយល់ច្រឡំ៖ វាអាចទៅរួចទាំងស្រុងក្នុងការបង្កើតអ្វីមួយដែលល្អ គួរឱ្យទុកចិត្ត និងលឿន ដែលពាក់ព័ន្ធនឹងដំណើរការជាច្រើន និងការគ្រប់គ្រងស្របទំនើប។ ប៉ុន្តែយើងគិតថា វាកាន់តែងាយស្រួល និងងាយស្រួលជាងក្នុងការសរសេរ និងរក្សាកូដដោយប្រើ Docker ជាអ្នកលេងតែមួយគត់។

នេះមានន័យថាប្រសិនបើអ្នកចែករំលែកថត /var/lib/docker រវាង Docker ច្រើន អ្នកនឹងមានបញ្ហា។ ជាការពិតណាស់ នេះអាចដំណើរការបាន ជាពិសេសនៅក្នុងដំណាក់កាលដំបូងនៃការធ្វើតេស្ត។ "ស្តាប់ ម៉ា ខ្ញុំអាចដំណើរការ ubuntu ជា docker បាន!" ប៉ុន្តែ​សាកល្បង​អ្វី​ដែល​ស្មុគស្មាញ​ជាង​នេះ ដូចជា​ទាញ​រូបភាព​ដូចគ្នា​ពី​ឧទាហរណ៍​ពីរ​ផ្សេង​គ្នា ហើយ​អ្នក​នឹង​ឃើញ​ពិភពលោក​ឆេះ។

នេះមានន័យថា ប្រសិនបើប្រព័ន្ធ CI របស់អ្នកដំណើរការសាងសង់ និងបង្កើតឡើងវិញ រាល់ពេលដែលអ្នកចាប់ផ្តើមកុងតឺន័រ Docker-in-Docker របស់អ្នកឡើងវិញ នោះអ្នកនឹងប្រថុយនឹងទម្លាក់ nuke ទៅក្នុងឃ្លាំងសម្ងាត់របស់វា។ នេះមិនឡូយទាល់តែសោះ!

ការដោះស្រាយបញ្ហា

តោះ​មួយ​ជំហាន​ថយ​ក្រោយ។ តើអ្នកពិតជាត្រូវការ Docker-in-Docker ឬតើអ្នកគ្រាន់តែចង់អាចដំណើរការ Docker និងបង្កើត និងដំណើរការកុងតឺន័រ និងរូបភាពពីប្រព័ន្ធ CI របស់អ្នក ខណៈដែលប្រព័ន្ធ CI ខ្លួនឯងស្ថិតនៅក្នុងកុងតឺន័រ?

ខ្ញុំភ្នាល់ថាមនុស្សភាគច្រើនចង់បានជម្រើសចុងក្រោយ មានន័យថាពួកគេចង់បានប្រព័ន្ធ CI ដូចជា Jenkins ដើម្បីអាចដំណើរការកុងតឺន័របាន។ ហើយវិធីងាយស្រួលបំផុតដើម្បីធ្វើវាគឺគ្រាន់តែបញ្ចូលរន្ធ Docker ទៅក្នុងកុងតឺន័រ CI របស់អ្នក ហើយភ្ជាប់វាជាមួយទង់ -v ។

និយាយឱ្យសាមញ្ញ នៅពេលអ្នកដំណើរការកុងតឺន័រ CI របស់អ្នក (Jenkins ឬផ្សេងទៀត) ជំនួសឱ្យការលួចចូលអ្វីមួយជាមួយ Docker-in-Docker សូមចាប់ផ្តើមវាជាមួយបន្ទាត់៖

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

ឥឡូវនេះកុងតឺន័រនេះនឹងមានសិទ្ធិចូលប្រើរន្ធ Docker ដូច្នេះហើយអាចដំណើរការកុងតឺន័របាន។ លើកលែងតែថាជំនួសឱ្យការដំណើរការកុងតឺន័រ "កុមារ" វានឹងបើកដំណើរការធុង "បងប្អូនបង្កើត" ។

សាកល្បងវាដោយប្រើរូបភាព docker ផ្លូវការ (ដែលមាន Docker binary):

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។

ការផ្សាយពាណិជ្ជកម្មមួយចំនួន🙂

សូមអរគុណចំពោះការស្នាក់នៅជាមួយពួកយើង។ តើអ្នកចូលចិត្តអត្ថបទរបស់យើងទេ? ចង់មើលខ្លឹមសារគួរឱ្យចាប់អារម្មណ៍បន្ថែមទៀតទេ? គាំទ្រយើងដោយការបញ្ជាទិញឬណែនាំដល់មិត្តភក្តិ, cloud VPS សម្រាប់អ្នកអភិវឌ្ឍន៍ចាប់ពី $4.99, analogue តែមួយគត់នៃម៉ាស៊ីនមេកម្រិតធាតុ ដែលត្រូវបានបង្កើតឡើងដោយពួកយើងសម្រាប់អ្នក៖ ការពិតទាំងមូលអំពី VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ចាប់ពី $19 ឬរបៀបចែករំលែកម៉ាស៊ីនមេ? (អាចប្រើបានជាមួយ RAID1 និង RAID10 រហូតដល់ 24 cores និងរហូតដល់ 40GB DDR4)។

Dell R730xd 2x ថោកជាងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ Equinix Tier IV នៅទីក្រុង Amsterdam? នៅទីនេះ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ចាប់ពី $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