हेल्म 3 का परिचय

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

15 अक्टूबर 2015 को, इस परियोजना का जन्म हुआ जिसे अब हेल्म के नाम से जाना जाता है। अपनी स्थापना के ठीक एक साल बाद, हेल्म समुदाय हेल्म 2 पर सक्रिय रूप से काम करते हुए, कुबेरनेट्स में शामिल हो गया। जून 2018 में, हेल्म सीएनसीएफ में शामिल हो गए एक विकासशील (इनक्यूबेटिंग) परियोजना के रूप में। वर्तमान में तेजी से आगे बढ़ रहा है, और नए हेल्म 3 की पहली अल्फा रिलीज होने वाली है। (यह रिलीज पहले ही हो चुका है मई के मध्य में - लगभग। अनुवाद).

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

सारांश:

• हेल्म के निर्माण का इतिहास;
• टिलर को भावभीनी विदाई;
• चार्ट भंडार;
• रिहाई प्रबंधन;
• चार्ट निर्भरता में परिवर्तन;
• पुस्तकालय चार्ट;
• आगे क्या?

हेल्म का इतिहास

जन्म

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

2015 के मध्य में, हमने पाठ्यक्रम बदलने का फैसला किया और डेइस (उस समय इसका नाम बदलकर डेस वर्कफ़्लो रखा गया) को फ्लीट से कुबेरनेट्स में स्थानांतरित कर दिया। पुन: डिज़ाइन किए जाने वाले पहले में से एक इंस्टॉलेशन टूल था। deisctl. हमने इसका उपयोग फ्लीट क्लस्टर में डेस वर्कफ़्लो को स्थापित और प्रबंधित करने के लिए किया।

हेल्म 1 को होमब्रू, एपीटी और यम जैसे प्रसिद्ध पैकेज प्रबंधकों की छवि में बनाया गया था। इसका मुख्य लक्ष्य कुबेरनेट्स पर पैकेजिंग और एप्लिकेशन इंस्टॉल करने जैसे कार्यों को सरल बनाना था। हेल्म को आधिकारिक तौर पर 2015 में सैन फ्रांसिस्को में क्यूबकॉन सम्मेलन में पेश किया गया था।

हेल्म के साथ हमारा पहला प्रयास सफल रहा, लेकिन यह कुछ गंभीर सीमाओं के बिना नहीं था। उन्होंने परिचयात्मक YAML ब्लॉक के रूप में जनरेटर के साथ सुगंधित कुबेरनेट्स मैनिफ़ेस्ट का एक सेट लिया (प्रस्तावना)*, और परिणामों को कुबेरनेट्स में लोड किया।

* टिप्पणी। अनुवाद।: हेल्म के पहले संस्करण से, कुबेरनेट्स संसाधनों का वर्णन करने के लिए YAML सिंटैक्स को चुना गया था, और कॉन्फ़िगरेशन लिखते समय जिंजा टेम्पलेट्स और पायथन स्क्रिप्ट का समर्थन किया गया था। हमने इसके बारे में और सामान्य तौर पर हेल्म के पहले संस्करण की संरचना के बारे में "हेल्म का संक्षिप्त इतिहास" अध्याय में लिखा है। पदार्थ.

उदाहरण के लिए, YAML फ़ाइल में किसी फ़ील्ड को बदलने के लिए, आपको निम्नलिखित निर्माण को मेनिफेस्ट में जोड़ना होगा:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

यह बहुत अच्छी बात है कि टेम्पलेट इंजन आज भी मौजूद हैं, है ना?

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

पिछली गलतियों के अनुभव के आधार पर, हमने हेल्म 2 का विकास शुरू किया।

हेल्म बनाना 2

2015 के अंत में, Google टीम ने हमसे संपर्क किया। वे कुबेरनेट्स के लिए एक समान टूल पर काम कर रहे थे। कुबेरनेट्स के लिए परिनियोजन प्रबंधक एक मौजूदा टूल का एक पोर्ट था जिसका उपयोग Google क्लाउड प्लेटफ़ॉर्म के लिए किया गया था। "क्या हम चाहेंगे," उन्होंने पूछा, "समानताओं और अंतरों पर चर्चा करते हुए कुछ दिन बिताएं?"

जनवरी 2016 में, हेल्म और परिनियोजन प्रबंधक टीमों ने विचारों का आदान-प्रदान करने के लिए सिएटल में मुलाकात की। वार्ता एक महत्वाकांक्षी योजना के साथ समाप्त हुई: हेल्म 2 बनाने के लिए दोनों परियोजनाओं को संयोजित करना। डेस और गूगल के साथ, लोग स्किपबॉक्स (अब बिटनामी का हिस्सा - लगभग अनुवाद।), और हमने हेल्म 2 पर काम करना शुरू कर दिया।

हम हेल्म के उपयोग को आसान बनाए रखना चाहते थे, लेकिन निम्नलिखित जोड़ें:

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

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

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

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

टिलर को भावपूर्ण विदाई

हेल्म 2 के विकास के दौरान, हमने Google के परिनियोजन प्रबंधक के साथ अपने एकीकरण के हिस्से के रूप में टिलर को पेश किया। टिलर ने एक सामान्य क्लस्टर के भीतर काम करने वाली टीमों के लिए एक महत्वपूर्ण भूमिका निभाई: इसने बुनियादी ढांचे का संचालन करने वाले विभिन्न विशेषज्ञों को रिलीज के एक ही सेट के साथ बातचीत करने की अनुमति दी।

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

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

टिलर का मुख्य लक्ष्य टिलर के बिना हासिल किया जा सकता था, इसलिए हेल्म 3 के संबंध में हमारा पहला निर्णय टिलर को पूरी तरह से त्यागना था।

टिलर के चले जाने से, हेल्म का सुरक्षा मॉडल मौलिक रूप से सरल हो गया है। हेल्म 3 अब वर्तमान कुबेरनेट्स की सभी आधुनिक सुरक्षा, पहचान और प्राधिकरण विधियों का समर्थन करता है। हेल्म अनुमतियाँ का उपयोग करके निर्धारित की जाती हैं kubeconfig फ़ाइल. क्लस्टर प्रशासक उपयोगकर्ता अधिकारों को किसी भी स्तर की विस्तृतता तक सीमित कर सकते हैं। रिलीज़ अभी भी क्लस्टर के भीतर सहेजे गए हैं, और हेल्म की बाकी कार्यक्षमता बरकरार है।

चार्ट भंडार

उच्च स्तर पर, चार्ट रिपॉजिटरी एक ऐसा स्थान है जहां चार्ट संग्रहीत और साझा किए जा सकते हैं। हेल्म क्लाइंट पैकेज करता है और चार्ट को रिपॉजिटरी में भेजता है। सीधे शब्दों में कहें तो, एक चार्ट रिपॉजिटरी एक आदिम HTTP सर्वर है जिसमें एक Index.yaml फ़ाइल और कुछ पैकेज्ड चार्ट होते हैं।

जबकि अधिकांश बुनियादी भंडारण आवश्यकताओं को पूरा करने वाले चार्ट रिपोजिटरी एपीआई के कुछ फायदे हैं, वहीं कुछ नुकसान भी हैं:

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

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

लेकिन क्या आप जानते हैं कि वितरण परियोजना को केवल कंटेनर छवियों को ही नहीं, बल्कि किसी भी प्रकार की सामग्री को वितरित करने के लिए डिज़ाइन किया गया था?

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

हेल्म चार्ट रिपॉजिटरी में कुछ आगामी परिवर्तनों का अधिक विस्तृत विवरण उपलब्ध है по ссылке.

रिहाई प्रबंधन

हेल्म 3 में, एप्लिकेशन स्थिति को ऑब्जेक्ट की एक जोड़ी द्वारा क्लस्टर के भीतर ट्रैक किया जाता है:

• रिलीज़ ऑब्जेक्ट - एक एप्लिकेशन इंस्टेंस का प्रतिनिधित्व करता है;
• रिलीज़ संस्करण रहस्य - किसी विशिष्ट समय पर एप्लिकेशन की वांछित स्थिति का प्रतिनिधित्व करता है (उदाहरण के लिए, एक नए संस्करण की रिलीज़)।

कॉल helm install एक रिलीज़ ऑब्जेक्ट और रिलीज़ संस्करण रहस्य बनाता है। पुकारना helm upgrade एक रिलीज़ ऑब्जेक्ट की आवश्यकता होती है (जिसे वह बदल सकता है) और एक नया रिलीज़ संस्करण रहस्य बनाता है जिसमें नए मान और एक तैयार मेनिफेस्ट होता है।

रिलीज़ ऑब्जेक्ट में रिलीज़ के बारे में जानकारी होती है, जहाँ रिलीज़ नामित चार्ट और मानों की एक विशिष्ट स्थापना है। यह ऑब्जेक्ट रिलीज़ के बारे में शीर्ष-स्तरीय मेटाडेटा का वर्णन करता है। रिलीज़ ऑब्जेक्ट एप्लिकेशन के पूरे जीवनचक्र में बना रहता है और सभी रिलीज़ संस्करण रहस्यों का स्वामी होता है, साथ ही सभी ऑब्जेक्ट जो सीधे हेल्म चार्ट द्वारा बनाए जाते हैं।

रिलीज़ संस्करण रहस्य एक रिलीज़ को संशोधनों (इंस्टॉलेशन, अपडेट, रोलबैक, विलोपन) की एक श्रृंखला के साथ जोड़ता है।

हेल्म 2 में, संशोधन बेहद सुसंगत थे। पुकारना helm install v1 बनाया गया, अगला अद्यतन (अपग्रेड) - v2, इत्यादि। रिलीज़ और रिलीज़ संस्करण रहस्य को एक ही ऑब्जेक्ट में संक्षिप्त कर दिया गया है जिसे संशोधन के रूप में जाना जाता है। संशोधनों को टिलर के समान नामस्थान में संग्रहीत किया गया था, जिसका अर्थ था कि प्रत्येक रिलीज़ नामस्थान के संदर्भ में "वैश्विक" थी; परिणामस्वरूप, नाम का केवल एक उदाहरण उपयोग किया जा सका।

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

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

चार्ट निर्भरता में परिवर्तन

चार्ट पैक किए गए (उपयोग करके)। helm package) हेल्म 2 के साथ उपयोग के लिए हेल्म 3 के साथ स्थापित किया जा सकता है, हालांकि चार्ट विकास वर्कफ़्लो को पूरी तरह से बदल दिया गया है, इसलिए हेल्म 3 के साथ चार्ट विकास जारी रखने के लिए कुछ बदलाव किए जाने चाहिए। विशेष रूप से, चार्ट निर्भरता प्रबंधन प्रणाली बदल गई है।

चार्ट की निर्भरता प्रबंधन प्रणाली स्थानांतरित हो गई है requirements.yaml и requirements.lock पर Chart.yaml и Chart.lock. इसका मतलब यह है कि जो चार्ट कमांड का उपयोग करते हैं helm dependency, हेल्म 3 में काम करने के लिए कुछ सेटअप की आवश्यकता है।

आइए एक उदाहरण देखें. आइए हेल्म 2 में चार्ट में एक निर्भरता जोड़ें और देखें कि हेल्म 3 पर जाने पर क्या परिवर्तन होता है।

हेल्म 2 में requirements.yaml इस तरह देखा:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

हेल्म 3 में वही निर्भरता आपमें प्रतिबिंबित होगी Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

चार्ट अभी भी डाउनलोड किए गए हैं और निर्देशिका में रखे गए हैं charts/, तो उपचार्ट (उपचार्ट), कैटलॉग में पड़ा हुआ है charts/, बिना बदलाव के काम करना जारी रखेगा।

लाइब्रेरी चार्ट का परिचय

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

लाइब्रेरी चार्ट अनुभाग में घोषित किए गए हैं dependencies फाइल मैं Chart.yaml. उन्हें स्थापित करना और प्रबंधित करना अन्य चार्ट से अलग नहीं है।

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

हम उन उपयोग के मामलों को लेकर उत्साहित हैं जो यह घटक चार्ट डेवलपर्स के लिए खोलेगा, साथ ही लाइब्रेरी चार्ट से निकलने वाली सर्वोत्तम प्रथाओं के बारे में भी।

आगे क्या है?

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

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

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

यदि आपको लगता है कि हमसे कुछ छूट गया है, तो हमें आपके विचार सुनना अच्छा लगेगा!

हमारी चर्चा में शामिल हों सुस्त चैनल:

• #helm-users समुदाय के साथ प्रश्नों और सरल संचार के लिए;
• #helm-dev पुल अनुरोधों, कोड और बग पर चर्चा करने के लिए।

आप गुरुवार को 19:30 एमएसके पर हमारे साप्ताहिक सार्वजनिक डेवलपर कॉल में भी चैट कर सकते हैं। बैठकें उन मुद्दों पर चर्चा करने के लिए समर्पित हैं जिन पर प्रमुख डेवलपर्स और समुदाय काम कर रहे हैं, साथ ही सप्ताह के लिए चर्चा के विषय भी हैं। बैठक में कोई भी शामिल होकर हिस्सा ले सकता है. लिंक स्लैक चैनल में उपलब्ध है #helm-dev.

अनुवादक से पी.एस

हमारे ब्लॉग पर भी पढ़ें:

• «कुबेरनेट्स के लिए पैकेज मैनेजर - हेल्म: अतीत, वर्तमान, भविष्य";
• «हेल्म 2 पर एक गंभीर नज़र: "यही तो है..."";
• «कुबेरनेट्स के लिए पैकेज मैनेजर का व्यावहारिक परिचय - हेल्म";
• «कुबेरनेट्स टिप्स और ट्रिक्स: क्लस्टर में चल रहे संसाधनों को हेल्म 2 प्रबंधन में स्थानांतरित करना";
• «डैप के साथ अभ्यास करें. भाग 2. हेल्म का उपयोग करके कुबेरनेट्स में डॉकर छवियों को तैनात करना'.

स्रोत: www.habr.com