कुबेरनेट्स सर्वोत्तम अभ्यास। छोटे कंटेनर बनाना

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

हालाँकि यह तकनीक आरंभ करने के लिए बहुत अच्छी है, डिफ़ॉल्ट आधार छवियों का उपयोग करने से कमजोरियों से भरी बड़ी छवियों के साथ असुरक्षित काम हो सकता है।

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

तो यह सारा अतिरिक्त कार्यभार डिजिटल स्थान की बर्बादी है और सुरक्षा कमजोरियों और बगों के लिए एक बढ़िया छिपने की जगह है। तो आइए कंटेनर छवि के आकार को कम करने के दो तरीकों पर गौर करें।

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

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

छोटी आधार छवि पर जाने के लिए, नई आधार छवि के साथ काम करना शुरू करने के लिए बस डॉकरफाइल को अपडेट करें:

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

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

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

कोड पहले कंटेनर में बनाया जाता है और संकलित किया जाता है। संकलित कोड को उस कोड को संकलित करने के लिए आवश्यक कंपाइलरों और उपकरणों के बिना एक अंतिम कंटेनर में पैक किया जाता है। आइए इस प्रक्रिया के माध्यम से एक गो एप्लिकेशन चलाएं। सबसे पहले, हम ऑनबिल्ड इमेज से अल्पाइन लिनक्स की ओर बढ़ेंगे।

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

आप इस डॉकर फ़ाइल में कुछ अजीब देख सकते हैं: इसमें दो FROM पंक्तियाँ हैं। पहली 4 पंक्ति का अनुभाग बिल्कुल पिछले Dockerfile जैसा ही दिखता है, सिवाय इसके कि यह इस चरण को नाम देने के लिए AS कीवर्ड का उपयोग करता है। अगले अनुभाग में एक नई छवि शुरू करने के लिए एक नई FROM लाइन है, जहां गोलांग: अल्पाइन छवि के बजाय हम आधार छवि के रूप में रॉ अल्पाइन का उपयोग करेंगे।

रॉ एल्पाइन लिनक्स में कोई एसएसएल प्रमाणपत्र स्थापित नहीं है, जिसके कारण HTTPS पर अधिकांश एपीआई कॉल विफल हो जाएंगी, तो आइए कुछ रूट सीए प्रमाणपत्र स्थापित करें।

अब मज़ेदार हिस्सा आता है: संकलित कोड को पहले कंटेनर से दूसरे कंटेनर में कॉपी करने के लिए, आप बस दूसरे खंड की पंक्ति 5 पर स्थित COPY कमांड का उपयोग कर सकते हैं। यह केवल एक एप्लिकेशन फ़ाइल की प्रतिलिपि बनाएगा और गो उपयोगिता टूल को प्रभावित नहीं करेगा। नई मल्टी-स्टेज डॉकर फ़ाइल में एक कंटेनर छवि होगी जिसका आकार केवल 12 मेगाबाइट होगा, जबकि मूल कंटेनर छवि 700 मेगाबाइट थी, जो एक बड़ा अंतर है!
इसलिए छोटी आधार छवियों और बिल्डर पैटर्न का उपयोग करना बहुत अधिक काम किए बिना बहुत छोटे कंटेनर बनाने का शानदार तरीका है।
यह संभव है कि एप्लिकेशन स्टैक के आधार पर, छवि और कंटेनर आकार को कम करने के अतिरिक्त तरीके हों, लेकिन क्या छोटे कंटेनरों का वास्तव में मापने योग्य लाभ होता है? आइए दो क्षेत्रों पर नजर डालें जहां छोटे कंटेनर बेहद प्रभावी हैं - प्रदर्शन और सुरक्षा।

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

डॉकर परतों को कैश करेगा इसलिए बाद का निर्माण बहुत तेज़ होगा। हालाँकि, कंटेनरों के निर्माण और परीक्षण के लिए उपयोग की जाने वाली कई सीआई प्रणालियाँ परतों को कैश नहीं करती हैं, इसलिए महत्वपूर्ण समय की बचत होती है। जैसा कि आप देख सकते हैं, एक बड़ा कंटेनर बनाने का समय, आपकी मशीन की शक्ति के आधार पर, 34 से 54 सेकंड तक है, और बिल्डर पैटर्न का उपयोग करके कंटेनर का उपयोग करते समय - 23 से 28 सेकंड तक कम किया जाता है। इस प्रकार के संचालन के लिए उत्पादकता में 40-50% की वृद्धि होगी। तो बस इस बारे में सोचें कि आप कितनी बार अपना कोड बनाते और परीक्षण करते हैं।

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

Google कंटेनर रजिस्ट्री (जीसीआर) के साथ, आप केवल कच्चे भंडारण और नेटवर्किंग के लिए भुगतान करते हैं, और कोई अतिरिक्त कंटेनर प्रबंधन शुल्क नहीं है। यह निजी, सुरक्षित और बहुत तेज़ है। जीसीआर पुल ऑपरेशन को तेज करने के लिए कई युक्तियों का उपयोग करता है। जैसा कि आप देख सकते हैं, गो: ऑनबिल्ड का उपयोग करके डॉकर कंटेनर इमेज कंटेनर डालने में कंप्यूटर के प्रदर्शन के आधार पर 15 से 48 सेकंड लगेंगे, और छोटे कंटेनर के साथ समान ऑपरेशन में 14 से 16 सेकंड लगेंगे, और कम उत्पादक मशीनों के लिए ऑपरेशन की गति में लाभ 3 गुना बढ़ जाता है। बड़ी मशीनों के लिए, समय लगभग समान है, क्योंकि जीसीआर छवियों के साझा डेटाबेस के लिए वैश्विक कैश का उपयोग करता है, जिसका अर्थ है कि आपको उन्हें लोड करने की बिल्कुल भी आवश्यकता नहीं है। कम-शक्ति वाले कंप्यूटर में, सीपीयू बाधा है, इसलिए छोटे कंटेनरों का उपयोग करने का लाभ यहां बहुत अधिक है।

यदि आप जीसीआर का उपयोग कर रहे हैं, तो मैं आपके बिल्ड सिस्टम के हिस्से के रूप में Google कंटेनर बिल्डर (जीसीबी) का उपयोग करने की अत्यधिक अनुशंसा करता हूं।

जैसा कि आप देख सकते हैं, इसका उपयोग आपको एक उत्पादक मशीन की तुलना में बिल्ड+पुश ऑपरेशन की अवधि को कम करने में बहुत बेहतर परिणाम प्राप्त करने की अनुमति देता है - इस मामले में, होस्ट को कंटेनर बनाने और भेजने की प्रक्रिया लगभग 2 गुना तेज है। साथ ही, आपको प्रतिदिन 120 निःशुल्क निर्माण मिनट मिलते हैं, जो अधिकांश मामलों में आपकी कंटेनर निर्माण आवश्यकताओं को पूरा करता है।

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

ऐसे कई मामले हैं जहां ऐसा हो सकता है: क्लस्टर में एक नया नोड जोड़ना, नोड्स को अपग्रेड करना, या यहां तक ​​कि तैनाती के लिए एक नए कंटेनर पर स्विच करना। इस प्रकार, पुल निष्कर्षण समय को कम करना एक महत्वपूर्ण कारक बन जाता है। यह निर्विवाद है कि एक छोटा कंटेनर बड़े कंटेनर की तुलना में बहुत तेजी से डाउनलोड होता है। यदि आप कुबेरनेट्स क्लस्टर में कई कंटेनर चला रहे हैं, तो समय की बचत महत्वपूर्ण हो सकती है।

इस तुलना पर एक नज़र डालें: छोटे कंटेनरों पर एक पुल ऑपरेशन में मशीन की शक्ति के आधार पर, गो:ऑनबिल्ड का उपयोग करके उसी ऑपरेशन की तुलना में 4-9 गुना कम समय लगता है। साझा, छोटे कंटेनर बेस छवियों का उपयोग करने से उस समय और गति में काफी तेजी आती है जिस पर नए कुबेरनेट्स नोड्स तैनात किए जा सकते हैं और ऑनलाइन आ सकते हैं।

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

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

निष्कर्ष स्पष्ट है: छोटे कंटेनर बनाएं क्योंकि वे आपके सिस्टम को वास्तविक प्रदर्शन और सुरक्षा लाभ प्रदान करते हैं।

कुबेरनेट्स सर्वोत्तम अभ्यास। नेमस्पेस के साथ कुबेरनेट्स का संगठन

कुछ विज्ञापन 🙂

हमारे साथ रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक रोचक सामग्री देखना चाहते हैं? आदेश देकर या मित्रों को अनुशंसा करके हमारा समर्थन करें, डेवलपर्स के लिए क्लाउड VPS $4.99 से शुरू, प्रवेश स्तर के सर्वरों का एक अनूठा एनालॉग, जिसका आविष्कार हमने आपके लिए किया था: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps के बारे में पूरी सच्चाई $19 से या सर्वर कैसे साझा करें? (RAID1 और RAID10 के साथ उपलब्ध, 24 कोर तक और 40GB DDR4 तक)।

एम्स्टर्डम में इक्विनिक्स टियर IV डेटा सेंटर में Dell R730xd 2x सस्ता है? केवल यहां 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 टीवी $199 से नीदरलैंड में! डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 से! के बारे में पढ़ा इन्फ्रास्ट्रक्चर कॉर्प का निर्माण कैसे करें। एक पैसा के लिए 730 यूरो मूल्य के डेल R5xd E2650-4 v9000 सर्वर के उपयोग के साथ वर्ग?

स्रोत: www.habr.com