सिफारिश ऑपरेटिंग-सिस्टम-स्तरीय वर्चुअलाइजेशन के लक्ष्य और डिजाइन से आती है
कंटेनर यह अपने आप ही देकर दूसरों के लिए एक प्रक्रिया को अलग करने के लिए डिजाइन किया गया है यूज़रस्पेस और फाइल सिस्टम।
यह तार्किक विकास है, chrootजो एक पृथक फाइल सिस्टम प्रदान कर रहा था, अगला चरण मेमोरी ओवरराइट से बचने के लिए दूसरों से प्रक्रियाओं को अलग कर रहा था और संघर्ष के बिना कई प्रक्रियाओं से समान संसाधन (उदाहरण के लिए टीसीपी पोर्ट 8080) का उपयोग करने की अनुमति देता था।
संस्करण संघर्षों की चिंता किए बिना प्रक्रिया के लिए आवश्यक लाइब्रेरी को पैकेज करने के लिए एक कंटेनर में मुख्य रुचि। यदि आप एक ही लाइब्रेरी के दो संस्करणों की जरूरत के लिए एक ही यूजरस्पेस और फाइल सिस्टम में मल्टीपल प्रोसेस चलाते हैं, तो आपको प्रत्येक प्रक्रिया के लिए कम से कम LDPATH को ट्विक करना होगा, ताकि उचित लाइब्रेरी पहले मिल जाए, और कुछ लाइब्रेरी को इस तरह से ट्वीक नहीं किया जा सकता है। क्योंकि संकलन के समय निष्पादन योग्य में उनका मार्ग कठिन है, इसलिए अधिक विवरण के लिए यह SO प्रश्न देखें।
नेटवर्क स्तर पर आपको समान पोर्ट का उपयोग करने से बचने के लिए प्रत्येक प्रक्रिया को कॉन्फ़िगर करना होगा।
एक ही कंटेनर में कई प्रक्रियाओं को चलाने के लिए कुछ भारी ट्विकिंग की आवश्यकता होती है और दिन के अंत में अलगाव के उद्देश्य को पराजित किया जाता है, यदि आप एक ही यूज़रस्पेस के भीतर मल्टीपल प्रोसेस को चलाने के लिए ठीक हैं, तो एक ही फाइलसिथम और नेटवर्क संसाधनों को साझा करना, फिर उन्हें चलाना क्यों नहीं मेजबान पर ही?
यहाँ मैं सोच सकता हूँ कि भारी ट्विकिंग / नुकसान की गैर थकाऊ सूची है:
लॉग को संभालना
या तो एक घुड़सवार मात्रा के साथ या stdout पर interleaved होने के नाते यह कुछ प्रबंधन लाता है। यदि एक माउंटेड वॉल्यूम का उपयोग करते हुए आपके कंटेनर में होस्ट पर "स्थान" होना चाहिए या दो ही कंटेनर एक ही संसाधन के लिए लड़ेंगे। जब इसका लाभ उठाने के लिए स्टडआउट पर इंटरलेइंग करना docker logsविश्लेषण के लिए एक बुरा सपना बन सकता है अगर स्रोतों को आसानी से पहचाना नहीं जा सकता है।
ज़ोंबी प्रक्रियाओं से सावधान रहें
यदि कंटेनर क्रैश में आपकी कोई प्रक्रिया होती है, तो हो सकता है कि पर्यवेक्षक ज़ोंबी स्थिति में चिल्ड को साफ करने में सक्षम न हो, और मेजबान इनिट कभी भी उन्हें विरासत में नहीं मिलेगा। एक बार जब आप उपलब्ध pids की संख्या को समाप्त कर लेते हैं (2 ^ 22 तो लगभग 4 लाख) चीजों का एक गुच्छा विफल हो जाएगा।
चिंताओ का विभाजन
यदि आप दो अलग-अलग चीजों को चलाते हैं, जैसे एक अपाचे सर्वर और उसी कंटेनर के भीतर लॉगस्टैश, जो लॉग हैंडलिंग को कम कर सकता है, लेकिन आपको लॉगस्टैश को अपडेट करने के लिए अपाचे को बंद करना होगा। (वास्तव में, आपको डॉकिंग के लॉगिंग ड्राइवर का उपयोग करना चाहिए) क्या यह वर्तमान सत्रों के समाप्त होने या नहीं होने की प्रतीक्षा करने वाला एक सुंदर पड़ाव होगा? यदि यह एक सुंदर पड़ाव है, तो इसमें कुछ समय लग सकता है और नए संस्करण को रोल करने के लिए लंबा हो सकता है। यदि आप मारते हैं, तो आप उपयोगकर्ताओं को एक लॉग शिपर के लिए प्रभावित करेंगे और उसे IMHO से बचना चाहिए।
अंत में जब आपके पास कई प्रक्रियाएं होती हैं, तो आप एक ओएस को पुन: पेश कर रहे हैं, और इस मामले में हार्डवेयर वर्चुअलाइजेशन का उपयोग करके इस आवश्यकता के अनुरूप अधिक लगता है।