क्लाउड-नेटिव्ह अॅप्स तयार करण्यासाठी 5 सामान्य ज्ञान तत्त्वे

"क्लाउड नेटिव्ह" किंवा फक्त "क्लाउड" ऍप्लिकेशन्स विशेषतः क्लाउड इन्फ्रास्ट्रक्चरमध्ये काम करण्यासाठी तयार केले जातात. ते सामान्यत: कंटेनरमध्ये पॅक केलेल्या हलक्या जोडलेल्या मायक्रोसर्व्हिसेसच्या संच म्हणून तयार केले जातात, जे यामधून क्लाउड प्लॅटफॉर्मद्वारे व्यवस्थापित केले जातात. असे ऍप्लिकेशन डीफॉल्टनुसार अपयशांसाठी तयार केले जातात, याचा अर्थ ते गंभीर पायाभूत सुविधा स्तरावरील अपयशाच्या परिस्थितीतही विश्वासार्हपणे कार्य करतात आणि स्केल करतात. नाण्याची दुसरी बाजू म्हणजे निर्बंधांचे संच (करार) जे क्लाउड प्लॅटफॉर्म कंटेनर ऍप्लिकेशन्सना आपोआप व्यवस्थापित करण्यास सक्षम होण्यासाठी लादतो.

क्लाउड-आधारित ऍप्लिकेशन्सकडे जाण्याची गरज आणि महत्त्व याची पूर्णपणे जाणीव असताना, अनेक संस्थांना अद्याप कोठून सुरुवात करावी हे माहित नाही. या पोस्टमध्ये, आम्ही अनेक तत्त्वे पाहणार आहोत, ज्याचे पालन केल्यास, कंटेनराइज्ड ऍप्लिकेशन्स विकसित करताना, तुम्हाला क्लाउड प्लॅटफॉर्मची क्षमता लक्षात घेता येईल आणि IT पायाभूत सुविधांमध्ये गंभीर अपयश आल्यास देखील अनुप्रयोगांचे विश्वसनीय ऑपरेशन आणि स्केलिंग साध्य करता येईल. पातळी येथे वर्णन केलेल्या तत्त्वांचे अंतिम उद्दिष्ट हे आहे की कुबर्नेट्स सारख्या क्लाउड प्लॅटफॉर्मद्वारे स्वयंचलितपणे व्यवस्थापित केले जाऊ शकणारे अनुप्रयोग कसे तयार करावे हे शिकणे.

सॉफ्टवेअर डिझाइन तत्त्वे

प्रोग्रामिंग जगामध्ये, तत्त्वे सामान्य नियमांचा संदर्भ देतात ज्यांचे सॉफ्टवेअर विकसित करताना पालन करणे आवश्यक आहे. ते कोणत्याही प्रोग्रामिंग भाषेसह काम करताना वापरले जाऊ शकतात. प्रत्येक तत्त्वाची स्वतःची उद्दिष्टे असतात, ती साध्य करण्यासाठी साधने असतात जी सहसा टेम्पलेट्स आणि पद्धती असतात. उच्च-गुणवत्तेचे सॉफ्टवेअर तयार करण्यासाठी अनेक मूलभूत तत्त्वे देखील आहेत, ज्यामधून इतर सर्व प्रवाहित होतात. येथे मूलभूत तत्त्वांची काही उदाहरणे आहेत:

• चुंबनाचा (ते सोपे, मूर्ख ठेवा) - ते गुंतागुंत करू नका;
• ड्राय (स्वतःची पुनरावृत्ती करू नका) - स्वतःची पुनरावृत्ती करू नका;
• YAGNI (तुम्हाला त्याची गरज भासणार नाही) - लगेच गरज नसलेली एखादी गोष्ट तयार करू नका;
• सोसायटी चिंतेचे पृथक्करण - जबाबदाऱ्या सामायिक करा.

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

सॉलिड तत्त्वे OOP च्या क्षेत्राशी संबंधित आहेत आणि वर्ग, इंटरफेस आणि वारसा यांसारख्या संकल्पना आणि संकल्पनांच्या भाषेत तयार केल्या आहेत. सादृश्यतेने, क्लाउड ऍप्लिकेशन्ससाठी विकास तत्त्वे देखील तयार केली जाऊ शकतात, येथे फक्त मूलभूत घटक वर्ग नसून एक कंटेनर असेल. या तत्त्वांचे पालन करून, तुम्ही कंटेनराइज्ड अॅप्लिकेशन्स तयार करू शकता जे Kubernetes सारख्या क्लाउड प्लॅटफॉर्मची उद्दिष्टे आणि उद्दिष्टे अधिक चांगल्या प्रकारे पूर्ण करतात.

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

आज, जवळजवळ कोणताही अनुप्रयोग तुलनेने सहजपणे कंटेनरमध्ये पॅक केला जाऊ शकतो. परंतु कुबरनेट सारख्या क्लाउड प्लॅटफॉर्ममध्ये अनुप्रयोग प्रभावीपणे स्वयंचलित आणि ऑर्केस्ट्रेट करण्यासाठी, अतिरिक्त प्रयत्न आवश्यक आहेत.
खाली वर्णन केलेल्या कल्पनांचा आधार ही पद्धत होती बारा-फॅक्टर अॅप आणि वेब अॅप्लिकेशन्स बनवण्याच्या विविध पैलूंवर, सोर्स कोड मॅनेजमेंटपासून स्केलिंग मॉडेलपर्यंत इतर अनेक कामे. वर्णन केलेली तत्त्वे केवळ कंटेनराइज्ड ऍप्लिकेशन्सच्या विकासासाठी लागू होतात जी मायक्रोसर्व्हिसेसच्या शीर्षस्थानी तयार केली जातात आणि कुबर्नेट्स सारख्या क्लाउड प्लॅटफॉर्मसाठी डिझाइन केलेली असतात. आमच्या चर्चेतील मूळ घटक कंटेनर प्रतिमा आहे आणि लक्ष्य कंटेनर रनटाइम हे कंटेनर ऑर्केस्ट्रेशन प्लॅटफॉर्म आहे. प्रस्तावित तत्त्वांचे उद्दिष्ट कंटेनर तयार करणे आहे ज्यासाठी शेड्यूलिंग, स्केलिंग आणि मॉनिटरिंग कार्ये बहुतेक ऑर्केस्ट्रेशन प्लॅटफॉर्मवर स्वयंचलित केली जाऊ शकतात. तत्त्वे कोणत्याही विशिष्ट क्रमाने सादर केलेली नाहीत.

सिंगल कन्सर्न प्रिन्सिपल (एससीपी)

हे तत्त्व अनेक प्रकारे सिंगल रिस्पॉन्सिबिलिटी तत्त्वासारखे आहे. एसआरपी), जो SOLID संचाचा भाग आहे आणि प्रत्येक ऑब्जेक्टची एक जबाबदारी असणे आवश्यक आहे आणि ती जबाबदारी पूर्णपणे वर्गात अंतर्भूत असणे आवश्यक आहे. एसआरपीचा मुद्दा असा आहे की प्रत्येक जबाबदारी हे बदलाचे कारण असते आणि वर्गाकडे बदलाचे एकच कारण असते.

SCP मध्ये, OOP वर्गाच्या तुलनेत कंटेनरचा उच्च स्तरावरील अमूर्तता आणि व्यापक हेतू दर्शवण्यासाठी आम्ही “जबाबदारी” या शब्दाऐवजी “चिंता” हा शब्द वापरतो. आणि जर SRP चे ध्येय बदलण्याचे एकच कारण असेल तर SCP च्या मागे कंटेनर पुन्हा वापरण्याची आणि बदलण्याची क्षमता वाढवण्याची इच्छा आहे. SRP चे अनुसरण करून आणि एकच समस्या सोडवणारा कंटेनर तयार केल्याने आणि ते कार्यात्मकरित्या पूर्ण केले जाते, तुम्ही त्या कंटेनरची प्रतिमा वेगवेगळ्या अनुप्रयोग संदर्भांमध्ये पुन्हा वापरण्याची शक्यता वाढवता.

SCP तत्त्व सांगते की प्रत्येक कंटेनरने एक समस्या सोडवली पाहिजे आणि ती चांगली केली पाहिजे. शिवाय, कंटेनरच्या जगात SCP हे OOP जगामध्ये SRP पेक्षा सोपे आहे, कारण कंटेनर सहसा एकच प्रक्रिया चालवतात आणि बहुतेक वेळा ही प्रक्रिया एकच कार्य सोडवते.

जर कंटेनर मायक्रोसर्व्हिसने एकाच वेळी अनेक समस्या सोडवल्या पाहिजेत, तर ते सिंगल-टास्क कंटेनरमध्ये विभागले जाऊ शकते आणि साइडकार आणि इनिट कंटेनर टेम्पलेट्स वापरून एका पॉडमध्ये (कंटेनर प्लॅटफॉर्म तैनातीचे एक युनिट) एकत्र केले जाऊ शकते. याशिवाय, SCP जुन्या कंटेनरला (जसे की वेब सर्व्हर किंवा मेसेज ब्रोकर) नवीन कंटेनर बदलणे सोपे करते जे समान समस्येचे निराकरण करते परंतु कार्यक्षमतेचा विस्तार किंवा स्केल अधिक चांगल्या प्रकारे करते.

उच्च निरीक्षणक्षमता तत्त्व (HOP)

जेव्हा कंटेनर्सचा वापर अनुप्रयोग पॅकेज आणि चालवण्याचा एकसंध मार्ग म्हणून केला जातो, तेव्हा अनुप्रयोग स्वतःच ब्लॅक बॉक्स म्हणून हाताळले जातात. तथापि, जर हे क्लाउड कंटेनर असतील, तर त्यांनी कंटेनरच्या आरोग्यावर लक्ष ठेवण्यासाठी रनटाइमला विशेष API प्रदान केले पाहिजेत आणि आवश्यक असल्यास, योग्य कारवाई करा. याशिवाय, कंटेनर अद्यतनित करणे आणि त्यांचे जीवन चक्र व्यवस्थापित करणे स्वयंचलितपणे एकत्र करणे शक्य होणार नाही, ज्यामुळे सॉफ्टवेअर सिस्टमची स्थिरता आणि उपयोगिता खराब होईल.

प्रॅक्टिसमध्ये, कंटेनराइज्ड ऍप्लिकेशनमध्ये कमीतकमी, विविध प्रकारच्या आरोग्य तपासणीसाठी API असणे आवश्यक आहे: जिवंतपणा चाचण्या आणि तयारी चाचण्या. जर अनुप्रयोगाने अधिक काम करण्याचा दावा केला असेल, तर त्याने त्याच्या स्थितीचे परीक्षण करण्याचे इतर माध्यम प्रदान केले पाहिजेत. उदाहरणार्थ, Fluentd, Logstash आणि इतर तत्सम साधनांचा वापर करून लॉग एकत्रीकरणासाठी STDERR आणि STDOUT द्वारे महत्त्वाचे कार्यक्रम लॉग करणे. तसेच ट्रेसिंग आणि मेट्रिक्स कलेक्शन लायब्ररीसह एकत्रीकरण, जसे की OpenTracing, Prometheus, इ.

सर्वसाधारणपणे, ॲप्लिकेशनला अजूनही ब्लॅक बॉक्स मानला जाऊ शकतो, परंतु प्लॅटफॉर्मला सर्वोत्कृष्ट मार्गाने त्याचे परीक्षण आणि व्यवस्थापित करण्यासाठी आवश्यक असलेले सर्व API प्रदान केले जाणे आवश्यक आहे.

जीवन चक्र अनुरूप तत्त्व (LCP)

एलसीपी हा एचओपीचा विरोधी आहे. HOP म्हणतो की कंटेनरने प्लॅटफॉर्मवर रीड API उघड केले पाहिजेत, LCP ला प्लॅटफॉर्मवरून माहिती स्वीकारण्यास सक्षम असणे आवश्यक आहे. शिवाय, कंटेनरने केवळ इव्हेंट्स प्राप्त केले पाहिजेत असे नाही, तर दुसर्‍या शब्दात, त्यांच्याशी जुळवून घेणे देखील आवश्यक आहे. म्हणून तत्त्वाचे नाव, ज्याला API लेखनसह प्लॅटफॉर्म प्रदान करण्याची आवश्यकता मानली जाऊ शकते.

कंटेनरचे जीवनचक्र व्यवस्थापित करण्यात मदत करण्यासाठी प्लॅटफॉर्ममध्ये विविध प्रकारचे कार्यक्रम असतात. परंतु त्यापैकी कोणाला समजून घ्यायचे आणि कशी प्रतिक्रिया द्यायची हे स्वतः अर्जावर अवलंबून आहे.

हे स्पष्ट आहे की काही घटना इतरांपेक्षा अधिक महत्त्वाच्या असतात. उदाहरणार्थ, जर एखादा ऍप्लिकेशन क्रॅश चांगल्या प्रकारे सहन करत नसेल, तर त्याने सिग्नल: टर्मिनेट (SIGTERM) संदेश स्वीकारले पाहिजेत आणि सिग्नल पकडण्यासाठी शक्य तितक्या लवकर त्याचा टर्मिनेशन रूटीन सुरू केला पाहिजे: किल (SIGKILL) जो SIGTERM नंतर येतो.

याव्यतिरिक्त, पोस्टस्टार्ट आणि प्रीस्टॉप सारख्या घटना अनुप्रयोगाच्या जीवनचक्रासाठी महत्त्वपूर्ण असू शकतात. उदाहरणार्थ, एखादे अॅप्लिकेशन लॉन्च केल्यानंतर, विनंत्यांना प्रतिसाद देण्‍यापूर्वी त्याला काही सराव वेळ लागेल. किंवा शट डाउन करताना ऍप्लिकेशनने काही विशिष्ट प्रकारे संसाधने सोडली पाहिजेत.

प्रतिमा अपरिवर्तनीयता तत्त्व (IIP)

सामान्यतः हे मान्य केले जाते की कंटेनराइज्ड ऍप्लिकेशन्स बांधल्यानंतर ते अपरिवर्तित राहिले पाहिजेत, जरी ते वेगवेगळ्या वातावरणात चालवले जातात. हे रनटाइमच्या वेळी डेटा स्टोरेजचे बाह्यकरण करण्याची आवश्यकता आहे (दुसर्‍या शब्दात, यासाठी बाह्य साधने वापरण्यासाठी) आणि बाह्य, रनटाइम-विशिष्ट कॉन्फिगरेशनवर विसंबून राहणे, बदलण्याऐवजी किंवा प्रत्येक वातावरणासाठी अद्वितीय कंटेनर तयार करण्याऐवजी. अनुप्रयोगातील कोणत्याही बदलांनंतर, कंटेनरची प्रतिमा पुन्हा तयार केली जाणे आवश्यक आहे आणि वापरलेल्या सर्व वातावरणात तैनात करणे आवश्यक आहे. तसे, आयटी सिस्टम व्यवस्थापित करताना, समान तत्त्व वापरले जाते, ज्याला सर्व्हर आणि पायाभूत सुविधांच्या अपरिवर्तनीयतेचे तत्त्व म्हणून ओळखले जाते.

IIP चे ध्येय वेगवेगळ्या रनटाइम वातावरणासाठी स्वतंत्र कंटेनर प्रतिमा तयार करणे प्रतिबंधित करणे आणि योग्य पर्यावरण-विशिष्ट कॉन्फिगरेशनसह सर्वत्र समान प्रतिमा वापरणे हे आहे. या तत्त्वाचे पालन केल्याने तुम्हाला क्लाउड सिस्टीमच्या ऑटोमेशनच्या दृष्टिकोनातून रोल-बॅक आणि अॅप्लिकेशन अपडेट्सचे रोल-फॉरवर्ड यासारख्या महत्त्वाच्या पद्धती लागू करण्याची परवानगी मिळते.

प्रक्रिया डिस्पोजेबिलिटी तत्त्व (PDP)

कंटेनरचे सर्वात महत्त्वाचे वैशिष्ट्य म्हणजे त्याची तात्कालिकता: कंटेनरचे उदाहरण तयार करणे सोपे आणि नष्ट करणे सोपे आहे, म्हणून ते कोणत्याही वेळी सहजपणे बदलले जाऊ शकते. अशा बदलाची अनेक कारणे असू शकतात: सेवाक्षमता चाचणी अयशस्वी होणे, अनुप्रयोगाचे स्केलिंग, दुसर्या होस्टकडे हस्तांतरण, प्लॅटफॉर्म संसाधने संपुष्टात येणे किंवा इतर परिस्थिती.

परिणामी, कंटेनराइज्ड ऍप्लिकेशन्सने काही बाह्य माध्यमांचा वापर करून त्यांची स्थिती राखली पाहिजे किंवा यासाठी रिडंडंसीसह अंतर्गत वितरित योजना वापरल्या पाहिजेत. याव्यतिरिक्त, ऍप्लिकेशन त्वरीत सुरू होणे आणि त्वरीत बंद करणे आवश्यक आहे आणि अचानक घातक हार्डवेअर अपयशासाठी तयार असणे आवश्यक आहे.

या तत्त्वाची अंमलबजावणी करण्यात मदत करणारा एक सराव म्हणजे कंटेनर लहान ठेवणे. क्लाउड एनवायरमेंट्स कंटेनर इंस्टन्स लाँच करण्यासाठी आपोआप होस्ट निवडू शकतात, त्यामुळे कंटेनर जितका लहान असेल तितक्या लवकर ते सुरू होईल - ते नेटवर्कवर लक्ष्य होस्टवर अधिक जलद कॉपी करेल.

स्व-नियंत्रण तत्त्व (S-CP)

या तत्त्वानुसार, असेंब्लीच्या टप्प्यावर, कंटेनरमध्ये सर्व आवश्यक घटक समाविष्ट केले जातात. सिस्टीममध्ये फक्त शुद्ध लिनक्स कर्नल आहे असे गृहीत धरून कंटेनर तयार केला गेला पाहिजे, म्हणून सर्व आवश्यक अतिरिक्त लायब्ररी कंटेनरमध्येच ठेवल्या पाहिजेत. त्यामध्ये संबंधित प्रोग्रामिंग भाषेसाठी रनटाइम, अॅप्लिकेशन प्लॅटफॉर्म (आवश्यक असल्यास) आणि कंटेनर अॅप्लिकेशन चालू असताना आवश्यक असणारे इतर अवलंबित्व यासारख्या गोष्टींचा समावेश असावा.

कॉन्फिगरेशनसाठी अपवाद केले जातात जे पर्यावरणानुसार बदलतात आणि रनटाइमच्या वेळी प्रदान केले जाणे आवश्यक आहे, उदाहरणार्थ कुबर्नेट्स कॉन्फिगमॅपद्वारे.

ॲप्लिकेशनमध्ये अनेक कंटेनराइज्ड घटकांचा समावेश असू शकतो, उदाहरणार्थ, कंटेनराइज्ड वेब ऍप्लिकेशनमध्ये वेगळा DBMS कंटेनर. एस-सीपी तत्त्वानुसार, हे कंटेनर एकामध्ये एकत्र केले जाऊ नयेत, परंतु असे केले पाहिजे की DBMS कंटेनरमध्ये डेटाबेसच्या ऑपरेशनसाठी आवश्यक असलेल्या सर्व गोष्टी असतील आणि वेब ऍप्लिकेशन कंटेनरमध्ये वेबच्या ऑपरेशनसाठी आवश्यक असलेल्या सर्व गोष्टी असतील. अनुप्रयोग, समान वेब सर्व्हर. परिणामी, रनटाइमच्या वेळी वेब अनुप्रयोग कंटेनर DBMS कंटेनरवर अवलंबून असेल आणि आवश्यकतेनुसार त्यात प्रवेश करेल.

रनटाइम कॉन्फिनमेंट प्रिन्सिपल (RCP)

S-CP तत्त्व कंटेनर कसे बांधले जावे आणि प्रतिमा बायनरीमध्ये काय असावे हे परिभाषित करते. परंतु कंटेनर हा फक्त एक "ब्लॅक बॉक्स" नाही ज्यामध्ये फक्त एक वैशिष्ट्य आहे - फाइल आकार. अंमलबजावणी दरम्यान, कंटेनर इतर परिमाणे घेते: वापरलेली मेमरी, CPU वेळ आणि इतर सिस्टम संसाधने.

आणि येथे आरसीपी तत्त्व उपयुक्त आहे, त्यानुसार कंटेनरने सिस्टम संसाधनांसाठी त्याच्या आवश्यकतांचे शिरच्छेद करणे आणि त्यांना प्लॅटफॉर्मवर स्थानांतरित करणे आवश्यक आहे. प्रत्येक कंटेनरच्या संसाधन प्रोफाइलसह (किती CPU, मेमरी, नेटवर्क आणि डिस्क संसाधने आवश्यक आहेत), प्लॅटफॉर्म शेड्यूलिंग आणि ऑटोस्केलिंग चांगल्या प्रकारे करू शकते, IT क्षमता व्यवस्थापित करू शकते आणि कंटेनरसाठी SLA पातळी राखू शकते.

कंटेनरच्या संसाधन आवश्यकता पूर्ण करण्याव्यतिरिक्त, अनुप्रयोगासाठी स्वतःच्या सीमांच्या पलीकडे न जाणे देखील महत्त्वाचे आहे. अन्यथा, जेव्हा संसाधनाचा तुटवडा निर्माण होतो, तेव्हा प्लॅटफॉर्मने ते संपुष्टात आणणे किंवा स्थलांतरित करणे आवश्यक असलेल्या अनुप्रयोगांच्या सूचीमध्ये समाविष्ट करण्याची अधिक शक्यता असते.

जेव्हा आपण क्लाउड-फर्स्ट असण्याबद्दल बोलतो, तेव्हा आपण काम करण्याच्या पद्धतीबद्दल बोलत असतो.
वर, आम्ही अनेक सामान्य तत्त्वे तयार केली आहेत जी क्लाउड वातावरणासाठी उच्च-गुणवत्तेचे कंटेनर अनुप्रयोग तयार करण्यासाठी पद्धतशीर पाया सेट करतात.

लक्षात घ्या की या सामान्य तत्त्वांव्यतिरिक्त, आपल्याला कंटेनरसह कार्य करण्यासाठी अतिरिक्त प्रगत पद्धती आणि तंत्रांची देखील आवश्यकता असेल. याव्यतिरिक्त, आमच्याकडे काही लहान शिफारसी आहेत ज्या अधिक विशिष्ट आहेत आणि परिस्थितीनुसार लागू केल्या पाहिजेत (किंवा लागू केल्या जाऊ नयेत):

• प्रतिमांचा आकार कमी करण्याचा प्रयत्न करा: तात्पुरत्या फायली हटवा आणि अनावश्यक पॅकेजेस स्थापित करू नका - कंटेनरचा आकार जितका लहान असेल तितक्या वेगाने ते नेटवर्कवर लक्ष्य होस्टवर एकत्र केले जाईल आणि कॉपी केले जाईल.
• अनियंत्रित वापरकर्ता-आयडीवर लक्ष केंद्रित करा: तुमचे कंटेनर लाँच करण्यासाठी sudo कमांड किंवा कोणतेही विशेष userid वापरू नका.
• महत्त्वाचे पोर्ट चिन्हांकित करा: तुम्ही रनटाइमवर पोर्ट क्रमांक सेट करू शकता, परंतु 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

OpenShift कंटेनर प्लॅटफॉर्म - 4 च्या नवीन आवृत्तीवर वेबिनार
11 जून रोजी 11.00 वाजता

तुम्ही काय शिकाल:

• अपरिवर्तनीय Red Hat Enterprise Linux CoreOS
• OpenShift सेवा जाळी
• ऑपरेटर फ्रेमवर्क
• नेटिव्ह फ्रेमवर्क

स्त्रोत: www.habr.com