क्लाउड-नेटिभ एप्स निर्माणका लागि ५ सामान्य ज्ञान सिद्धान्तहरू

"क्लाउड नेटिभ" वा केवल "क्लाउड" अनुप्रयोगहरू विशेष रूपमा क्लाउड पूर्वाधारहरूमा काम गर्न सिर्जना गरिन्छ। तिनीहरू सामान्यतया कन्टेनरहरूमा प्याकेज गरिएका ढिलो जोडिएको माइक्रोसेवाहरूको सेटको रूपमा बनाइएका हुन्छन्, जसलाई क्लाउड प्लेटफर्मद्वारा व्यवस्थित गरिन्छ। त्यस्ता अनुप्रयोगहरू पूर्वनिर्धारित रूपमा विफलताहरूको लागि तयार हुन्छन्, जसको मतलब तिनीहरूले भरपर्दो रूपमा काम गर्छन् र गम्भीर पूर्वाधार-स्तर विफलताहरूको घटनामा पनि मापन गर्छन्। सिक्काको अर्को पक्ष भनेको प्रतिबन्धहरू (सम्झौताहरू) को सेटहरू हुन् जुन क्लाउड प्लेटफर्मले कन्टेनर अनुप्रयोगहरूमा तिनीहरूलाई स्वचालित रूपमा व्यवस्थापन गर्न सक्षम हुन लगाउँदछ।

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

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

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

• चुम्बन (यो सरल, मूर्ख राख्नुहोस्) - यसलाई जटिल नगर्नुहोस्;
• ड्राई (आफूलाई नदोहोर्याउनुहोस्) - आफैलाई दोहोर्याउनुहोस्;
• YAGNI (तपाइँलाई यसको आवश्यकता छैन) - तुरुन्तै आवश्यक नभएको कुरा सिर्जना नगर्नुहोस्;
• समाज चिन्ताको पृथकीकरण - जिम्मेवारीहरू साझा गर्नुहोस्।

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

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

क्लाउड-नेटिभ कन्टेनरहरू: रेड ह्याट दृष्टिकोण

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

एकल सरोकार सिद्धान्त (SCP)

यो सिद्धान्त धेरै हिसाबले एकल उत्तरदायित्व सिद्धान्तसँग मिल्दोजुल्दो छ। एसआरपी), जुन SOLID सेटको अंश हो र बताउँछ कि प्रत्येक वस्तुको एउटा जिम्मेवारी हुनुपर्छ, र त्यो जिम्मेवारी पूर्ण रूपमा वर्गमा समावेश हुनुपर्छ। SRP को बिन्दु यो हो कि प्रत्येक जिम्मेवारी परिवर्तन को कारण हो, र एक वर्ग को एक मात्र र परिवर्तन को कारण हुनु पर्छ।

SCP मा, हामी OOP वर्गको तुलनामा कन्टेनरको उच्च स्तरको अमूर्तता र फराकिलो उद्देश्यलाई संकेत गर्न "उत्तरदायित्व" शब्दको सट्टा "चिन्ता" शब्द प्रयोग गर्छौं। र यदि SRP को लक्ष्य परिवर्तनको लागि एक मात्र कारण हो भने, SCP पछि कन्टेनरहरू पुन: प्रयोग र प्रतिस्थापन गर्ने क्षमता विस्तार गर्ने इच्छा हो। SRP लाई पछ्याएर र एउटा कन्टेनर सिर्जना गरेर जसले एकल समस्याको समाधान गर्छ र यसलाई कार्यात्मक रूपमा पूर्ण रूपमा गर्छ, तपाईंले विभिन्न अनुप्रयोग सन्दर्भहरूमा त्यो कन्टेनर छवि पुन: प्रयोग गर्ने सम्भावना बढाउनुहुन्छ।

SCP सिद्धान्तले बताउँछ कि प्रत्येक कन्टेनरले एउटा समस्या समाधान गर्नुपर्छ र यसलाई राम्रोसँग गर्नुपर्छ। यसबाहेक, कन्टेनर संसारमा SCP OOP संसारमा SRP भन्दा प्राप्त गर्न सजिलो छ, किनकि कन्टेनरहरूले सामान्यतया एक एकल प्रक्रिया चलाउँछन्, र धेरै जसो समय यो प्रक्रियाले एउटै कार्य समाधान गर्दछ।

यदि केही कन्टेनर माइक्रोसर्भिसले एकैचोटि धेरै समस्याहरू समाधान गर्नुपर्छ भने, यसलाई एकल-कार्य कन्टेनरहरूमा विभाजन गर्न सकिन्छ र साइडकार र इनिट कन्टेनर टेम्प्लेटहरू प्रयोग गरेर एक पोड (कन्टेनर प्लेटफर्म डिप्लोइमेन्टको एकाइ) भित्र मिलाउन सकिन्छ। थप रूपमा, SCP ले पुरानो कन्टेनर (जस्तै वेब सर्भर वा सन्देश ब्रोकर) लाई नयाँ कन्टेनरसँग बदल्न सजिलो बनाउँदछ जसले समान समस्या समाधान गर्दछ तर विस्तारित कार्यक्षमता वा तराजू राम्रोसँग छ।

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

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

अभ्यासमा, कन्टेनराइज्ड एप्लिकेसनमा कम्तीमा पनि विभिन्न प्रकारका स्वास्थ्य जाँचहरूका लागि एपीआई हुनुपर्छ: जीवन्तता परीक्षण र तयारी परीक्षण। यदि एप्लिकेसनले थप काम गर्ने दाबी गर्छ भने, यसले आफ्नो राज्यको अनुगमन गर्ने अन्य माध्यमहरू प्रदान गर्नुपर्छ। उदाहरणका लागि, Fluentd, Logstash र अन्य समान उपकरणहरू प्रयोग गरेर लग एग्रीगेसनको लागि STDERR र STDOUT मार्फत महत्त्वपूर्ण घटनाहरू लग गर्ने। साथै ट्रेसिङ र मेट्रिक्स सङ्कलन पुस्तकालयहरूसँग एकीकरण, जस्तै OpenTracing, Prometheus, आदि।

सामान्यतया, एप्लिकेसनलाई अझै पनि ब्ल्याक बक्सको रूपमा व्यवहार गर्न सकिन्छ, तर यो प्लेटफर्मलाई सबै भन्दा राम्रो तरिकाले अनुगमन र व्यवस्थापन गर्न आवश्यक पर्ने सबै एपीआईहरू प्रदान गरिनुपर्छ।

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

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

प्लेटफर्महरूमा कन्टेनरको जीवनचक्र व्यवस्थापन गर्न मद्दत गर्न विभिन्न प्रकारका घटनाहरू हुन्छन्। तर ती मध्ये कुनलाई बुझ्ने र कसरी प्रतिक्रिया दिने भन्ने निर्णय गर्ने यो अनुप्रयोगमा निर्भर छ।

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

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

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

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

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

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

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

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

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

आत्म-नियन्त्रण सिद्धान्त (S-CP)

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

अपवादहरू कन्फिगरेसनहरूका लागि बनाइन्छ जुन परिवेश अनुसार फरक हुन्छ र रनटाइममा उपलब्ध गराइनुपर्छ, उदाहरणका लागि Kubernetes ConfigMap मार्फत।

एउटा एपले धेरै कन्टेनराइज्ड कम्पोनेन्टहरू समावेश गर्न सक्छ, उदाहरणका लागि, कन्टेनराइज गरिएको वेब एप भित्र छुट्टै DBMS कन्टेनर। S-CP सिद्धान्त अनुसार, यी कन्टेनरहरू एकमा मिलाउनु हुँदैन, तर DBMS कन्टेनरमा डाटाबेसको सञ्चालनको लागि आवश्यक सबै चीजहरू समावेश गरिएको हुनुपर्दछ, र वेब अनुप्रयोग कन्टेनरले वेब सञ्चालनको लागि आवश्यक सबै समावेश गर्दछ। अनुप्रयोग, उही वेब सर्भर। नतिजाको रूपमा, रनटाइममा वेब अनुप्रयोग कन्टेनर DBMS कन्टेनरमा निर्भर हुनेछ र आवश्यकता अनुसार पहुँच गर्नेछ।

रनटाइम कैद सिद्धान्त (RCP)

S-CP सिद्धान्तले कन्टेनर कसरी बनाइन्छ र छवि बाइनरीमा के समावेश हुनुपर्छ भनेर परिभाषित गर्दछ। तर कन्टेनर भनेको "ब्ल्याक बक्स" मात्र होइन जसमा एउटा मात्र विशेषता हुन्छ - फाइल साइज। कार्यान्वयनको क्रममा, कन्टेनरले अन्य आयामहरू लिन्छ: प्रयोग गरिएको मेमोरीको मात्रा, CPU समय, र अन्य प्रणाली स्रोतहरू।

र यहाँ RCP सिद्धान्त काममा आउँछ, जसको अनुसार कन्टेनरले प्रणाली स्रोतहरूको लागि यसको आवश्यकताहरू काटेर प्लेटफर्ममा स्थानान्तरण गर्नुपर्छ। प्रत्येक कन्टेनरको संसाधन प्रोफाइलहरू (कति CPU, मेमोरी, नेटवर्क, र डिस्क स्रोतहरू आवश्यक छ) संग, प्लेटफर्मले अनुसूचित र स्वत: स्केलिङ गर्न, IT क्षमता व्यवस्थापन गर्न, र कन्टेनरहरूको लागि SLA स्तरहरू कायम राख्न सक्छ।

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

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

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

• छविहरूको आकार घटाउने प्रयास गर्नुहोस्: अस्थायी फाइलहरू मेटाउनुहोस् र अनावश्यक प्याकेजहरू स्थापना नगर्नुहोस् - कन्टेनरको आकार जति सानो हुन्छ, यो नेटवर्कमा लक्षित होस्टमा जति छिटो भेला हुन्छ र प्रतिलिपि हुन्छ।
• स्वेच्छाचारी प्रयोगकर्ता-आईडीहरूमा फोकस गर्नुहोस्: तपाईंको कन्टेनरहरू सुरू गर्न sudo आदेश वा कुनै विशेष userid प्रयोग नगर्नुहोस्।
• महत्त्वपूर्ण पोर्टहरू चिन्ह लगाउनुहोस्: तपाईंले रनटाइममा पोर्ट नम्बरहरू सेट गर्न सक्नुहुन्छ, तर तिनीहरूलाई EXPOSE आदेश प्रयोग गरेर निर्दिष्ट गर्नु राम्रो हुन्छ - यसले अन्य व्यक्तिहरू र कार्यक्रमहरूलाई तपाईंको छविहरू प्रयोग गर्न सजिलो बनाउँदछ।
• भोल्युमहरूमा निरन्तर डाटा भण्डार गर्नुहोस्: कन्टेनर नष्ट भएपछि रहनु पर्ने डाटा भोल्युमहरूमा लेखिनु पर्छ।
• छवि मेटाडेटा लेख्नुहोस्: ट्यागहरू, लेबलहरू र एनोटेसनहरूले छविहरू प्रयोग गर्न सजिलो बनाउँदछ - अन्य विकासकर्ताहरूले तपाईंलाई धन्यवाद दिनेछन्।
• होस्ट र तस्बिरहरू सिङ्क्रोनाइज गर्नुहोस्: केही कन्टेनरकृत अनुप्रयोगहरूलाई कन्टेनरलाई होस्टसँग समय वा मेशिन ID जस्ता निश्चित विशेषताहरूमा सिङ्क गर्न आवश्यक हुन्छ।
• अन्तमा, हामी टेम्प्लेटहरू र उत्कृष्ट अभ्यासहरू साझा गर्छौं जसले तपाईंलाई माथि सूचीबद्ध सिद्धान्तहरूलाई अझ प्रभावकारी रूपमा लागू गर्न मद्दत गर्नेछ:
  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