सवाल यदि कंटेनरों के पास कोई अतिथि ओएस नहीं है तो हम डॉकर के साथ ओएस बेस छवि का उपयोग क्यों करते हैं?


मैंने अभी डॉकर का अध्ययन करना शुरू कर दिया है और ऐसा कुछ है जो मेरे लिए काफी उलझन में है। जैसा कि मैंने डॉकर की वेबसाइट पर पढ़ा है, एक कंटेनर वर्चुअल मशीन से अलग है। जैसा कि मैंने एक कंटेनर समझा है, केवल एक सैंडबॉक्स है जिसमें से एक पूरी पृथक फाइल सिस्टम चलती है।

मैंने यह भी पढ़ा है कि एक कंटेनर में अतिथि ओएस इंस्टॉल नहीं है। इसके बजाय यह अंतर्निहित ओएस कर्नेल पर निर्भर करता है।

यह सब ठीक है। मैं उलझन में हूं कि ऑपरेटिंग सिस्टम के नाम पर डॉकर छवियां हैं। हम उबंटू, डेबियन, फेडोरा, सेंटोस और इसी तरह की छवियों को देखते हैं।

मेरा मुद्दा है: वास्तव में उन छवियों क्या हैं? वर्चुअल मशीन बनाने और डेबियन स्थापित करने से डेबियन छवि के आधार पर एक कंटेनर बनाना अलग कैसे है?

मैंने सोचा कि कंटेनरों के पास कोई अतिथि ओएस इंस्टॉल नहीं था, लेकिन जब हम छवियां बनाते हैं तो हम उन्हें एक ओएस के नाम पर नामित किसी छवि पर आधारित करते हैं।

इसके अलावा, उदाहरणों में मैंने देखा जब हम करते हैं docker run ubuntu echo "hello world", ऐसा लगता है कि हम उबंटू के साथ एक वीएम कताई कर रहे हैं और इसे कमांड बनाते हैं echo "hello world"

वैसे ही जब हम करते हैं docker run -it ubuntu /bin/bash, ऐसा लगता है कि हम उबंटू के साथ एक वीएम कताई कर रहे हैं और कमांड लाइन का उपयोग कर इसे एक्सेस कर रहे हैं।

वैसे भी, ऑपरेटिंग सिस्टम के बाद उन छवियों का नाम क्या है? उन छवियों में से एक के साथ एक कंटेनर चलाने और संबंधित अतिथि ओएस के साथ एक वीएम कताई कितना अलग है?

क्या यह विचार है कि हम केवल कर्नेल को मेजबान ओएस के साथ साझा करें (और इसके परिणामस्वरूप हमारे पास अंतर्निहित मशीन हार्डवेयर संसाधनों तक पहुंच है, हार्डवेयर को वर्चुअलाइज करने की आवश्यकता के बिना), लेकिन अभी भी जो भी एप्लिकेशन चाहते हैं उसका समर्थन करने के लिए कंटेनरों पर प्रत्येक अलग-अलग सिस्टम की फ़ाइलों और बाइनरी का उपयोग करें चलाने के लिए?


60
2018-02-11 16:39


मूल


मेरी राय में, वर्चुअलाइजेशन में आपके उद्देश्य कुंजी हैं। यदि आपको ओएस पर पुस्तकालयों, भाषाओं आदि की आवश्यकता है, तो ओएस कंटेनर आपकी ज़रूरत के अनुरूप हैं। लेकिन अगर आपकी आवश्यकता केवल घटक के रूप में आवेदन है, तो ओएस का उपयोग अपनी मूल छवि के रूप में करना आवश्यक नहीं है। मुझे लगता है कि यह आलेख इसे स्पष्ट रूप से समझा सकता है blog.risingstack.com/... - metamorph


जवाब:


चूंकि सभी लिनक्स वितरण एक ही चलाते हैं (yup, यह थोड़ा सा सरल है) लिनक्स कर्नेल और केवल उपयोगकर्तालैंड सॉफ़्टवेयर में भिन्न है, यह एक अलग वितरण वातावरण को अनुकरण करना बहुत आसान है - बस उस उपयोगकर्तालैंड सॉफ़्टवेयर को स्थापित करके और इसे एक और वितरण का नाटक करके। विशिष्ट होने के नाते, उबंटू ओएस के अंदर CentOS कंटेनर स्थापित करने का अर्थ यह होगा कि आपको सेंटोस से उपयोगकर्तालैंड मिल जाएगा, जबकि अभी भी एक ही कर्नेल चल रहा है, यहां तक ​​कि एक और कर्नेल उदाहरण भी नहीं।

इसलिए हल्के वर्चुअलाइजेशन एक ही ओएस के भीतर अलग डिब्बों की तरह है। एयू कॉन्ट्रैयर असली वर्चुअलाइजेशन में होस्ट ओएस के अंदर एक और पूर्ण ओएस है। यही कारण है कि डॉकर लिनक्स के अंदर फ्रीबीएसडी या विंडोज नहीं चला सकता है।

यदि यह आसान होगा, तो आप सोच सकते हैं कि डॉकर बहुत परिष्कृत और उन्नत क्रोट पर्यावरण है।


53
2018-02-11 17:15



तो यही कारण है कि मैं अपने संकलित गोलांग कोड को खाली स्क्रैच कंटेनर में होस्ट कर सकता हूं - क्योंकि संकलित कोड केवल कर्नेल की आवश्यकता है? - Francis Norton
तो अतिथि ओएस मेजबान ओएस 'कर्नेल (और ऐसा करने के लिए कैसे) का उपयोग करने के लिए जानता है? AFAIK, डॉकर छवि बेस मानक ओएस छवियों का उपयोग करें। आपके उदाहरण में, ऐसा नहीं है कि कस्टम सेंटोस बिल्ड है जो माता-पिता के कर्नेल का उपयोग करना जानता है? या यह एक फ़ाइल सिस्टम (औफ) चाल के रूप में सरल है जहां डॉकर मेहमानों ('CentOS') को होस्ट / बूट करने के लिए होस्ट (उबंटू) को रीडायरेक्ट करता है? उस स्थिति में, अतिथि (CentOS) अपनी बूट / बूट की अपनी प्रति स्थापित करेगा, लेकिन यह कभी पढ़ा नहीं जाएगा? - James S


कंटेनर एकल कर्नेल पर चलते हैं। दूसरे शब्दों में सभी कंटेनरों में एकल कर्नेल (होस्ट ओएस) होता है। जबकि दूसरी तरफ हाइपरवाइजर के पास कई कर्नल होते हैं। प्रत्येक आभासी मशीन विभिन्न कर्नेल पर चलती है।

और "डॉकर रन उबंटू" क्रोट पर्यावरण बनाने की तरह है।


1
2018-06-16 01:33