2017-03-02 21 views
7

उपयोग करने के लिए मैं डी लिखें और डी-झुंड के बीच मतभेद या समानता समझने की कोशिश कर रहा हूँ।जब डोकर-लिखें और उपयोग करने के लिए जब डोकर-झुंड

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

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

जो मैं समझने की कोशिश कर रहा हूं वह है डॉकर-स्वाद सफल डॉकर-कंपोज़ और ओवरले नेटवर्क कंटेनरों को जोड़ने के लिए नया (अनुशंसित) तरीका है?

या यह है कि डॉकर-कंपोज़ अभी भी पूरे डॉकर परिवार का एक अभिन्न अंग है और यह अपेक्षा की जाती है और कंटेनरों को सहयोग में काम करने के लिए इसका उपयोग करने की सलाह दी जाती है। यदि ऐसा है तो झुंड में विभिन्न नोड्स में कंटेनरों के साथ डॉकर-रचना काम करता है ??

या यह है कि ओवरले नेटवर्क स्विमर्स और डॉकर-कंपोज़ में विभिन्न होस्टों में कंटेनरों को जोड़ने के लिए आंतरिक लिंक बनाने के लिए है ??

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

मैं थोड़ा उलझन में हूँ ???

बहुत बहुत धन्यवाद!

+0

क्या कोई उत्तर आपके प्रश्न का समाधान नहीं है? यदि वे करते हैं, तो उनमें से एक को अपने उत्तर के रूप में स्वीकार करने के लिए चेक बॉक्स का चयन करें। – JoeG

उत्तर

2

मुझे लगता है कि आपके पास प्रत्येक समझ में सही समझ है, लेकिन कुछ ट्वीकिंग की आवश्यकता है।

आप सही डॉकर-कंपोज़ हैं जो बहु-कंटेनर अनुप्रयोगों को लाने के लिए हैं। इससे पहले आप प्रत्येक कंटेनर शुरू करने के लिए docker run .. करते थे। आमतौर पर माइक्रो-सर्विस प्रतिमान को गले लगाने वाले आधुनिक अनुप्रयोगों में दर्जनों सेवाओं का निर्माण किया जा सकता है और docker run .. का उपयोग करके बहुत जल्द ही थकाऊ हो जाएगा। इसलिए डॉकर-कंपोज़ आपको सभी कंटेनरों और उनकी गुणों को व्यक्त करने और yaml या json फ़ाइल के रूप में एक दूसरे से कनेक्ट करने की अनुमति देता है ताकि आप इसे एक आसान फैशन में प्रबंधित कर सकें।

तो, डॉकर-कंपोज़ डॉकर पारिस्थितिक तंत्र में कंटेनर ऑर्केस्ट्रेशन भाग है।

लिंक अलग वे सिर्फ डोकर-लिखें या docker run आदेशों का एक हिस्सा हैं और software defined networks के पक्ष में पदावनत कर रहे हैं जिनमें से overlay networks उनमें से सिर्फ एक कर रहे हैं,।

स्वर्ग डॉकर में शेड्यूलिंग घटक है। शेड्यूलिंग क्या है - यह पता लगाने के अलावा कुछ भी नहीं है कि डॉकर होस्ट के अपने समूह में अपने कंटेनर को "जगह" कहां रखा जाए। आपके पास सैकड़ों सर्वरों का समूह हो सकता है, और आपके पास सैकड़ों कंटेनर हो सकते हैं, प्रत्येक एक दर्जन विभिन्न अनुप्रयोगों के लिए एक सेवा को समाहित कर सकता है।अब इन कंटेनरों को सैकड़ों सर्वरों के अपने समूह में कैसे वितरित किया जाना चाहिए, क्या कुछ कंटेनरों को केवल कुछ होस्टों पर ही रखा जाना चाहिए क्योंकि वे किसी विशेष मानदंड को पूरा करते हैं या हो सकता है कि वे अन्य कंटेनरों के नजदीक हों (या नहीं) जो किसी भी तरह से संबंधित हैं ... ये सभी शेड्यूलिंग घटक का हिस्सा हैं जो डॉकर स्वार द्वारा किया जाता है।

मैं सुझाव है कि आप यहाँ docker.com पर मिलने लगे प्रलेखन के माध्यम से जाना: https://docs.docker.com/engine/getstarted-voting-app/

+0

बहुत बहुत धन्यवाद। मैंने वह ट्यूटोरियल किया था। मैं यह पता लगाने की कोशिश कर रहा हूं कि डॉकर डेवलपर्स द्वारा खुद की एक विशिष्ट सिफारिश है कि किस कंटेनर को निकटता से जोड़ने के लिए उपयोग की आवश्यकता है - ** लिखें ** या ** स्वर्म ओवरले नेटवर्क **। मेरे पास दुविधा यह है कि _network_ के माध्यम से कंटेनरों को जोड़ने का विचार उन्हें लिखने जैसा कुछ नहीं लगता है (या वे वही हैं ???)। क्या यह कंटेनर बाइंडिंग की तरह लिखता है ओवरले-नेटवर्क शैली कनेक्शन से अधिक सुरक्षित है? – Shabirmean

2

लिखें या झुंड या झुंड ओवरले नेटवर्क

आप पाते हैं कि आप सब उपयोग करने की आवश्यकता उपरोक्त यदि आप अपने लैपटॉप आदि पर डेमो के अलावा कुछ भी कर रहे हैं।

मैंने जानबूझकर & स्वार ओवरले नेटवर्क को अलग कर दिया, क्योंकि आपको दोनों का उपयोग करने की आवश्यकता नहीं है, लेकिन आप इसके नीचे एक झुंड के बिना ओवरले नेटवर्क नहीं प्राप्त कर सकते हैं।

लिखें कई कंटेनरों को एक साथ लाने के लिए है। अब यह समझ में आता है कि वे एक दूसरे से संबंधित हैं, हालांकि वे नहीं हो सकते हैं। लेकिन आइए मान लें कि एक ठेठ मामला जब कंटेनर एक दूसरे से संबंधित सेवाओं के लिए होते हैं, तो आप चाहते हैं कि वे किसी दूसरे से बात करें, लेकिन फिर भी यह नियंत्रित करें कि वे नेटवर्क का उपयोग करके एक-दूसरे से कैसे बात करते हैं। उदाहरण के लिए, एक 3 स्तरीय ऐप लें जिसमें एक वेबसर्वर, ऐससेवर और डीबी है। आइए मान लें कि सभी तीन घटकों को डॉकराइज्ड किया गया है और आप अलग-अलग पैरामीटर के साथ docker run.. तीन बार चलाने के बजाय उन्हें एक साथ लाने के लिए रचना का उपयोग कर रहे हैं। सभी तीन आएंगे, लेकिन आप यह नियंत्रित करना चाहते हैं कि वे एक दूसरे से कैसे जुड़ते हैं। आप चाहते हैं कि वेबसर्वर एप्सर्वर से बात करने में सक्षम हो, लेकिन डीबी को सीधे नहीं। और आप चाहते हैं कि ऐपसेवर डीबी सर्वर कंटेनर से बात करे (पिंग) और वेब सर्वर को पिंग भी करे। सभी कनेक्शन दो तरह से हैं, लेकिन केवल उन्हीं सेवाओं तक ही सीमित हैं जिन्हें आप एक दूसरे के साथ संवाद करने में सक्षम होना चाहते हैं। ऐसी व्यवस्था के लिए, आप आमतौर पर 2 नेटवर्क सेट करेंगे - frontend और backend कहें। वेब और ऐप कंटेनर फ्रंटेंड नेटवर्क से जुड़े हुए हैं। ऐप और डीबी कंटेनर बैकएंड नेटवर्क से जुड़े हुए हैं। चूंकि डीबी और वेब कंटेनरों के बीच कोई आम नेटवर्क नहीं है क्योंकि वे एक-दूसरे को छू नहीं सकते हैं, जो आपका इरादा है।

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

मुझे उम्मीद है कि यह स्पष्ट करता है।

संपादित करें: मैंने नहीं देखा कि आपको पहले से ही एक जवाब मिला है!

+0

धन्यवाद @ एनोप। तो मुझे लगता है कि यह सही है अगर मैं कहता हूं कि दोनों उपयोग लिखें और घुमाएं ** yaml ** आधारित सेवा विवरण सेवाओं को शुरू करने के लिए और दोनों इन सेवाओं को जोड़ने के लिए बनाए गए उपयोगकर्ता द्वारा परिभाषित नेटवर्क का उपयोग करें। केवल अंतर यह है कि एक एकल डॉकर-होस्ट पर चलने वाले कंटेनर के सेट के लिए रचना है और एक मल्टी होस्ट प्लेटफॉर्म के लिए झुंड है। – Shabirmean

+0

हां, लेकिन आप मिश्रण और मिलान कर सकते हैं, जिसका मतलब है - आप एक ही डोजर होस्ट के बजाय एक स्वैच्छ क्लस्टर को लक्षित करने के लिए एक ही रचना फ़ाइल का उपयोग कर सकते हैं। यह उस तरह से बेहद लचीला है। – Anoop

14

यह शायद कुछ परिभाषा के साथ शुरू करने के लिए मदद मिलेगी:

  • डोकर-रचना: कमान कॉन्फ़िगर और संबंधित कंटेनरों के एक समूह का प्रबंधन करने के लिए इस्तेमाल किया। यह डॉकर क्ली द्वारा उपयोग की जाने वाली वही एपीआई का एक अग्रभाग है, इसलिए आप docker run जैसे कमांड के साथ इसका व्यवहार पुन: पेश कर सकते हैं।
  • डॉकर-compose.yml: डॉकर-कंपोज़ द्वारा उपयोग किए जाने वाले कंटेनरों के समूह के लिए परिभाषा फ़ाइल और अब भी स्वार मोड द्वारा उपयोग की गई।
  • स्वार मोड: डॉकर इंजन के समूह को एक इकाई के रूप में प्रबंधित करने के लिए प्रयुक्त होता है और ऑर्केस्ट्रेशन प्रदान करता है (वर्तमान स्थिति और लक्ष्य स्थिति के बीच किसी भी अंतर को सही करने की कोशिश करता है)।
  • सेवा: एक ही छवि के लिए एक या अधिक कंटेनर और झुंड के भीतर कॉन्फ़िगरेशन, एकाधिक कंटेनर स्केलेबिलिटी प्रदान करते हैं।
  • स्टैक: एक झुंड के भीतर एक या अधिक सेवाएं, इन्हें डीएबी या डॉकर-कंपोज़.आईएमएल फ़ाइल का उपयोग करके परिभाषित किया जा सकता है।
  • पुल नेटवर्क: नेटवर्क एक एकल डॉकर इंजन द्वारा प्रबंधित किया जाता है जहां एकाधिक कंटेनर एक दूसरे के साथ संवाद कर सकते हैं। आपके पास इंजन द्वारा प्रबंधित कई नेटवर्क हो सकते हैं, और कंटेनरों को शून्य या अधिक नेटवर्क से जोड़ा जा सकता है।
  • ओवरले नेटवर्क: पुल नेटवर्क के समान लेकिन एकाधिक डॉकर इंजनों को फैला रहा है। इन्हें अपने राज्य को बनाए रखने के लिए एक कुंजी/मूल्य स्टोर की आवश्यकता होती है। स्वार मोड यह प्रदान करता है, लेकिन अगर झुंड मोड अक्षम है, तो आप आदि, कंसुल, या ज़ूकीपर का भी उपयोग कर सकते हैं।
  • लिंक: कंटेनरों को एक साथ जोड़ने के लिए एक विधि जो ब्रिज नेटवर्क को पूर्ववत करती है। इसका उपयोग अब अनुशंसित नहीं है।
  • क्लासिक झुंड: कंटेनर के रूप में चलने वाले एकीकृत स्विम मोड के पूर्ववर्ती, एकाधिक इंजनों को एक के रूप में प्रदर्शित करने की अनुमति देता है, लेकिन ऑर्केस्ट्रेशन प्रदान नहीं करता है या अपने स्वयं के के/वी स्टोर को शामिल नहीं करता है।

सवालों के जवाब देने के लिए:

डोकर-झुंड है सफल रहा डोकर-लिखें और ओवरले नेटवर्क नई (अनुशंसित) जिस तरह से कंटेनर कनेक्ट करने के लिए है?

या यह है कि डॉकर-कंपोज़ अभी भी पूरे डॉकर परिवार का एक अभिन्न अंग है और यह अपेक्षा की जाती है और कंटेनरों को सहयोग में काम करने के लिए इसका उपयोग करने की सलाह दी जाती है। यदि ऐसा है तो झुंड में विभिन्न नोड्स में कंटेनरों के साथ डॉकर-रचना काम करता है ??

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

या यह है कि ओवरले नेटवर्क स्विमर्स और डॉकर-कंपोज़ में विभिन्न होस्टों में कंटेनरों को जोड़ने के लिए आंतरिक लिंक बनाने के लिए है ??

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

yml फ़ाइल के संस्करण 2 के साथ शुरू करने वाला डॉकर-कम्पोज़ प्रति परियोजना एक नए ब्रिज नेटवर्क (प्रोजेक्ट नाम पर डिफ़ॉल्ट रूप से) के साथ डिफ़ॉल्ट रूप से एकाधिक कंटेनरों को जोड़ता है। क्लासिक झुंड के साथ, यह बाहरी के/वी स्टोर का उपयोग कर ओवरले नेटवर्क पर डिफ़ॉल्ट होगा। और एक झुंड मोड ढेर के साथ, यह एक ओवरले नेटवर्क होगा।

डॉकर नेटवर्क का उपयोग करना कंटेनर एक दूसरे के साथ संवाद करने का पसंदीदा तरीका है।आप उन कंटेनरों के प्रति समूह को नेटवर्क चाहते हैं जिन्हें आप अपने शेष डॉकर पर्यावरण से अलग करना चाहते हैं। डॉकर-कंपोज़ इस नेटवर्क निर्माण को स्वचालित करता है, लेकिन आप इसे docker networks create के साथ कमांड लाइन से भी कर सकते हैं।

लिंकिंग को बड़े पैमाने पर डॉकर नेटवर्क द्वारा प्रतिस्थापित किया गया है जिसमें अंतर्निहित DNS खोज है। जब आप अपने डॉकर-compose.yml से लिंक हटाते हैं, तो आपको कंटेनर स्टार्टअप ऑर्डर को लागू करने के लिए उन्हें depends_on सेक्शन के साथ प्रतिस्थापित करने की आवश्यकता हो सकती है। अन्यथा, बहुत कम परिदृश्य हैं जहां लिंकिंग समझ में आता है और मैंने जो भी उपयोग देखा है, वह पुराने दस्तावेज के बाद किसी से है।

संबंधित मुद्दे