K8s के लिए पैकेज और पैकेज मैनेजर

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


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

इवान ग्लुशकोव ( ग्लि ) ने आरआईटी ++ पर अपनी रिपोर्ट के साथ, नीचे इस विस्तृत और विस्तृत प्रस्तुति के एक वीडियो और पाठ संस्करण के साथ हमारी मदद की।

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

स्पीकर के बारे में: इवान ग्लुशकोव 15 वर्षों से सॉफ्टवेयर विकसित कर रहा है। मैं एमजेड में काम करने में कामयाब रहा, इको में टिप्पणियों के लिए एक मंच पर, एमसीटीएस में एल्ब्रस प्रोसेसर के लिए संकलक के विकास में भाग लेते हैं। वह वर्तमान में पोस्टमेट्स में बुनियादी ढांचा परियोजनाओं में शामिल है। इवान अग्रणी देवज़ेन पॉडकास्ट में से एक है, जिसमें वे हमारे सम्मेलनों के बारे में बात करते हैं: यहाँ RIT ++ के बारे में है, और यहाँ HighLoad ++ के बारे में है।

पैकेज प्रबंधक

हालाँकि हर कोई किसी न किसी तरह के पैकेज मैनेजर का इस्तेमाल करता है, लेकिन यह क्या है, इस पर एक भी समझौता नहीं है। एक आम समझ है, और प्रत्येक की अपनी है।

आइए याद करें कि किस प्रकार के पैकेज मैनेजर पहले ध्यान में आते हैं:

• सभी ऑपरेटिंग सिस्टम के मानक पैकेज प्रबंधक: rpm, dpkg, portage , ...
• विभिन्न प्रोग्रामिंग भाषाओं के लिए पैकेज मैनेजर: कार्गो, कैबल, rebar3, मिक्स , ...

उनका मुख्य कार्य पैकेज को स्थापित करने, पैकेज को अपडेट करने, पैकेज को हटाने और निर्भरता के प्रबंधन के लिए कमांड निष्पादित करना है। प्रोग्रामिंग भाषाओं के अंदर पैकेज प्रबंधकों में, चीजें थोड़ी अधिक जटिल होती हैं। उदाहरण के लिए, "पैकेज लॉन्च करें" या "एक रिलीज़ बनाएं" (बिल्ड / रन / रिलीज़) जैसी कमांड हैं। यह पता चला है कि यह पहले से ही एक बिल्ड सिस्टम है, हालांकि हम इसे पैकेज मैनेजर भी कहते हैं।


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

विकास

जीएनयू लिबेटूल के साथ काम करने वाले, जो बड़ी संख्या में घटकों के साथ एक बड़ी परियोजना के लिए बनाया गया था, सर्कस में हंसी नहीं करता है। यह वास्तव में बहुत कठिन है, और कुछ मामलों को सिद्धांत रूप में हल नहीं किया जा सकता है, लेकिन केवल इसे दरकिनार किया जा सकता है।

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

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

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

डाक में काम करनेवाला मज़दूर

क्या आपको लगता है कि डॉकर पैकेज मैनेजर है या नहीं?

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

मैक्सिम लापशीन पहले ही कह चुका है कि डॉकर के साथ यह बहुत आसान हो गया है, और ऐसा ही है। डॉकर में बिल्ट-इन बिल्ड सिस्टम है, ये सभी डेटाबेस, बाइंडिंग, यूटिलिटीज हैं।

सभी लाभों की कीमत क्या है? जो लोग डॉकर के साथ काम करते हैं, वे औद्योगिक अनुप्रयोगों के बारे में बहुत कम सोचते हैं। मेरे पास ऐसा अनुभव है, और कीमत वास्तव में बहुत अधिक है:

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

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

मैं कहता हूं:

- डॉकटर आपकी सभी समस्याओं का समाधान कर सकता है। देखो यह कैसे किया जाता है।

- सब कुछ बटन पर होगा - महान! लेकिन हम चाहते हैं कि SSH कुबेरनेट कंटेनर के अंदर करे।

- रुको, कहीं भी एसएसएच नहीं।

- हां, हां, सब ठीक है ... लेकिन क्या एसएसएच संभव है?

उपयोगकर्ताओं की धारणा को एक नई दिशा में बदलने के लिए, यह बहुत समय लेता है, शैक्षिक कार्य और बहुत प्रयास करता है।

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

Kubernetes

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

दिलचस्प है, सभी कुबेरनेट्स नोड्स कुबेरनेट्स में कंटेनर के माध्यम से काम करते हैं, और सभी बाहरी अनुप्रयोग कंटेनरों के माध्यम से काम करते हैं - सब कुछ कंटेनरों के माध्यम से काम करता है ! यह प्लस और माइनस दोनों है।

कुबेरनेट्स में बहुत सारी उपयोगी कार्यक्षमता और गुण हैं: वितरण, दोष सहिष्णुता, विभिन्न क्लाउड सेवाओं के साथ काम करने की क्षमता, और माइक्रोसैस आर्किटेक्चर की ओर उन्मुखीकरण। यह सब दिलचस्प और शांत है, लेकिन कुबेरनेट्स में एप्लिकेशन कैसे स्थापित करें?

ऐप कैसे इंस्टॉल करें?

डॉकर-रजिस्ट्री में डॉकर छवि स्थापित करें।

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

• एक डॉकर छवि तैयार करें
• समझें कि यह कैसे चल रहा है, किन संस्करणों पर आधारित है;
• इसका परीक्षण करने में सक्षम हो;
• इकट्ठा, डॉक-रजिस्ट्री में भरें, जिसे आप, वैसे, पहले स्थापित किया गया था।

वास्तव में, यह एक पंक्ति में एक बड़ा, बड़ा दर्द है।

इसके अलावा, आप अभी भी k8s के संदर्भ (संसाधन) में आवेदन प्रकट करने की आवश्यकता है। सबसे आसान विकल्प:

• वर्णन तैनाती + फली, सेवा + प्रवेश (संभवतः);
• kubectl apply -f resource.yaml कमांड चलाएँ, और इस कमांड में सभी संसाधन ट्रांसफर करें।

गांधी स्लाइड पर अपने हाथ रगड़ते हैं - ऐसा लगता है जैसे मैंने कुबेरनेट्स में पैकेज मैनेजर पाया। लेकिन kubectl एक पैकेज मैनेजर नहीं है। वह सिर्फ इतना कहता है कि मैं व्यवस्था की ऐसी अंतिम स्थिति देखना चाहता हूं। यह पैकेज स्थापित नहीं कर रहा है, निर्भरता के साथ काम नहीं कर रहा है, निर्माण नहीं कर रहा है - यह सिर्फ "मैं इस अंतिम स्थिति को देखना चाहता हूं।"

पतवार

अंत में हम हेल्म आ गए। हेल्म एक बहुउद्देश्यीय उपयोगिता है। अब हम विचार करेंगे कि हेल्म के विकास के कौन से क्षेत्र हैं और इसके साथ काम करते हैं।

साँचा इंजन

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

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

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

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

उदाहरण के लिए, हेल्म की अभिव्यक्ति।

• हेल्म में सबसे महत्वपूर्ण हिस्सा चार्ट.यिमल है , जो बताता है कि यह किस प्रकार का है, क्या संस्करण है, यह कैसे काम करता है।
• टेम्प्लेट सिर्फ कुबेरनेट्स संसाधन टेम्प्लेट हैं जिनमें कुछ प्रकार के चर होते हैं। इन चर को बाहरी फ़ाइल या कमांड लाइन पर परिभाषित किया जाना चाहिए, लेकिन हमेशा बाहरी रूप से।
• values.yaml इन टेम्प्लेट के लिए चर के साथ फ़ाइल का मानक नाम है।

चार्ट स्थापित करने के लिए सबसे सरल स्टार्टअप कमांड हैम इंस्टाल ./wordpress (फ़ोल्डर)। कुछ मापदंडों को फिर से परिभाषित करने के लिए, हम कहते हैं: "मैं इन मापदंडों को ठीक से फिर से परिभाषित करना चाहता हूं और इस तरह के मूल्यों को निर्धारित करता हूं।"

हेल्म इस कार्य का सामना करता है, इसलिए आरेख में हम इसे हरे रंग में चिह्नित करते हैं।


सच, विपक्ष दिखाई देते हैं:

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

हेल्म की दिशा में डूबने से पहले - एक पैकेज मैनेजर, जिसके लिए मैं आपको यह सब बताता हूं, आइए देखें कि हेल्म निर्भरता के साथ कैसे काम करता है।

निर्भरता के साथ काम करें

निर्भरता के साथ काम करना मुश्किल है। सबसे पहले, एक आवश्यकताएँ है। श्याम फ़ाइल जो हम पर निर्भर करती है उसमें फिट होती है। आवश्यकताओं के साथ काम करते हुए, वह आवश्यकताओं को करता है। बैल - यह सभी आश्रितों की वर्तमान स्थिति (सोने की डली) है। उसके बाद, वह उन्हें एक फ़ोल्डर में डाउनलोड करता है जिसे / चार्ट कहा जाता है।

प्रबंधित करने के लिए उपकरण हैं: किससे, कैसे, कहाँ से कनेक्ट करें - टैग और शर्तें , जिनके साथ यह निर्धारित किया जाता है कि किस वातावरण में, किस बाहरी पैरामीटर पर निर्भर करता है, कनेक्ट करने के लिए या कुछ निर्भरता को जोड़ने के लिए नहीं।

मान लें कि आपके पास स्टेजिंग वातावरण (या उत्पादन के लिए RDS, या परीक्षण के लिए NoSQL) के लिए PostgreSQL है। इस पैकेज को उत्पादन में स्थापित करने से, आप PostgreSQL को स्थापित नहीं करेंगे, क्योंकि इसकी आवश्यकता नहीं है - केवल टैग और शर्तों का उपयोग करके।

यहाँ क्या दिलचस्प है?

• हेल्म सभी निर्भरता और अनुप्रयोगों के सभी संसाधनों को मिलाता है;
• सॉर्ट -> इंस्टॉल / अपडेट करें

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

पैकेज प्रबंधक

हेल्म एप्लिकेशन और निर्भरता स्थापित करता है, और आप हेल्म इंस्टॉल को बता सकते हैं - और यह पैकेज स्थापित करेगा। तो यह एक पैकेज मैनेजर है।

उसी समय, यदि आपके पास एक बाहरी रिपॉजिटरी है जहां आप पैकेज अपलोड करते हैं, तो आप इसे स्थानीय फ़ोल्डर के रूप में एक्सेस नहीं कर सकते हैं, लेकिन बस कहें: "इस रिपॉजिटरी से, इस पैकेज को लें, इसे ऐसे और ऐसे मापदंडों के साथ इंस्टॉल करें।"

बहुत सारे पैकेज के साथ खुले रिपॉजिटरी हैं। उदाहरण के लिए, आप चला सकते हैं: helm install -f prod / values.yaml स्थिर / वर्डप्रेस

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

लेकिन विपक्ष हैं: सभी सकर्मक निर्भरताओं को अंदर शामिल किया जाना चाहिए। यह एक बड़ी समस्या है जब सकर्मक निर्भरता स्वतंत्र अनुप्रयोग हैं और आप परीक्षण और विकास के लिए उनके साथ अलग से काम करना चाहते हैं।

एक और माइनस एंड-टू - एंड कॉन्फ़िगरेशन है । जब आपके पास एक डेटाबेस होता है और उसके नाम को सभी पैकेजों में स्थानांतरित करना होता है, तो यह हो सकता है, लेकिन ऐसा करना मुश्किल है।



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

विधानसभा और पैकेजिंग

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

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

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

इसलिए, हम कहते हैं कि हेलम छवियों के साथ काम करना नहीं जानता है।

डिज़ाइन

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

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

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

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

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

हेल्म बड़ी डॉकर छवियों के साथ किसी भी मदद की पेशकश नहीं करता है। मेरा मानना ​​है कि यह नहीं होना चाहिए, लेकिन हेल्म डेवलपर्स सभी उपयोगकर्ताओं से बेहतर जानते हैं, और स्टीव जॉब्स इस पर मुस्कुराते हैं।



विकास के साथ ब्लॉक भी लाल हो गया।

पर्यावरण स्वचालन

अंतिम दिशा - पर्यावरण का स्वचालन - एक दिलचस्प क्षेत्र है। डॉकर (और कुबेरनेट्स, एक संबंधित मॉडल के रूप में) की दुनिया से पहले, यह कहना संभव नहीं था: "मैं इस सर्वर पर या इन सर्वरों पर अपना एप्लिकेशन इंस्टॉल करना चाहता हूं, ताकि एन प्रतिकृतियां, 50 निर्भरताएं हों, और यह सभी स्वचालित रूप से काम करता है!" ऐसे, कोई कह सकता है, जो था, लेकिन नहीं था!

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

यह सलाह दी जाती है कि हेल्म में एक विशेष बटन है "मुझे पहले से ही अच्छा करो!" - और यह तुरंत अच्छा हो जाएगा। कुबेरनेट्स आपको ऐसा करने की अनुमति देता है।

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

ऐसा लगता है कि स्वाभाविक रूप से हेल्म आपको ऐसा करने की अनुमति देता है। क्योंकि अन्यथा, सामान्य रूप से हेल्म बनाने की बात क्या थी?

लेकिन यह पता चला, नहीं!


पर्यावरण का कोई स्वचालन नहीं है।

विकल्प

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

टेम्पलेट इंजन

ऐसा लगता है, एक टेम्पलेट इंजन के रूप में, हेल्म ने सभी समस्याओं को हल किया, लेकिन फिर भी समुदाय विकल्प बनाता है। मुझे आपको टेम्पलेट इंजन की समस्याओं को याद दिलाना है: वर्बोसिटी और कोड का पुन: उपयोग।

यहाँ एक अच्छा प्रतिनिधि Ksonnet है। यह डेटा और अवधारणाओं के एक मूल रूप से भिन्न मॉडल का उपयोग करता है, और कुबेरनेट्स संसाधनों के साथ काम नहीं करता है, लेकिन अपनी स्वयं की परिभाषाओं के साथ:
प्रोटोटाइप (परम) -> घटक -> अनुप्रयोग -> वातावरण।


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

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

सैद्धांतिक रूप से, यह सुविधाजनक है। मैंने व्यावहारिक रूप से इसका उपयोग नहीं किया।

पैकेज प्रबंधक

, — , , . Ksonnet . Ksonnet Helm , , .. , , , .


, , , , . . , , , 0.1. , .


, — KubePack , .

डिज़ाइन

:

1. Helm;
   
2. Helm;
   
3. , ;
   
4. , .
   

1. Helm

— Draft . — , , . Draft — Heroku-style:

• (pack);
• , , Python «Hello, world!»;
• , Docker- ( );
• , , docker-registry, ;
• .

, , .

Helm, Draft Helm-, production ready, , Draft Helm-, . .

, Draft , Helm-. Draft — .

2. Helm

Helm Charts Kubernetes-, Helm Charts. :

• GitKube;
• Skaffold;
• Forge.

Helm, . , , command line interface, Chart , git push .

, docker build, docker push kubectl rollout. , Helm, . .

3.

— . — Metaparticle . , Python, Python , .

, , , sysconfig .. .

, , , - Kubernetes-.

: , ; , ; ..


, , , - , Python- Kubernetes-. ?

- , . . , , preinstall , - . Kubernetes-, Metaparticle, .

, , Kubernetes- . , , Metaparticle.



Metaparticle, Helm . , .

Telepresence/Ksync — . , , Helm-, . , - , - , , . , Production-, Production - .

Kubernetes , Docker, registry, Kubernetes. . , .

, , , Development . : , , , , — , , , Helm, , .

, .

4. Kubernetes Kubernetes

, Kubernetes Kubernetes. , Helm- , . , . , Docker-compose .

Docker-compose , , , , Docker, Kubernetes, Docker-compose, . , . , Docker. .

minikube , Docker-compose, . , , Docker-compose — 10 . , .


Docker-compose, , .

, — Helm, , , Helm - . CI/CD, , . — Helm, ? , , .

CI/CD, , docker', set-, , — .

CI/CD — , .

परिणाम

5 Helm . , . , , . , , , .

Helm

, , Helm . , Helm , . , , , Helm.

, Road Map. Kuberneres Helm community , , Helm V3 .

Tiller, cli

, . Helm :

1. , (cmd ..).
   
2. Tiller — , Kubernetes.
   

Tiller , Command Line Interface. : « Chart» — Helm , , Tiller', : «, - ! , Kubernetes-» — .

Helm, Tiller , . , , , , Tiller' — namespace . Tiller namespace, , . , .

V3 Tiller .


? , , Command Line Interface, , Kubernetes. , Kubernetes , Tiller. kubectl cli .

Tiller . , Kubernetes Command Line Interface : , , , pre- post-. .

Lua- Chart

, — , lua- . Chart lua-, . . , . , , , .


Lua , , , - , , .

, , . , . Kubernetes, - , , , , . देखते हैं क्या होता है।

Release- + secret

, , Release- , Release . , Release-, , , CRD, , .

namespace

Release- namespace, , - Tiller' namespace — , .

CRD: controller

, CRD-controller Helm , push-. .

, .


, Helm . , , , . , , . Helm — - Kubernetes. - , , .

, CI/CD , . Slack , , , master , . : « Staging» — , : « !» — . .

Docker-compose Telepresence.

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

• विकास के लिए, क्योंकि वास्तव में हमें एक ही चीज को विकसित करना है, लेकिन दो अलग-अलग संस्करण;
• जारी करने के लिए;
• एक नाम संघर्ष के लिए, क्योंकि सभी मानक पैकेज प्रबंधकों में, विभिन्न संस्करणों के दो पैकेज स्थापित करने से समस्याएं हो सकती हैं।

वास्तव में, कुबेरनेट्स हमारे लिए सब कुछ तय करता है - आपको बस इसे सही ढंग से उपयोग करने की आवश्यकता है।



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

दूसरा सकर्मक निर्भरता है, और यहाँ यह अधिक जटिल है।


उदाहरण के लिए, आप सेवाओं की एक श्रृंखला विकसित कर रहे हैं और ए का परीक्षण करना चाहते हैं। इसके लिए, आपको उन सभी आश्रितों को उत्तीर्ण करना होगा, जिन पर ए निर्भर करता है, जिसमें आपके पैकेज की हेल्म परिभाषा में परिवर्तनशील भी शामिल है। लेकिन एक ही समय में, आप बी को विकसित करना चाहते हैं और यह भी परीक्षण करना चाहते हैं - यह कैसे करना है यह समझ से बाहर है, क्योंकि आपको इसमें सभी परिवर्तनशील निर्भरताएं डालनी होंगी।

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

उपयोगी लिंक

• ड्राफ्ट

• GitKube

• हेलम

• कोनसनेट

• टेलीग्राम स्टिकर: एक , दो

• सिग-एप्स

• कुबेपैक

• मेटापार्टिकल

• स्केफोल्ड

• हेल्म v3

• डॉकटर-रचना

• Ksync

• दूरदर्शन

• डॉ

• फोर्ज

GitHub पर स्पीकर इवान ग्लुशकोव का प्रोफाइल , ट्विटर पर, हैबर पर।

बड़ी खबर है

हमारे यूट्यूब चैनल पर, हमने RIT ++ त्योहार से DevOps पर सभी रिपोर्टों का एक वीडियो खोला । यह एक अलग प्लेलिस्ट है , लेकिन वीडियो की पूरी सूची में अन्य सम्मेलनों से कई उपयोगी चीजें हैं।

बेहतर अभी तक, चैनल और न्यूज़लेटर की सदस्यता लें, क्योंकि आने वाले वर्ष में हमारे पास बहुत सारे देवोप होंगे : मई में, RIT ++ की रूपरेखा; वसंत, गर्मी और शरद ऋतु में हाईलाड ++ के एक खंड के रूप में, और एक अलग शरद ऋतु DevOpsConf रूस ।