लिनक्स पर विस्तार से कंटेनरकरण - LXC और OpenVZ। भाग 1

OpenVZ क्या है?

OpenVZ विकास इतिहास

• RHEL4 के लिए OpenVZ (EOL द्वारा बंद)
• RHV5 के लिए OpenVZ
• RHEL6 के लिए OpenVZ
• RHEL7 के लिए OpenVZ (अभी भी लिखित रूप में)

लिनक्स अपस्ट्रीम कंटेनर डेवलपमेंट हिस्ट्री

कंटेनर अलगाव सबसिस्टम का तकनीकी कार्यान्वयन

1. आप विभिन्न लिनक्स उपयोगकर्ताओं से एप्लिकेशन चला सकते हैं। इस प्रकार, पड़ोसी एप्लिकेशन की फाइल सिस्टम सुरक्षा को विशेष रूप से लिनक्स फाइलों और फ़ोल्डरों के अधिकारों की प्रणाली द्वारा नियंत्रित किया जाएगा, और यदि कॉन्फ़िगरेशन गलत है, तो फाइलों से समझौता करना संभव हो सकता है। साथ ही, भौतिक सर्वर की सभी सेवा फाइलें दोनों अनुप्रयोगों के लिए उपलब्ध होंगी, जिससे डेटा रिसाव और संपूर्ण प्रणाली के बाद का समझौता भी हो सकता है। यह विधि सभी समस्याओं को हल नहीं करती है और आपको कुछ और उन्नत करने की आवश्यकता है।
2. फ़ाइल सिस्टम की सुरक्षा बढ़ाने के लिए, हम चेरोट कार्यक्षमता का उपयोग करने की कोशिश करेंगे, जो आपको एक विशिष्ट फ़ोल्डर के अंदर प्रक्रिया को "लॉक" करने की अनुमति देता है, जिससे इसे बाहर निकालना बहुत मुश्किल होगा। ऐसा करने के लिए, हमें प्रत्येक एप्लिकेशन के लिए सिस्टम फ़ाइलों (उदाहरण के लिए, डीबूटस्ट्रैप के माध्यम से) का एक पूरा सेट बनाने और उन्हें अलग फ़ाइल पदानुक्रम में डालने की आवश्यकता है। इस प्रकार, प्रत्येक एप्लिकेशन की अपनी फ़ाइल पदानुक्रम होगी जो किसी मित्र के साथ प्रतिच्छेद नहीं करती है। लेकिन अगर चेरोट के अंदर की प्रक्रिया रूट उपयोगकर्ता के रूप में चलती है (और इस तरह की कुछ प्रक्रियाएं हैं), तो मानक तंत्र (मल्टीपल चेरोट) का उपयोग करते हुए, वह चेरोट से बाहर निकलने में सक्षम होगा और भौतिक सर्वर के फाइल सिस्टम में प्रवेश करेगा, जो निश्चित रूप से अनुमेय नहीं है। यह विकल्प भी हमें पसंद नहीं है।
3. चेरोट लिनक्स के अलावा, लिनक्स माउंट नेमस्पेस सबसिस्टम बहुत लंबे समय से अस्तित्व में है, जो व्यापक कार्यक्षमता प्रदान करता है, लेकिन पूरी सुरक्षा के साथ कि आप इससे बच नहीं सकते। यह वह है जो कंटेनरीकरण में उपयोग किया जाता है। चूंकि हमारे कार्यों का विस्तार से वर्णन करने के लिए सी कोड का वर्णन किए बिना यह संभव नहीं होगा, इसलिए मैं खुद को उनके औपचारिक विवरण तक सीमित कर दूंगा। इसलिए, हमने साधारण फ़ाइल सिस्टम की अलगाव समस्याओं को हल किया है।
4. अब मान लें कि प्रत्येक एप्लिकेशन एक निश्चित पोर्ट का उपयोग करता है, उदाहरण के लिए, 443 वां। यदि सर्वर पर केवल 1 IP पता है और उसे किसी भौतिक सर्वर से जोड़ा गया है तो हमें क्या करना चाहिए? बेशक, पहले हमें दो अतिरिक्त आईपी पते की आवश्यकता है, प्रत्येक सेवा के लिए एक। हमें दोनों को एक भौतिक सर्वर पर असाइन करना होगा और प्रत्येक एप्लिकेशन के लिए कॉन्फ़िगर करना होगा ताकि वह स्पष्ट रूप से इसके आईपी पते को सुन सके। लेकिन क्या होगा अगर कोई एप्लिकेशन हैक हो जाए और एक्सेस से समझौता करने के लिए किसी फिजिकल सर्वर के आईपी या पड़ोसी के आईपी पर पोर्ट सुनना शुरू कर दे? वह सफल होगा और कोई भी उसे ऐसा करने से नहीं रोकेगा। इससे कैसे निपटें? यहां नेमस्पेस हमें फिर से मदद करेगा - अर्थात्, नेटवर्क नेमस्पेस जिसके माध्यम से प्रत्येक कंटेनर (शायद उन्हें पहले से ही इस तरह से बुलाया जा सकता है!) एक सख्ती से तय आईपी पते (और साथ ही सॉकेट्स, पोर्ट्स और एक रूटिंग टेबल का स्थान) हो जाता है। यह पड़ोसी से सॉकेट, आईपी पते और पोर्ट स्तर पर पूर्ण अलगाव सुनिश्चित करेगा। अब कोई आपसी प्रभाव संभव नहीं है।
5. और अब चलो प्रक्रियाओं के जंगल में थोड़ा सा जाएं और याद रखें कि, उदाहरण के लिए, अपाचे वेब सर्वर बहुत सक्रिय रूप से सेमाफोर का उपयोग करता है, और PHP एपीसी ओपकोड त्वरक बहुत बार शम मेमोरी का उपयोग करता है। यदि कोई प्रक्रिया हाँ में लेती है और पड़ोसी की स्मृति को साफ कर देती है, तो उसे क्या होता है? या इसे पढ़ें और कोई संवेदनशील डेटा निकालें? एक स्पष्ट रूप से अप्रिय घटना जो कुछ भी नहीं करने के लिए हमारे सभी चाल को कम कर देती है। लेकिन एक समाधान है - IPC नाम स्थान, जो IPC और IPC Sys V के लिए सेमीफॉरेस, कतारों, म्यूटेक्स, अलग-थलग मेमोरी को अलग करता है, जिसमें प्रत्येक कंटेनर केवल अपने IPC संसाधनों को देखता है और कोई नहीं। हुर्रे! समस्या हल हो गई है।
6. इस स्तर पर, हमारे साथ लगभग सब कुछ ठीक है, लेकिन समस्या यह है कि कंटेनर से हम भौतिक सर्वर की सभी प्रक्रियाओं, साथ ही साथ पड़ोसी की प्रक्रियाओं को देखते हैं। अक्सर प्रक्रियाएं उनके नामों में पासवर्ड या अन्य महत्वपूर्ण जानकारी प्रकट करती हैं, इसलिए यह संभावना बेहद अवांछनीय है। इसके अलावा, यदि हम एक निश्चित पीआईडी ​​के साथ एक प्रक्रिया शुरू करना चाहते हैं जो पहले से ही एक पड़ोसी कंटेनर या होस्ट सिस्टम द्वारा कब्जा कर ली गई है, तो यह काम नहीं करेगा, क्योंकि लिनक्स को सभी प्रक्रियाओं के लिए एक अद्वितीय पीआईडी ​​की आवश्यकता होती है। इस व्यवहार से छुटकारा पाने के लिए, हम पीआईडी ​​नामस्थान का उपयोग करेंगे, जो प्रत्येक कंटेनर के लिए पूरी तरह से अलग (भौतिक सर्वर से और पड़ोसी से) पीआईडी ​​नंबरिंग सिस्टम बनाएगा, जो बदले में इसे शुरू करना संभव बनाता है, उदाहरण के लिए, पीआईडी ​​के साथ कई प्रक्रियाएं 1. स्टॉप और स्टॉप के बराबर होती हैं। किस लिनक्स प्रक्रिया में ऐसा PID है? यह सही है, init! हमारे "स्व-निर्मित अलगाव" में हम उस चरण में पहुँच गए जब हम एक पूर्ण प्रणाली शुरू कर सकते हैं, और कंटेनर के अंदर सिर्फ 1 प्रक्रिया नहीं! हुर्रे!
7. लेकिन कंटेनर में पूर्ण विकसित लिनक्स लॉन्च करने में हमारी खुशी अधूरी रह जाएगी, क्योंकि दोनों कंटेनरों पर होस्टनाम भौतिक सर्वर के होस्टनाम के साथ मेल खाएंगे, उदाहरण के लिए, ssh पर काम करते समय अप्रिय परिणाम हो सकते हैं, और बहुत सारे सॉफ़्टवेयर होस्टनाम सही हैं और मेल खाते हैं मशीन का आईपी पता। इसे अलग-थलग करने की भी आवश्यकता है, यह एक नाम स्थान के साथ एक बहुत ही गैर-सहज नाम - यूटीएस के साथ किया जाता है, जो आपको प्रत्येक कंटेनर को अपने स्वयं के अनूठे होस्टनाम पर सेट करने की अनुमति देता है।

• पर्वत
• नेटवर्क
• पीआईडी
• UTS
• भारतीय दंड संहिता

अगली कड़ी में क्या उम्मीद करें?

• कंटेनर हार्डवेयर संसाधन की तकनीकी कार्यान्वयन सबसिस्टम को सीमित करता है
• कंटेनर का उपयोग करते समय सामान्य समस्याएं
• OpenVZ का लाभ मानक लिनक्स कंटेनरीकरण से अधिक है
• उपयोगकर्ता स्थान से समस्या
• निष्कर्ष