थोड़ी देर के लिए डॉकर के साथ पढ़ने और खेलने के बाद, मैं इसे अपने उत्पादन वातावरण में उपयोग करने पर विचार कर रहा हूं । हालांकि मैं अभी भी माउंट बाइंड्स और वॉल्यूम के बीच के अंतर को समझने की कोशिश कर रहा हूं ।
माउंट बाइंड्स पर डॉकर्स प्रलेखन के अनुसार (https://docs.docker.com/storage/bind-mounts/):
डॉकर के शुरुआती दिनों से बाइंड माउंट आसपास रहे हैं । वॉल्यूम की तुलना में बाइंड माउंट में सीमित कार्यक्षमता होती है । जब आप बाइंड माउंट का उपयोग करते हैं, तो होस्ट मशीन पर एक फ़ाइल या निर्देशिका एक कंटेनर में घुड़सवार होती है । फ़ाइल या निर्देशिका को होस्ट मशीन पर इसके पूर्ण या सापेक्ष पथ द्वारा संदर्भित किया जाता है । इसके विपरीत, जब आप वॉल्यूम का उपयोग करते हैं, तो होस्ट मशीन पर डॉकर की स्टोरेज डायरेक्टरी के भीतर एक नई डायरेक्टरी बनाई जाती है, और डॉकर उस डायरेक्टरी की सामग्री को मैनेज करता है ।
इससे (और चारों ओर खेलने से) यह मुझे प्रतीत होता है कि माउंट बाइंड और वॉल्यूम एक ही चीज हैं, केवल अंतर डेटा का स्थान है । (डॉकर के "निजी" भंडारण क्षेत्र में संग्रहीत वॉल्यूम, जबकि माउंट बाइंड्स को कहीं भी संग्रहीत किया जा सकता है) । हां, डॉकर कंटेनर शुरू करने से पहले माउंट बाइंड का अस्तित्व होना चाहिए, जबकि कंटेनर शुरू होने पर डॉकर इंजन द्वारा वॉल्यूम बनाया जा सकता है - लेकिन यह अंतर अपरिवर्तनीय प्रदर्शन या रखरखाव के अनुसार है ।
मैं प्रलेखन द्वारा बताए गए संस्करणों के कथित लाभों को समझने में सक्षम नहीं था (https://docs.docker.com/storage/volumes/) जैसा कि वे सभी माउंट बाइंड्स पर लागू होते हैं ।
क्या कोई कृपया वॉल्यूम और माउंट-बाइंड्स (प्रदर्शन और रखरखाव के अनुसार) के बीच मुख्य अंतर और सबसे महत्वपूर्ण रूप से उनके उपयोग के मामलों की व्याख्या कर सकता है?
मदद के लिए धन्यवाद ।
डिफ़ॉल्ट रूप से, एक स्थानीय नामित वॉल्यूम ठीक वैसा ही है जैसा आप वर्णन करते हैं, एक विशेष डॉकर निर्देशिका में एक बाइंड माउंट । मैं जो अंतर देखता हूं:
सबसे पहले, बड़ा एक नामित वॉल्यूम और होस्ट वॉल्यूम (उर्फ बाइंड माउंट) के बीच एक व्यवहार अंतर है । डॉकर छवि की सामग्री से एक नामित वॉल्यूम प्रारंभ करेगा । इसमें फ़ाइल स्वामी और अनुमतियाँ शामिल हैं । इसका मतलब है कि आप उन अनुमति समस्याओं के बारे में चिंता करने से बच सकते हैं जो आमतौर पर होस्ट वॉल्यूम के साथ सामने आती हैं ।
दूसरा, पोर्टेबिलिटी। स्थानीय फाइल सिस्टम पथ या कमांड चलाने वाले उपयोगकर्ता के बारे में चिंता किए बिना नामित वॉल्यूम का उपयोग विभिन्न डॉकर होस्ट से किया जा सकता है । चाहे वह मैकओएस लैपटॉप पर हो, या उत्पादन में लिनक्स सर्वर पर हो, आप बस एक वॉल्यूम नाम दे सकते हैं और मान सकते हैं कि यह डिफ़ॉल्ट डॉकर इंस्टॉल के हिस्से के रूप में काम करेगा ।
तीसरा, वे कैसे प्रबंधित होते हैं । होस्ट वॉल्यूम आमतौर पर डॉकर के बाहर प्रबंधित होते हैं, जहां अनुमति की समस्याएं अक्सर खेल में आती हैं (क्योंकि होस्ट पर यूआईडी/जीआईडी आमतौर पर कंटेनर के अंदर यूआईडी/जीआईडी से मेल नहीं खाती है) । नामित वॉल्यूम के साथ, आप उन्हें किसी अन्य डॉकर कंटेनर के भीतर से प्रबंधित करेंगे जहां आप नियंत्रित कर सकते हैं कि कौन से उपकरण स्थापित हैं, उपयोगकर्ता बनाए गए हैं, आदि ।
नामित संस्करणों के साथ एक और बड़ा अंतर भी है । ऐसा इसलिए क्योंकि मैंने कहा "डिफ़ॉल्ट रूप से" ऊपर, और एक नामित वॉल्यूम काफी कुछ तरीकों से कॉन्फ़िगर किया जा सकता है । वॉल्यूम ड्राइवर को दूसरे में बदला जा सकता है जो क्लाउड अवेयर है । या आप स्थानीय वॉल्यूम ड्राइवर को स्थानीय बाइंड माउंट से एक विशिष्ट निर्देशिका में बदलने के लिए विकल्प पास कर सकते हैं जो आप माउंट सिस्कॉल के साथ कर सकते हैं । इसमें एक अलग निर्देशिका, एक एनएफएस माउंट के लिए एक बाइंड माउंट करना शामिल है, और आप कंटेनर को बेस लेयर में अंतर्निहित फ़ाइलों को बदले बिना कंटेनर के अंदर कुछ डेटा तक पहुंचने और संशोधित करने की अनुमति देने के लिए वॉल्यूम के रूप में अपना ओवरले फाइल सिस्टम भी बना सकते हैं ।
नामित वॉल्यूम का उपयोग करके, आप भंडारण के प्रबंधन को कंटेनरों के प्रबंधन से अलग भी कर सकते हैं । आप बस नाम को इंगित करते हैं और एक बाहरी उपकरण उस वातावरण में उपयुक्त स्थान को इंगित करने के लिए उस वॉल्यूम को बना सकता है ।
स्थानीय वॉल्यूम ड्राइवर के साथ मेरे द्वारा उपयोग किए गए नामित वॉल्यूम के कुछ उदाहरणों में शामिल हैं:
# named bind mount$ docker volume create --driver local \ --opt type=none \ --opt device=/home/user/test \ --opt o=bind \ test_vol# nfs$ docker volume create --driver local \ --opt type=nfs \ --opt o=nfsvers=4,addr=nfs.example.com,rw \ --opt device=:/path/to/dir \ foo# overlay$ docker volume create --driver local --opt type=overlay \ --opt o=lowerdir=${PWD}/ro-data,upperdir=${PWD}/upper1,workdir=${PWD}/work1 \ --opt device=overlay overlay1