क्या एक एकल "मास्टर" OpenVZ अतिथि बनाना संभव है जिसका उपयोग केवल पैकेज प्रबंधन के लिए किया जाएगा, और mount --bindकई अन्य OpenVZ मेहमानों की तरह कुछ का उपयोग करके उन्हें मास्टर अतिथि द्वारा स्थापित वातावरण का उपयोग करने के लिए छल करेगा?

इसका मतलब यह होगा कि उपयोगकर्ता अपने स्वयं के कंटेनरों को बनाए रख सकते हैं, और फिर भी मास्टर विकास वातावरण के साथ तालमेल बिठा सकते हैं, इसलिए सिस्टम प्रशासन के बारे में बहुत अधिक चिंता किए बिना उनके पास हमेशा नवीनतम और सबसे बड़ी आवश्यकताएं होंगी। यदि उन्हें अपने स्वयं के पैकेज स्थापित करने की आवश्यकता है, तो क्या उन्हें/ऑप्ट, या/usr/स्थानीय (या अपने होम निर्देशिका के लिए पथ सेट कर सकते हैं) में डाल सकते हैं?

पुनर्लेखन के लिए, मैं कई (डेवलपर, उदाहरण के लिए) OpenVZ अतिथि चाहूंगा जिनके /bin, /usr (और इसी तरह...) वास्तव में उसी डिस्क स्थान को संदर्भित करते हैं जो एक मास्टर OpenVZ अतिथि के रूप में है जिसे स्थापित करने के लिए शुरू किया जा सकता है और OpenVZ अतिथियों के इस समूह द्वारा साझा किए जाने वाले परिवेश के लिए सामान्य संकुल को अद्यतन करें।

इसके लायक क्या है, हम डेबियन 6 चला रहे हैं।

संपादित करें:

मैंने इस तरह से माउंटिंग (बाइंड, और रीडोनली) /bin, /lib, /sbin, /usr करने की कोशिश की है और यह यह कहते हुए कंटेनरों को शुरू करने से इनकार करता है कि फाइलें पहले से ही आरोहित हैं या अन्यथा उपयोग में हैं:

Starting container ...
vzquota : (error) Quota on syscall for id 1102: Device or resource busy
vzquota : (error)       Possible reasons:
vzquota : (error)       - Container's root is already mounted
vzquota : (error)       - there are opened files inside Container's private area
vzquota : (error)       - your current working directory is inside Container's
vzquota : (error)         private area
vzquota : (error)       Currently used file(s):
/var/lib/vz/private/1102/sbin
/var/lib/vz/private/1102/usr
/var/lib/vz/private/1102/lib
/var/lib/vz/private/1102/bin
vzquota on failed [3]

अगर मैं इन चार खंडों को अनमाउंट करता हूं, और अतिथि को शुरू करता हूं, और फिर अतिथि के शुरू होने के बाद उन्हें माउंट करता हूं, तो अतिथि उन्हें कभी भी माउंट नहीं देखता।

answer

टिप्पणियों के आधार पर, प्रश्न मैं (और शायद अन्य) की अपेक्षा से थोड़ा अलग है: "रखरखाव" का उपयोग कंटेनरों के भीतर पैकेज से संबंधित नहीं है, बल्कि उनकी व्यक्तिगत कॉन्फ़िगरेशन से संबंधित है।

यह प्रक्रिया को और अधिक कठिन बनाता है, लेकिन फिर भी संभव है। उदाहरण के लिए:

निर्देशिकाओं को माउंट करना

जैसा कि आपने कहा है, आपको बायनेरिज़ के लिए एक माउंट साझा /usr/binकरना होगा (जैसे ) जो यह सुनिश्चित करने में पहला कदम होगा कि वे सभी पैकेज साझा कर सकते हैं - यह स्थापित बायनेरिज़ को सभी के लिए आसानी से उपलब्ध होने की अनुमति देगा। अन्य कंटेनर।

आपको यह सुनिश्चित करने की आवश्यकता है कि जब आप mount --bind- आप इसे ROOTअपनी उपयुक्त /etc/vz/<veid>.confफ़ाइल में निर्देशिका पर करते हैं

उदाहरण के लिए, mount --bind /some/mount/point/bin /vz/root/1/bin

यह भी आवश्यक है कि ये माउंट साफ हों (मशीन के पहली बार बूट होने के बाद आप कैसे सुनिश्चित करें कि वे वहां हैं?) ऐसा करने के लिए, OpenVZ स्क्रिप्ट के रूप में स्टार्ट और स्टॉप हुक प्रदान करता है। यह मानते हुए कि आप भीतर काम कर रहे हैं /etc/vz/conf, आपके पास हो सकता है:

  • /etc/vz/conf/<veid>.mount - यह स्टार्ट हुक है: कंटेनर के चलने के बाद कॉल किया जाता है
  • /etc/vz/conf/<veid>.umount - यह स्टॉप हुक है: कंटेनर के बंद होने के बाद कॉल किया जाता है

उनके नाम उनकी तकनीकी परिभाषाओं से प्राप्त हुए हैं: OpenVZ माउंट करता /vz/private/<veid>है /vz/root/<veid>ताकि यह वही है जो इसे हुक कर रहा है (डिफ़ॉल्ट निर्देशिका मानते हुए)।

विन्यास

टिप्पणियों में, आपने पूछा है कि एक फायदा यह होगा कि वे अपने सर्वर को अपनी पसंद के अनुसार कॉन्फ़िगर कर सकते हैं (जैसे mysql.cnfया httpd.conf/ apache2.conf)। इसके साथ एकमात्र समस्या जो मैं देख सकता था, वह यह है कि आपको यह सुनिश्चित करने की आवश्यकता है कि जब आप पैकेज स्थापित करते हैं, तो ये कॉन्फ़िगरेशन फ़ाइलें प्रत्येक कंटेनर के अंदर सेट की जाती हैं। आप राइट शेयर पर माउंट कॉपी साझा करने का प्रयास कर सकते हैं

इसके साथ मुद्दा यह है कि कौन सी निर्देशिका साझा की जाए। इसे अपाचे पर /etc/httpdऔर MySQL पर /etc/mysql- इसलिए आपको यह सुनिश्चित करने की ज़रूरत है कि आप इन स्टॉक फ़ाइलों की प्रतिलिपि बनाते हैं या यह विचार काम नहीं करेगा। व्यक्तिगत रूप से मैं .debआपके 'वैश्विक' पैकेज व्यवस्थापक द्वारा स्थापित फ़ाइलों का निरीक्षण करता हूं , और व्यक्तिगत कंटेनरों में साझा नहीं की गई किसी भी निर्देशिका को निकालता हूं लेकिन, यह करने का यह सिर्फ एक ही तरीका है - मुझे यकीन है कि कुछ और भी हैं।

गोचास

एक बात जो मैं लेकर आया हूं वह यह है कि आप पैकेज के साथ आने वाले बायनेरिज़ और लाइब्रेरी को सीधे बदल सकते हैं, लेकिन आपको यह देखने की ज़रूरत है कि पैकेज मैनेजर इसे स्थापित करने के बाद सेवाओं को पुनरारंभ करता है या नहीं

आपकी पोस्ट में त्रुटि

आप बढ़ते जा रहे हैं private, आपको /var/lib/vz/root/1102/binनिर्देशिका पर माउंट करने की आवश्यकता है (यह मानते हुए कि रूट आपकी vz की .confफ़ाइल में इंगित करता है)।

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

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

जब उपयोगकर्ता नवीनतम संस्करण चाहता है, तो आपको अपने अपडेट किए गए टेम्पलेट का उपयोग करके उनकी सीटी को फिर से बनाना चाहिए। हर बार जब आप अपग्रेड करते हैं, तो आप इसे सीटी टेम्पलेट के रूप में सहेज सकते हैं। यह उनके सिस्टम को स्थिर रखता है, लेकिन वे किसी भी समय अपग्रेड के लिए कह सकते हैं।