वयस्क कंटेनर (भाग 02): शब्दावली के लिए एक व्यावहारिक गाइड

कई कंटेनर बिल्डिंग टेम्प्लेट हैं। एक कंटेनर अपनी छवि का सिर्फ एक निष्पादन योग्य संस्करण है। इसलिए, कंटेनर बनाने का तरीका बारीकी से संबंधित है कि यह कैसे शुरू होता है।

कुछ कंटेनर छवियां बिना किसी विशेष विशेषाधिकार के ठीक काम करती हैं, कुछ को विशेषाधिकारों की आवश्यकता होती है। इसके अलावा, एक ही छवि / कंटेनर कई निर्माण पैटर्न और उपयोग परिदृश्यों को एक साथ जोड़ सकते हैं।



नीचे हम सबसे आम कंटेनर उपयोग मामलों पर विचार करेंगे।

(कंटेनर शब्दावली के लिए एक परिचय के लिए, भाग एक देखें)

कंटेनर उपयोग परिदृश्य

अनुप्रयोग कंटेनर

अनुप्रयोग कंटेनर कंटेनर के सबसे सामान्य प्रकार हैं। डेवलपर्स और एप्लिकेशन के मालिक उन्हें संभालते हैं, और वे स्वयं सोर्स कोड, प्लस चीजें जैसे MySQL, Apache, MongoDB और Node.js.

अनुप्रयोग कंटेनरों का एक विशाल पारिस्थितिकी तंत्र बनाया जा रहा है। सॉफ़्टवेयर संग्रह जैसी परियोजनाएँ Red Hat Enterprise Linux के लिए सुरक्षित और समर्थित अनुप्रयोग कंटेनर चित्र प्रदान करती हैं। इसी समय, Red Hat समुदाय के सदस्य नवीन अनुप्रयोग कंटेनरों का विकास और समर्थन कर रहे हैं।

Red Hat में, हम मानते हैं कि एप्लिकेशन कंटेनरों को आमतौर पर विशेष विशेषाधिकारों की आवश्यकता नहीं होती है। हालांकि, कंटेनर उत्पादन वातावरण का निर्माण करते समय, अन्य कंटेनरों की आवश्यकता होती है।

ऑपरेटिंग सिस्टम कंटेनर

ऑपरेटिंग सिस्टम का कंटेनर एक ऐसा कंटेनर होता है जो बहुत कुछ एक पूर्ण वर्चुअल OS जैसा दिखता है। ऐसे कंटेनर मेजबान कर्नेल का भी उपयोग करते हैं, लेकिन पूर्ण init सिस्टम चलाते हैं, जो उन्हें कई प्रक्रियाओं को आसानी से निष्पादित करने की अनुमति देता है। ऑपरेटिंग सिस्टम कंटेनरों के उदाहरण LXC और LXD हैं।

ऑपरेटिंग सिस्टम के कंटेनर, सिद्धांत रूप में, docker / OCI कंटेनरों का उपयोग करके अनुकरण किया जा सकता है, बशर्ते कि आप उनके अंदर सिस्टम को चला सकें, ताकि अंतिम उपयोगकर्ता सामान्य तरीके से ऐसे कंटेनरों के अंदर सॉफ़्टवेयर स्थापित कर सके और उन्हें पूर्ण-आभासी वर्चुअल OS के रूप में मान सके।

yum install mysql systemctl enable mysql 

यह मौजूदा अनुप्रयोगों के कंटेनरीकरण को बहुत सरल करता है। रेड हैट ऑपरेटिंग सिस्टम कंटेनरों को सरल बनाने के लिए कड़ी मेहनत कर रहा है, ताकि सिस्टम कंटेनर के अंदर चले और मशीनी डैम का उपयोग कर सके। हालांकि कई ग्राहक अभी तक माइक्रोसॉर्फ़ आर्किटेक्चर के लिए तैयार नहीं हैं, फिर भी कंटेनर छवियों के आधार पर एक कंटेनरीकृत सॉफ़्टवेयर डिलीवरी मॉडल में संक्रमण अभी भी उन्हें बहुत सारे फायदे दे सकता है।

पालतू कंटेनर

हालाँकि, Red Hat नए अनुप्रयोगों को विकसित करते समय क्लाउड-आधारित टेम्प्लेट के उपयोग की दृढ़ता से अनुशंसा करता है, प्रचार करता है और समर्थन करता है, हम अच्छी तरह से जानते हैं कि इस तरह से सभी मौजूदा अनुप्रयोगों को फिर से नहीं लिखा जाएगा। विशेष रूप से, क्योंकि उनमें से कई के साथ विशेष अनुप्रयोगों का ज्यादा पालतू जानवर (की तरह लग रहे तुलना कि इतने अद्वितीय और अनोखी हैं, पालतू जानवर गायों के झुंड की पृष्ठभूमि के खिलाफ)। यह ऐसे अनुप्रयोगों के लिए है जो विशेष पालतू कंटेनरों को डिज़ाइन किए गए हैं।

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

सुपर प्रिविलेज कंटेनर

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

कंटेनरों को चलाने के लिए बनाए गए बुनियादी ढांचे में, प्रशासकों को निगरानी, ​​बैक अप आदि जैसे कार्य करने के लिए SPC कंटेनरों की आवश्यकता होती है, यह समझना महत्वपूर्ण है कि चूंकि SPC कंटेनर आमतौर पर मेजबान कोर से बहुत अधिक जुड़े होते हैं, इसलिए प्रशासकों को चाहिए होस्ट ऑपरेटिंग सिस्टम को चुनते समय, विशेष रूप से बड़े संकुल और वितरित वातावरणों में विश्वसनीयता और मानकीकरण के मुद्दों पर विशेष ध्यान दें जो समस्या निवारण को कठिन बनाते हैं। इसके अलावा, प्रशासकों को यह सुनिश्चित करने की आवश्यकता है कि SPC के भीतर उपयोगकर्ता स्थान होस्ट कोर के साथ संगत है।

उपकरण और सिस्टम सॉफ्टवेयर

लिनक्स वितरण ने हमेशा उपयोगकर्ता को सिस्टम सॉफ़्टवेयर के साथ प्रदान किया, जैसे कि रूपलॉग, SSSD, sadc, आदि। परंपरागत रूप से, यह सॉफ्टवेयर RPM या DEB पैकेज के रूप में स्थापित किया गया था, लेकिन कंटेनर पैकेजिंग प्रारूपों के आगमन के साथ कंटेनर चित्रों का उपयोग करना आसान और अधिक सुविधाजनक हो गया। विशेष रूप से, रेड हैट रेडी वर्चुअलाइजेशन टूल, rsyslog, sssd, और sadc जैसे रेडी-मेड कंटेनर जैसी चीजें प्रदान करता है।

कंटेनर वास्तुकला

जैसा कि कंटेनरीकृत सॉफ्टवेयर वितरण गति प्राप्त कर रहा है, नए कंटेनर डिजाइन पैटर्न उभर रहे हैं। इस खंड में हम उनमें से कुछ के बारे में बात करेंगे।

जिस तरह से कंटेनर को डिस्क पर सहेजा जाता है (दूसरे शब्दों में, छवि का प्रारूप) बहुत प्रभावित कर सकता है कि यह कैसे शुरू होता है। उदाहरण के लिए, sssd को चलाने के लिए तैयार कंटेनर में हर बार शुरू होने वाले विशेष विशेषाधिकार होने चाहिए, अन्यथा यह अपना काम करने में सक्षम नहीं होगा। नीचे, हम मुख्य पैटर्न पर विचार करते हैं जो वर्तमान में सक्रिय गठन के चरण से गुजर रहे हैं।

आवेदन छवियों

यह इन चित्रों के साथ है जो उपयोगकर्ताओं को समाप्त करते हैं। ऐसी छवियों का उपयोग करने के लिए परिदृश्य DBMS और वेब सर्वर से व्यक्तिगत अनुप्रयोगों और सेवा बसों तक होते हैं। ये चित्र संगठन द्वारा आंतरिक रूप से बनाए जा सकते हैं या सॉफ़्टवेयर विक्रेताओं द्वारा प्रदान किए जा सकते हैं। इसलिए, अंत उपयोगकर्ता अक्सर ऐसे स्वायत्त कंटेनरों की सामग्री को सावधानी और सफाई के साथ संबंधित करते हैं। इसके अलावा, हालांकि यह कंटेनरों के अंतिम-उपयोगकर्ता के लिए सबसे आसान विकल्प है, स्टैंड-अलोन छवियां डिजाइन, निर्माण और पैच के लिए बहुत अधिक कठिन हैं।

मूल चित्र

एक मूल छवि सबसे सरल प्रकार की छवियों में से एक है। हालांकि, लोग इस शब्द को कई प्रकार की चीजों के साथ निरूपित कर सकते हैं, उदाहरण के लिए, एक मानक कॉर्पोरेट असेंबली या यहां तक ​​कि एक एप्लीकेशन इमेज भी। हालांकि, सख्ती से बोलना, ये बुनियादी नहीं हैं, लेकिन मध्यवर्ती छवियां हैं।
तो बस यह स्पष्ट कर दें कि आधार छवि एक ऐसी छवि है जिसमें माता-पिता की परत नहीं है। बुनियादी छवियों में आमतौर पर ओएस की एक साफ प्रतिलिपि होती है, साथ ही सॉफ़्टवेयर पैकेज स्थापित करने या बाद में छवि को अपडेट करने के लिए आवश्यक उपकरण (yum, rpm, apt-get, dnf, microdnf)। मूल उपयोगकर्ता मैन्युअल रूप से अंतिम उपयोगकर्ता द्वारा एकत्र किए जा सकते हैं, लेकिन व्यवहार में वे आमतौर पर विकास समुदायों (जैसे डेबियन, फेडोरा या सेंटोस) या सॉफ़्टवेयर विक्रेताओं (जैसे रेड हैट) द्वारा बनाए और जारी किए जाते हैं। आधार छवि की उत्पत्ति सुरक्षा के लिए महत्वपूर्ण है। सारांशित करना, मूल छवि का मुख्य और एकमात्र उद्देश्य एक आधार प्रदान करना है जिसके आधार पर आप अपने बच्चे की छवियां बना सकते हैं। डॉकफाइल का उपयोग करते समय, अंतर्निहित आधार छवि का चयन स्पष्ट रूप से किया जाता है:

 FROM registry.access.redhat.com/rhel7-atomic 

बिल्डर छवियाँ

यह एक विशेष प्रकार की छवि है, जिसके आधार पर एप्लिकेशन कंटेनरों की बाल छवियां बनाई जाती हैं। बिल्डर छवियों में डेवलपर्स द्वारा लिखित स्रोत कोड को छोड़कर सब कुछ शामिल है, अर्थात् ओएस लाइब्रेरी, भाषा रनटाइम, मिडलवेयर और सोर्स-टू-इमेज टूल।

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

मान लीजिए कि डेवलपर्स ने आवेदन के लिए PHP कोड लिखा है और इसे कंटेनर में चलाना चाहते हैं। ऐसा करने के लिए, वे बस PHP की बिल्डर छवि लेते हैं और इसे GitHub वेबसाइट पर URL पास करते हैं, जहां उनका कोड संग्रहीत है। नतीजतन, डेवलपर्स को लॉन्च के लिए एक एप्लिकेशन कंटेनर छवि तैयार होती है जिसमें Red Hat Enterprise Linux, सॉफ़्टवेयर संग्रह से PHP और निश्चित रूप से, एप्लिकेशन के लिए स्रोत PHP कोड होता है।

बिल्डर छवियां स्रोत कोड को विश्वसनीय घटकों के आधार पर निर्मित करने के लिए एक शक्तिशाली, आसान और तेज़ तरीका हैं।

कंटेनरीकृत घटक

एक कंटेनर को मुख्य रूप से एक बड़े सॉफ्टवेयर सिस्टम के एक घटक के रूप में तैनात किया जाना है, न कि स्व-निहित इकाई के रूप में। और इसके दो मुख्य कारण हैं।

सबसे पहले, माइक्रोसैस आर्किटेक्चर घटकों की पसंद की स्वतंत्रता को बढ़ाता है, और उन घटकों की संख्या में वृद्धि की ओर भी जाता है जहां से एप्लिकेशन और सॉफ्टवेयर सिस्टम की रचना की जाती है। कंटेनरीकृत घटक ऐसे सिस्टम को तेजी से और आसानी से तैनात करने में मदद करते हैं। उदाहरण के लिए, कंटेनर छवियां एक ही घटक के विभिन्न संस्करणों के सह-अस्तित्व की समस्या को हल करना आसान बनाती हैं। और Kubernetes / OpenShift, ओपन सर्विस ब्रोकर , OpenShift टेम्प्लेट्स और Helm चार्ट्स में यम्ल / json जैसे डिफाइनिंग टूल हाई-लेवल एप्लिकेशन डिस्क्रिप्शन का निर्माण प्रदान करते हैं।

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

उदाहरण के लिए, ओपनशिफ्ट एंटरप्राइज 3.0 में, अधिकांश मुख्य कोड RPM का उपयोग करके तैनात किया गया था, लेकिन इसके स्थापित होने के बाद, प्रशासकों ने राउटर और रजिस्ट्री को कंटेनर के रूप में तैनात किया। OpenShift 3.1 ने मास्टर, नोड, ओपनव्सविच और etcd के लिए कंटेनरीकृत परिनियोजन विकल्प पेश किया, और एक बार स्थापित होने के बाद, व्यवस्थापक कंटेनर के रूप में इलास्टिसर्च, फ़्लुएंड और किबाना को भी तैनात कर सकते हैं।

हालाँकि OpenShift इंस्टॉलर अभी भी सर्वर फाइल सिस्टम में बदलाव कर रहा है, सभी प्रमुख सॉफ्टवेयर घटकों को अब कंटेनर छवियों का उपयोग करके स्थापित किया जा सकता है। इसलिए, इन कंटेनरीकृत घटकों, उदाहरण के लिए, OpenShift में एम्बेडेड etcd छवि का एक उदाहरण, कभी नहीं - और कभी नहीं होगा - आपके ग्राहक जिस एप्लिकेशन के साथ काम कर रहे हैं, उसके स्रोत कोड को स्टोर करने के लिए उपयोग किया जाना चाहिए, बस क्योंकि इन कंटेनरीकृत घटकों को भाग के रूप में चलाने का इरादा है ओपनशिफ्ट कंटेनर प्लेटफॉर्म।

ओपनशिफ्ट के नए संस्करणों में, घटक कंटेनराइजेशन की ओर रुझान केवल तेज है, और अन्य सॉफ्टवेयर डेवलपर्स तेजी से इस दृष्टिकोण का उपयोग कर रहे हैं।

डिप्लॉय करने वाले चित्र

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

उदाहरण के लिए, ओपनशिफ्ट में, लॉग और मैट्रिक्स को तैनात करने के लिए "इमेज / कंटेनर टाइप" टेम्पलेट का उपयोग किया जाता है। तैनाती के चित्रों का उपयोग करके इन घटकों को नियुक्त करना ओपनशिफ्ट इंजीनियरों को उस आदेश को नियंत्रित करने की अनुमति देता है जिसमें विभिन्न घटक चलाते हैं और सत्यापित करते हैं कि वे सही ढंग से काम करते हैं।

मध्यवर्ती छवियां

एक मध्यवर्ती छवि एक कंटेनर की कोई छवि है जो आधार छवि पर निर्भर करती है। कर्नेल असेंबली, मिडलवेयर और भाषा रनटाइम को आमतौर पर बेस इमेज के शीर्ष पर अतिरिक्त परतों के रूप में लागू किया जाता है और फिर इस बेस इमेज के साथ FROM के निर्देश में निर्दिष्ट किया जाता है। मध्यवर्ती छवियां आमतौर पर अपने दम पर उपयोग नहीं की जाती हैं, लेकिन एक स्वायत्त छवि बनाने में ब्लॉक के रूप में।

छवि की विभिन्न परतें, एक नियम के रूप में, विशेषज्ञों के विभिन्न समूहों में लगी हुई हैं। उदाहरण के लिए, कर्नेल असेंबली लेयर के लिए सिस्टम एडमिनिस्ट्रेटर जिम्मेदार हैं और मिडलवेयर लेयर के लिए डेवलपर्स। एक ही समय में, एक टीम द्वारा तैयार की गई अंतर्निहित परतें उन लोगों के लिए एक मध्यवर्ती छवि के रूप में कार्य करती हैं जो उच्च स्तर की परतों के लिए जिम्मेदार हैं। हालांकि कभी-कभी ऐसी मध्यवर्ती छवियों को स्वायत्त रूप से उपयोग किया जा सकता है, खासकर जब परीक्षण।

बहुउद्देशीय (इंटरमॉडल) छवियां

बहुउद्देशीय कंटेनर छवियां एक हाइब्रिड वास्तुकला के साथ छवियां हैं। उदाहरण के लिए, Red Hat सॉफ़्टवेयर कलेक्शंस की कई छवियों का उपयोग दो तरीकों से किया जा सकता है। सबसे पहले, रेल और अपाचे सर्वर पर पूर्ण रूबी के साथ नियमित रूप से आवेदन कंटेनरों के रूप में। दूसरे, उन्हें ओपनशिफ्ट कंटेनर प्लेटफॉर्म के लिए बिल्डर इमेज के रूप में इस्तेमाल किया जा सकता है और उनके आधार पर बाल चित्र रूबी ऑन रेल्स, अपाचे, और एप्लिकेशन कोड जो आप स्रोत के पास गए, ऐसी चाइल्ड इमेज बनाते समय इमेज प्रोसेस में आते हैं।

ध्यान दें कि बहुउद्देश्यीय चित्र लोकप्रियता प्राप्त कर रहे हैं क्योंकि वे आपको एक ही छवि का उपयोग करके दो मौलिक रूप से विभिन्न कार्यों को हल करने की अनुमति देते हैं।

सिस्टम कंटेनर

कंटेनर के रूप में सिस्टम सॉफ़्टवेयर को तैनात करते समय, बाद वाले को अक्सर सुपरसुसर विशेषाधिकारों की आवश्यकता होती है। इस परिनियोजन विकल्प को सरल बनाने और यह सुनिश्चित करने के लिए कि कंटेनर को चलाने से पहले ऐसे कंटेनर लॉन्च किए जाते हैं और ऑर्केस्ट्रेशन सिस्टम लॉन्च किया जाता है, Red Hat ने एक विशेष टेम्पलेट विकसित किया है जिसे सिस्टम कंटेनर कहा जाता है । इन कंटेनरों को सिस्टम बूट और परमाणु कमांड का उपयोग करके ओएस बूट प्रक्रिया के दौरान लॉन्च किया जाता है, जो उन्हें किसी भी रनटाइम या कंटेनर आर्किडेशन सिस्टम से स्वतंत्र बनाता है। आज, Red Hat rsyslog, कॉकपिट, etcd और फ़्लेनल्ड के लिए सिस्टम कंटेनर प्रदान करता है और भविष्य में इस सूची का विस्तार करेगा।

सिस्टम कंटेनर Red Hat Enterprise Linux और परमाणु होस्ट को इन सेवाओं के चयनात्मक जोड़ को बहुत सरल बनाते हैं।

निष्कर्ष

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

लोग अक्सर "कंटेनर छवि" और "रिपॉजिटरी" शब्दों के बीच अंतर नहीं देखते हैं, खासकर जब वे डॉकटर कमांड में उपयोग किए जाते हैं। लेकिन यदि आप मतभेदों को समझने के बिना आदेशों का उपयोग कर सकते हैं, तो कंटेनर वातावरण की वास्तुकला पर काम करते समय, आपको स्पष्ट रूप से समझना चाहिए कि भंडार वास्तव में मुख्य डेटा संरचना है।

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



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