सीआय किंवा चाचणी वातावरणासाठी डॉकर-इन-डॉकर वापरण्यापूर्वी काळजीपूर्वक विचार करा

डॉकर-इन-डॉकर हे कंटेनर प्रतिमा तयार करण्यासाठी कंटेनरमध्येच चालणारे आभासी डॉकर डिमन वातावरण आहे. डॉकर-इन-डॉकर तयार करण्याचा मुख्य उद्देश डॉकरला स्वतः विकसित करण्यात मदत करणे हा होता. जेनकिन्स सीआय चालवण्यासाठी बरेच लोक याचा वापर करतात. हे प्रथम सामान्य दिसते, परंतु नंतर समस्या उद्भवतात ज्या जेनकिन्स सीआय कंटेनरमध्ये डॉकर स्थापित करून टाळता येऊ शकतात. हे कसे करायचे ते हा लेख सांगतो. तुम्हाला तपशीलाशिवाय अंतिम समाधानामध्ये स्वारस्य असल्यास, "समस्या सोडवणे" या लेखाचा शेवटचा विभाग वाचा.

डॉकर-इन-डॉकर: "चांगले"

दोन वर्षांपूर्वी मी डॉकरमध्ये ठेवले झेंडा - विशेषाधिकार प्राप्त आणि लिहिले डिंडची पहिली आवृत्ती. मुख्य कार्यसंघाला डॉकर जलद विकसित करण्यात मदत करणे हे ध्येय होते. डॉकर-इन-डॉकरच्या आधी, सामान्य विकास चक्र असे दिसत होते:

• hackity hack;
• बांधणे
• चालू असलेला डॉकर डिमन थांबवणे;
• नवीन डॉकर डिमन लाँच करत आहे;
• चाचणी
• सायकल पुन्हा करा.

जर तुम्हाला एक सुंदर, पुनरुत्पादन करण्यायोग्य असेंब्ली बनवायची असेल (म्हणजे कंटेनरमध्ये), तर ते अधिक क्लिष्ट झाले:

• hackity hack;
• डॉकरची कार्यरत आवृत्ती चालू असल्याची खात्री करा;
• जुन्या डॉकरसह नवीन डॉकर तयार करा;
• डॉकर डिमन थांबवा;
• नवीन डॉकर डिमन सुरू करा;
• चाचणी
• नवीन डॉकर डिमन थांबवा;
• पुनरावृत्ती

डॉकर-इन-डॉकरच्या आगमनाने, प्रक्रिया सोपी झाली आहे:

• hackity hack;
• असेंबली + एका टप्प्यात लाँच;
• सायकल पुन्हा करा.

हे या मार्गाने बरेच चांगले नाही का?

डॉकर-इन-डॉकर: "वाईट"

तथापि, लोकप्रिय मान्यतेच्या विरुद्ध, डॉकर-इन-डॉकर 100% तारे, पोनी आणि युनिकॉर्न नाही. मला असे म्हणायचे आहे की अशा अनेक समस्या आहेत ज्यांची विकासकाला जाणीव असणे आवश्यक आहे.

त्यापैकी एक LSMs (Linux सुरक्षा मॉड्यूल्स) जसे की AppArmor आणि SELinux संबंधित आहे: कंटेनर चालवताना, "इंटर्नल डॉकर" सुरक्षा प्रोफाइल लागू करण्याचा प्रयत्न करू शकतो जे "बाह्य डॉकर" ला विरोध किंवा गोंधळात टाकतील. विशेषाधिकार प्राप्त ध्वजाची मूळ अंमलबजावणी विलीन करण्याचा प्रयत्न करताना सोडवणे ही सर्वात कठीण समस्या आहे. माझ्या बदलांनी काम केले आणि सर्व चाचण्या माझ्या डेबियन मशीन आणि उबंटू चाचणी VM वर पास होतील, परंतु त्या मायकेल क्रॉसबीच्या मशीनवर क्रॅश होऊन बर्न होतील (मला आठवते त्याप्रमाणे त्याच्याकडे फेडोरा होता). मला समस्येचे नेमके कारण आठवत नाही, पण कदाचित माईक हा एक शहाणा माणूस आहे जो SELINUX=enforce (मी AppArmor वापरला) सह काम करतो आणि माझे बदल SELinux प्रोफाइल विचारात घेत नाहीत.

डॉकर-इन-डॉकर: "वाईट"

दुसरी समस्या डॉकर स्टोरेज ड्रायव्हर्सची आहे. जेव्हा तुम्ही डॉकर-इन-डॉकर चालवता तेव्हा बाह्य डॉकर नियमित फाइल सिस्टमच्या वर चालते (EXT4, BTRFS, किंवा तुमच्याकडे जे काही आहे) आणि अंतर्गत डॉकर कॉपी-ऑन-राईट सिस्टम (AUFS, BTRFS, Device Mapper) वर चालतो. , इ.) , बाह्य डॉकर वापरण्यासाठी काय कॉन्फिगर केले आहे यावर अवलंबून). यामुळे अनेक कॉम्बिनेशन्स तयार होतात जे काम करणार नाहीत. उदाहरणार्थ, तुम्ही AUFS वर AUFS चालवू शकणार नाही.

तुम्ही BTRFS च्या वर BTRFS चालवल्यास, ते प्रथम कार्य करेल, परंतु एकदा नेस्टेड सबव्हॉल्यूम असल्यास, मूळ सबव्हॉल्यूम हटविणे अयशस्वी होईल. Device Mapper मॉड्यूलमध्ये नेमस्पेस नाही, त्यामुळे एकाच मशीनवर अनेक डॉकर उदाहरणे चालवत असल्यास, ते सर्व एकमेकांवर आणि कंटेनर बॅकअप डिव्हाइसेसवरील प्रतिमा पाहण्यास (आणि प्रभाव पाडण्यास) सक्षम असतील. हे वाईट आहे.

यापैकी अनेक समस्या सोडवण्यासाठी उपाय आहेत. उदाहरणार्थ, जर तुम्हाला अंतर्गत डॉकरमध्ये AUFS वापरायचे असेल, तर फक्त /var/lib/docker फोल्डरला व्हॉल्यूममध्ये बदला आणि तुम्ही ठीक व्हाल. डॉकरने डिव्हाइस मॅपर लक्ष्य नावांमध्ये काही बेस नेमस्पेस जोडल्या आहेत जेणेकरून एकाच मशीनवर अनेक डॉकर कॉल चालू असल्यास, ते एकमेकांवर पाऊल ठेवणार नाहीत.

तथापि, असे सेटअप अजिबात सोपे नाही, जे यावरून दिसून येते लेख GitHub वर dind भांडारात.

डॉकर-इन-डॉकर: ते खराब होते

बिल्ड कॅशे बद्दल काय? हे देखील खूप कठीण असू शकते. लोक मला नेहमी विचारतात "जर मी डॉकर-इन-डॉकर चालवत आहे, तर मी माझ्या अंतर्गत डॉकरमध्ये सर्वकाही परत खेचण्याऐवजी माझ्या होस्टवर होस्ट केलेल्या प्रतिमा कशा वापरू शकतो"?

काही उद्यमशील लोकांनी होस्टकडून /var/lib/docker ला डॉकर-इन-डॉकर कंटेनरशी बांधण्याचा प्रयत्न केला आहे. कधीकधी ते /var/lib/docker एकाधिक कंटेनरसह सामायिक करतात.

तुम्हाला तुमचा डेटा करप्ट करायचा आहे का? कारण यामुळेच तुमचा डेटा खराब होईल!

डॉकर डिमन स्पष्टपणे /var/lib/docker मध्ये विशेष प्रवेशासाठी डिझाइन केले होते. या फोल्डरमध्ये असलेल्या कोणत्याही डॉकर फायलींना इतर कशानेही "स्पर्श, पोक किंवा उत्पादन" करू नये.

हे असे का होते? कारण डॉटक्लाउड विकसित करताना शिकलेल्या कठीण धड्यांपैकी हा एक परिणाम आहे. डॉटक्लाउड कंटेनर इंजिन एकाच वेळी /var/lib/dotcloud मध्ये प्रवेश करणार्‍या अनेक प्रक्रिया करून चालले. अणु फाइल रिप्लेसमेंट (इन-प्लेस एडिटिंगऐवजी), सल्लागार आणि अनिवार्य लॉकसह पेपरिंग कोड आणि SQLite आणि BDB सारख्या सुरक्षित प्रणालींसह इतर प्रयोग यासारख्या धूर्त युक्त्या नेहमीच काम करत नाहीत. जेव्हा आम्ही आमचे कंटेनर इंजिन पुन्हा डिझाइन करत होतो, जे अखेरीस डॉकर बनले, तेव्हा सर्व कंटेनर ऑपरेशन्स एकाच डिमन अंतर्गत एकत्रित करणे हा एक मोठा डिझाईन निर्णय होता.

मला चुकीचे समजू नका: काहीतरी चांगले, विश्वासार्ह आणि जलद बनवणे पूर्णपणे शक्य आहे ज्यामध्ये अनेक प्रक्रिया आणि आधुनिक समांतर नियंत्रण समाविष्ट आहे. परंतु आम्हाला वाटते की डॉकर हा एकमेव खेळाडू म्हणून कोड लिहिणे आणि राखणे सोपे आणि सोपे आहे.

याचा अर्थ असा की तुम्ही /var/lib/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

हे डॉकर-इन-डॉकरसारखे दिसते आणि कार्य करते, परंतु ते डॉकर-इन-डॉकर नाही: जेव्हा हा कंटेनर अतिरिक्त कंटेनर तयार करतो, तेव्हा ते उच्च-स्तरीय डॉकरमध्ये तयार केले जातील. तुम्हाला नेस्टिंगचे दुष्परिणाम अनुभवणार नाहीत आणि असेंबली कॅशे एकाधिक कॉल्सवर सामायिक केले जाईल.

टीप: या लेखाच्या मागील आवृत्त्यांनी डॉकर बायनरी होस्टपासून कंटेनरशी जोडण्याचा सल्ला दिला होता. हे आता अविश्वसनीय बनले आहे कारण डॉकर इंजिन यापुढे स्थिर किंवा जवळ-स्थिर लायब्ररी कव्हर करत नाही.

तर, जर तुम्हाला जेनकिन्स सीआय वरून डॉकर वापरायचा असेल तर तुमच्याकडे 2 पर्याय आहेत:
डॉकर API वापरून मूलभूत प्रतिमा पॅकेजिंग प्रणाली वापरून डॉकर CLI स्थापित करणे (म्हणजे तुमची प्रतिमा डेबियनवर आधारित असल्यास, .deb पॅकेजेस वापरा).

काही जाहिराती 🙂

आमच्यासोबत राहिल्याबद्दल धन्यवाद. तुम्हाला आमचे लेख आवडतात का? अधिक मनोरंजक सामग्री पाहू इच्छिता? ऑर्डर देऊन किंवा मित्रांना शिफारस करून आम्हाला समर्थन द्या, $4.99 पासून विकसकांसाठी क्लाउड VPS, एंट्री-लेव्हल सर्व्हरचे एक अद्वितीय अॅनालॉग, जे तुमच्यासाठी आमच्याद्वारे शोधले गेले आहे: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps बद्दल संपूर्ण सत्य $19 पासून किंवा सर्व्हर कसा शेअर करायचा? (RAID1 आणि RAID10 सह उपलब्ध, 24 कोर पर्यंत आणि 40GB DDR4 पर्यंत).

डेल R730xd ऍमस्टरडॅममधील इक्विनिक्स टियर IV डेटा सेंटरमध्ये 2 पट स्वस्त? फक्त इथेच 2 x इंटेल टेट्राडेका-कोर 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 पासून! बद्दल वाचा इन्फ्रास्ट्रक्चर कॉर्पोरेशन कसे तयार करावे. डेल R730xd E5-2650 v4 सर्व्हरचा वापर करून 9000 युरो किमतीचा वर्ग?

स्त्रोत: www.habr.com