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

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



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

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

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

• KISS (के लिए इसे आसान बनाएं, बेवकूफ) - यह सरल रखने;
• DRY (खुद को दोहराएं नहीं) - दोहराएं नहीं;
• YAGNI (आपको इसकी आवश्यकता नहीं है) - ऐसा कुछ न बनाएं जिसमें तत्काल आवश्यकता न हो;
• SoC (चिंताओं का पृथक्करण) - जिम्मेदारियों को साझा करने के लिए।

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

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

क्लाउड-आधारित कंटेनर: रेड हैट एप्रोच

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

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

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

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

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

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

निगरानी की सुविधा का सिद्धांत (उच्च अवलोकन सिद्धांत, HOP)

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


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

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

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

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


प्लेटफार्मों में विभिन्न प्रकार की घटनाएं होती हैं जो कंटेनर के जीवन चक्र को प्रबंधित करने में मदद करती हैं। लेकिन यह आवेदन करने के लिए है कि उनमें से कौन सा अनुभव करना है और कैसे प्रतिक्रिया देना है।

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

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

कंटेनर छवि की इम्यूटेबिलिटी का सिद्धांत (इमेज इम्युटेबिलिटी प्रिंसिपल, IIP)

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

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

प्रक्रिया अक्षमता सिद्धांत (पीडीपी)

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


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

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

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

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



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

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

रनटाइम कॉन्फिडेंस सिद्धांत (आरसीपी)

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


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

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

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

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

• छवियों के आकार को कम करने का प्रयास करें: अस्थायी फ़ाइलों को हटा दें और अनावश्यक पैकेज न डालें - कंटेनर जितना छोटा होता है, उतनी ही तेजी से इसे एकत्र किया जाता है और नेटवर्क पर लक्ष्य होस्ट में कॉपी किया जाता है।
• उपयोगकर्ता-आईडी पर ध्यान दें: अपने कंटेनरों को चलाने के लिए sudo कमांड या किसी विशेष उपयोगकर्ता का उपयोग न करें।
• महत्वपूर्ण पोर्ट को लेबल करें: पोर्ट नंबर को रनटाइम पर भी सेट किया जा सकता है, लेकिन 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
• Openshift सेवा जाल
• संचालक ढांचा
• चाकू का ढांचा