वयस्क कंटेनरों (भाग 03): 10 चीजें जिन्हें आपको कंटेनरों के साथ करने की आवश्यकता नहीं है

आपने अंततः कंटेनरों की दया के सामने आत्मसमर्पण कर दिया और पाया कि वे बहुत सारी समस्याओं का समाधान करते हैं और उनके बहुत सारे फायदे हैं:

1. कंटेनर अपरिवर्तनीय हैं: ओएस, लाइब्रेरीज़, फ़ोल्डर्स और एप्लिकेशन - चूंकि यह सब सीधे कंटेनर में संग्रहीत किया जाता है, आप 100% सुनिश्चित हैं कि क्यूए में परीक्षण की गई छवि हमेशा उत्पादन में जाएगी। और यह ठीक उसी तरह से काम करेगा।
2. हल्के कंटेनर: एक कंटेनर स्मृति को बर्बाद नहीं करता है। सैकड़ों मेगाबाइट और गीगाबाइट के बजाय, एक कंटेनर को केवल मुख्य प्रक्रिया के लिए मेमोरी की आवश्यकता होती है।
3. कंटेनर तेज़ होते हैं: एक कंटेनर नियमित लिनक्स प्रक्रिया के रूप में तेजी से शुरू होता है। मिनट नहीं, लेकिन सचमुच सेकंड।

हालांकि, कई अभी भी मानते हैं कि कंटेनर वर्चुअल मशीन हैं, और अपनी सबसे महत्वपूर्ण संपत्ति के बारे में भूल जाते हैं ...

पंचांग कंटेनर

डिस्पोजेबिलिटी इसलिए है कि आपको अपने दृष्टिकोण को बदलना चाहिए कि कंटेनरों को कैसे संभालना है।

और यहाँ है कि किसी भी मामले में कंटेनर के फायदे को न खोने के लिए क्या किया जाना चाहिए:

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

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

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

4. सिंगल लेयर कंटेनर का इस्तेमाल न करें। प्रभावी रूप से मल्टी-लेयर (मल्टी-लेवल) फ़ाइल सिस्टम का उपयोग करने के लिए, हमेशा OS के लिए अलग-अलग लेयर बनाते हैं, यूज़रनेम परिभाषा के लिए, कॉन्फ़िगरेशन के लिए, और अंत में, एप्लिकेशन के लिए। इसलिए छवियों को फिर से बनाना, बनाए रखना और वितरित करना आसान होगा।

5. चल रहे कंटेनरों से चित्र बनाने की आवश्यकता नहीं है। दूसरे शब्दों में, एक छवि बनाने के लिए docker प्रतिबद्ध कमांड का उपयोग न करें, क्योंकि ऐसी छवियां प्रतिलिपि प्रस्तुत करने योग्य नहीं होंगी। इसके बजाय, हमेशा एक Dockerfile या अन्य S2I (स्रोत-से-छवि) उपकरण का उपयोग करें जो प्रतिलिपि प्रस्तुत करने योग्यता प्रदान करते हैं। इसके अलावा, डॉकरफाइल में, आप आसानी से परिवर्तनों को ट्रैक कर सकते हैं यदि आप इसे स्रोत भंडार (गिट) में संग्रहीत करते हैं।

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

7. एक कंटेनर में एक से अधिक प्रक्रिया निष्पादित करने की आवश्यकता नहीं है। कंटेनर आदर्श रूप से एकल प्रक्रिया (http डेमन डेमॉन, एप्लिकेशन सर्वर, DBMS) के लिए उपयुक्त हैं। अन्यथा, आप सभी प्रकार की परेशानियों का सामना कर सकते हैं, जैसे लॉग में खुदाई करना या प्रक्रियाओं को अलग से अपडेट करना।

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

9. प्रक्रियाओं को रूट के रूप में चलाने की आवश्यकता नहीं है। “डिफ़ॉल्ट रूप से, डॉकटर कंटेनर रूट के रूप में चलते हैं। (...) हालाँकि, जैसा कि तकनीक विकसित होती है, अन्य, सुरक्षित डिफ़ॉल्ट स्टार्टअप विकल्प दिखाई दे सकते हैं। वर्तमान परिस्थितियों में, रूट आवश्यकता को खतरा माना जा सकता है और सभी वातावरणों में प्रदान नहीं किया जा सकता है। रूट के अलावा किसी अन्य उपयोगकर्ता को निर्दिष्ट करने के लिए, जिसकी ओर से कंटेनर लॉन्च किया जाएगा, USER निर्देश का उपयोग किया जाता है ”(डोकर छवि लेखक के लिए मार्गदर्शन से अंश)

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