क्लाउड-नेटिव ऐप्स बनाने के लिए 5 सामान्य ज्ञान सिद्धांत

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

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

सॉफ़्टवेयर डिज़ाइन सिद्धांत

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

• चुंबन (इसे सरल रखें, बेवकूफी) - इसे जटिल मत बनाओ;
• सूखी (अपने आप को मत दोहराओ) - अपने आप को मत दोहराओ;
• YAGNI (आपको इसकी आवश्यकता नहीं होगी) - ऐसा कुछ न बनाएं जिसकी तुरंत आवश्यकता न हो;
• समाज चिंताओं को अलग करना - जिम्मेदारियाँ साझा करना।

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

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

क्लाउड-नेटिव कंटेनर: रेड हैट दृष्टिकोण

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

एकल चिंता सिद्धांत (एससीपी)

यह सिद्धांत कई मायनों में एकल उत्तरदायित्व सिद्धांत के समान है। एसआरपी), जो SOLID सेट का हिस्सा है और बताता है कि प्रत्येक वस्तु की एक ज़िम्मेदारी होनी चाहिए, और वह ज़िम्मेदारी पूरी तरह से एक वर्ग में समाहित होनी चाहिए। एसआरपी का मुद्दा यह है कि प्रत्येक जिम्मेदारी परिवर्तन का एक कारण है, और एक वर्ग के पास परिवर्तन का एक और केवल एक ही कारण होना चाहिए।

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

एससीपी सिद्धांत कहता है कि प्रत्येक कंटेनर को एक ही समस्या का समाधान करना चाहिए और इसे अच्छी तरह से करना चाहिए। इसके अलावा, कंटेनर दुनिया में एससीपी को ओओपी दुनिया में एसआरपी की तुलना में हासिल करना आसान है, क्योंकि कंटेनर आमतौर पर एक ही प्रक्रिया चलाते हैं, और अधिकांश समय यह प्रक्रिया एक ही कार्य को हल करती है।

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

उच्च अवलोकन सिद्धांत (HOP)

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

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

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

जीवन-चक्र अनुरूपता सिद्धांत (एलसीपी)

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

किसी कंटेनर के जीवनचक्र को प्रबंधित करने में सहायता के लिए प्लेटफ़ॉर्म में विभिन्न प्रकार के ईवेंट होते हैं। लेकिन यह एप्लिकेशन पर ही निर्भर करता है कि वह उनमें से किसे देखे और कैसे प्रतिक्रिया दे।

यह स्पष्ट है कि कुछ घटनाएँ दूसरों की तुलना में अधिक महत्वपूर्ण हैं। उदाहरण के लिए, यदि कोई एप्लिकेशन क्रैश को अच्छी तरह बर्दाश्त नहीं कर पाता है, तो उसे सिग्नल: टर्मिनेट (SIGTERM) संदेशों को स्वीकार करना होगा और सिग्नल को पकड़ने के लिए जितनी जल्दी हो सके अपना टर्मिनेशन रूटीन शुरू करना होगा: SIGTERM के बाद आने वाला किल (SIGKILL)।

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

छवि अपरिवर्तनीयता सिद्धांत (आईआईपी)

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

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

प्रक्रिया निपटान सिद्धांत (पीडीपी)

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

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

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

स्व-नियंत्रण सिद्धांत (एस-सीपी)

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

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

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

रनटाइम कारावास सिद्धांत (आरसीपी)

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

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

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

जब हम क्लाउड-फर्स्ट होने की बात करते हैं, तो हम अपने काम करने के तरीके के बारे में बात कर रहे होते हैं।
ऊपर, हमने कई सामान्य सिद्धांत तैयार किए जो क्लाउड वातावरण के लिए उच्च गुणवत्ता वाले कंटेनर अनुप्रयोगों के निर्माण के लिए पद्धतिगत आधार निर्धारित करते हैं।

ध्यान दें कि इन सामान्य सिद्धांतों के अलावा, आपको कंटेनरों के साथ काम करने के लिए अतिरिक्त उन्नत तरीकों और तकनीकों की भी आवश्यकता होगी। इसके अलावा, हमारे पास कुछ छोटी सिफारिशें हैं जो अधिक विशिष्ट हैं और स्थिति के आधार पर लागू की जानी चाहिए (या लागू नहीं की जानी चाहिए):

• छवियों का आकार कम करने का प्रयास करें: अस्थायी फ़ाइलें हटाएं और अनावश्यक पैकेज इंस्टॉल न करें - कंटेनर का आकार जितना छोटा होगा, उतनी ही तेज़ी से इसे इकट्ठा किया जाएगा और नेटवर्क पर लक्ष्य होस्ट पर कॉपी किया जाएगा।
• मनमाने उपयोगकर्ता-आईडी पर ध्यान दें: अपने कंटेनर लॉन्च करने के लिए सुडो कमांड या किसी विशेष उपयोगकर्ता आईडी का उपयोग न करें।
• महत्वपूर्ण पोर्ट चिह्नित करें: आप रनटाइम पर पोर्ट नंबर सेट कर सकते हैं, लेकिन उन्हें EXPOSE कमांड का उपयोग करके निर्दिष्ट करना बेहतर है - इससे अन्य लोगों और प्रोग्रामों के लिए आपकी छवियों का उपयोग करना आसान हो जाएगा।
• वॉल्यूम पर लगातार डेटा संग्रहीत करें: कंटेनर के नष्ट होने के बाद जो डेटा रहना चाहिए उसे वॉल्यूम पर लिखा जाना चाहिए।
• छवि मेटाडेटा लिखें: टैग, लेबल और एनोटेशन छवियों का उपयोग करना आसान बनाते हैं - अन्य डेवलपर्स आपको धन्यवाद देंगे।
• होस्ट और छवियों को सिंक्रनाइज़ करें: कुछ कंटेनरीकृत अनुप्रयोगों को कंटेनर को कुछ विशेषताओं, जैसे समय या मशीन आईडी पर होस्ट के साथ सिंक करने की आवश्यकता होती है।
• अंत में, हम टेम्पलेट और सर्वोत्तम अभ्यास साझा करते हैं जो आपको ऊपर सूचीबद्ध सिद्धांतों को अधिक प्रभावी ढंग से लागू करने में मदद करेंगे:
  www.slideshare.net/luebken/container-patterns
  docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices
  docs.projectatomic.io/container-best-practices
  docs.openshift.com/enterprise/3.0/creating_images/guidelines.html
  www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf
  leanpub.com/k8spatterns
  12factor.net

ओपनशिफ्ट कंटेनर प्लेटफ़ॉर्म के नए संस्करण पर वेबिनार - 4
11 जून 11.00 बजे

आप क्या सीखेंगे:

• अपरिवर्तनीय Red Hat Enterprise Linux CoreOS
• ओपनशिफ्ट सेवा जाल
• ऑपरेटर ढाँचा
• मूल ढाँचा

स्रोत: www.habr.com