हेलम ३ को परिचय दिँदै

नोट। अनुवाद।: यस वर्षको मे 16 ले Kubernetes - Helm को प्याकेज प्रबन्धकको विकासमा महत्त्वपूर्ण कोसेढुङ्गा हो। यस दिन, परियोजना को भविष्य प्रमुख संस्करण को पहिलो अल्फा रिलीज - 3.0 - प्रस्तुत गरिएको थियो। यसको रिलीजले हेल्ममा महत्त्वपूर्ण र लामो-प्रतीक्षित परिवर्तनहरू ल्याउनेछ, जसको लागि कुबेरनेट समुदायका धेरैले ठूलो आशा राखेका छन्। हामी आफै पनि यिनीहरू मध्ये एक हौं, किनकि हामीले एप्लिकेसन डिप्लोयमेन्टको लागि सक्रिय रूपमा हेल्म प्रयोग गर्छौं: हामीले यसलाई CI/CD लागू गर्नको लागि हाम्रो उपकरणमा एकीकृत गरेका छौं। वाफ र समय-समयमा हामी अपस्ट्रीमको विकासमा हाम्रो योगदान दिन्छौं। यो अनुवादले आधिकारिक हेल्म ब्लगबाट 7 नोटहरू संयोजन गर्दछ, जुन हेल्म 3 को पहिलो अल्फा रिलीजमा समर्पित छ र परियोजनाको इतिहास र हेल्म 3 को मुख्य विशेषताहरू बारे कुरा गर्दछ। तिनीहरूका लेखक म्याट "बेकनगोबलर" फिशर हुन्, एक माइक्रोसफ्ट कर्मचारी। र हेल्मको प्रमुख संरक्षकहरू मध्ये एक।

अक्टोबर 15, 2015 मा, अहिले हेल्म भनेर चिनिने परियोजनाको जन्म भएको थियो। यसको स्थापना भएको एक वर्षपछि, हेल्म समुदायले हेल्म २ मा सक्रिय रूपमा काम गर्दा कुबेरनेटमा सामेल भयो। जुन २०१८ मा, हेल्म CNCF मा सामेल हुनुभयो विकासशील (इन्क्यूबेटिङ) परियोजनाको रूपमा। वर्तमानमा छिटो अगाडि बढ्नुहोस्, र नयाँ हेलम 3 को पहिलो अल्फा रिलीज यसको बाटोमा छ। (यो रिलीज पहिले नै भएको छ मध्य मई मा - लगभग। अनुवाद।).

यस टुक्रामा, म यो सबै कहाँबाट सुरु भयो, हामी आज हामी कहाँ छौं भन्ने बारे कुरा गर्नेछु, Helm 3 को पहिलो अल्फा विमोचनमा उपलब्ध केही अद्वितीय विशेषताहरू परिचय गराउँछु, र हामी कसरी अगाडि बढ्ने योजना बनाउँछौं भनी व्याख्या गर्नेछु।

सारांश:

• हेलम को निर्माण को इतिहास;
• टिलरलाई टेन्डर विदाई;
• चार्ट भण्डारहरू;
• रिलीज व्यवस्थापन;
• चार्ट निर्भरता मा परिवर्तन;
• पुस्तकालय चार्ट;
• अब के?

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

जन्म

Helm 1 Deis द्वारा सिर्जना गरिएको खुला स्रोत परियोजनाको रूपमा सुरु भयो। हामी एउटा सानो स्टार्टअप थियौं अवशोषित वसन्त 2017 मा माइक्रोसफ्ट। हाम्रो अर्को खुला स्रोत परियोजना, जसलाई Deis पनि भनिन्छ, एउटा उपकरण थियो deisctl, जुन Deis प्लेटफर्म स्थापना र सञ्चालन गर्न (अन्य चीजहरू बीच) प्रयोग गरिएको थियो फ्लीट क्लस्टर। त्यस समयमा, फ्लीट पहिलो कन्टेनर आर्केस्ट्रा प्लेटफर्महरू मध्ये एक थियो।

2015 को मध्यमा, हामीले पाठ्यक्रम परिवर्तन गर्ने निर्णय गर्यौं र Deis (त्यस बेला Deis Workflow को नाम परिवर्तन गरी) Fleet बाट Kubernetes मा सारियो। पुन: डिजाइन गरिएको पहिलो मध्ये एक स्थापना उपकरण थियो। deisctl। हामीले यसलाई फ्लीट क्लस्टरमा Deis कार्यप्रवाह स्थापना र व्यवस्थापन गर्न प्रयोग गर्यौं।

Helm 1 प्रसिद्ध प्याकेज प्रबन्धकहरू जस्तै Homebrew, apt र yum को छविमा सिर्जना गरिएको थियो। यसको मुख्य लक्ष्य प्याकेजिङ्ग र Kubernetes मा अनुप्रयोगहरू स्थापना जस्ता कार्यहरू सरल बनाउनु थियो। हेल्मलाई सन् २०१५ मा सान फ्रान्सिस्कोमा भएको कुबेकन सम्मेलनमा आधिकारिक रूपमा प्रस्तुत गरिएको थियो।

हेल्मसँगको हाम्रो पहिलो प्रयासले काम गर्‍यो, तर यो केही गम्भीर सीमाहरू बिना थिएन। उसले कुबर्नेट्स म्यानिफेस्टहरूको सेट लियो, जसमा जेनेरेटरहरू परिचयात्मक YAML ब्लकहरू छन्। (अगाडिको कुरा)*, र Kubernetes मा परिणाम लोड।

* नोट। अनुवाद।: हेल्मको पहिलो संस्करणबाट, YAML वाक्यविन्यास Kubernetes स्रोतहरू वर्णन गर्न छनौट गरिएको थियो, र कन्फिगरेसनहरू लेख्दा Jinja टेम्प्लेटहरू र Python स्क्रिप्टहरू समर्थित थिए। हामीले यस बारे थप लेख्यौं र सामान्य रूपमा हेल्मको पहिलो संस्करणको संरचना "हेल्मको संक्षिप्त इतिहास" अध्यायमा। यो सामग्री.

उदाहरणका लागि, YAML फाइलमा फिल्ड प्रतिस्थापन गर्न, तपाईंले manifest मा निम्न निर्माण थप्नुपर्छ:

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

यो राम्रो छ कि टेम्प्लेट इन्जिनहरू आज अवस्थित छन्, हैन?

धेरै कारणहरूका लागि, यो प्रारम्भिक Kubernetes स्थापनाकर्तालाई manifest फाइलहरूको हार्ड-कोड गरिएको सूची चाहिन्छ र घटनाहरूको सानो, निश्चित अनुक्रम मात्र कार्यान्वयन गर्‍यो। यो प्रयोग गर्न धेरै गाह्रो थियो कि Deis Workflow R&D टोलीले आफ्नो उत्पादनलाई यस प्लेटफर्ममा स्थानान्तरण गर्ने प्रयास गर्दा कठिन समय थियो - यद्यपि, विचारको बीउ पहिले नै छरिएको थियो। हाम्रो पहिलो प्रयास एउटा ठूलो सिक्ने अवसर थियो: हामीले महसुस गर्यौं कि हामी हाम्रा प्रयोगकर्ताहरूका लागि दैनिक समस्याहरू समाधान गर्ने व्यावहारिक उपकरणहरू सिर्जना गर्ने बारे साँच्चै उत्साहित थियौं।

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

हेल्म बनाउँदै 2

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

जनवरी 2016 मा, हेल्म र डिप्लोइमेन्ट प्रबन्धक टोलीहरू विचारहरू आदानप्रदान गर्न सिएटलमा भेटे। वार्ताहरू एक महत्वाकांक्षी योजनाको साथ समाप्त भयो: हेल्म 2 सिर्जना गर्न दुवै परियोजनाहरू संयोजन गर्न। Deis र Google सँगसँगै, बाट केटाहरू SkippBox (अहिले बिटनामीको अंश - लगभग अनुवाद।), र हामीले Helm 2 मा काम गर्न थाल्यौं।

हामी हेल्मको प्रयोगमा सहजता राख्न चाहन्छौं, तर निम्न थप्नुहोस्:

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

यी लक्ष्यहरू प्राप्त गर्न, हेल्म इकोसिस्टममा दोस्रो तत्व थपिएको छ। यो इन्ट्रा-क्लस्टर कम्पोनेन्ट टिलर भनिन्थ्यो र हेल्म चार्टहरू स्थापना र व्यवस्थापन गर्न जिम्मेवार थियो।

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

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

टिलरलाई टेन्डर विदाई

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

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

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

टिलरको मुख्य लक्ष्य टिलर बिना नै हासिल गर्न सकिन्थ्यो, त्यसैले हेल्म ३ को सम्बन्धमा हाम्रो पहिलो निर्णय टिलरलाई पूर्ण रूपमा त्याग्नु थियो।

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

चार्ट भण्डारहरू

उच्च स्तरमा, चार्ट भण्डारण एउटा स्थान हो जहाँ चार्टहरू भण्डारण र साझेदारी गर्न सकिन्छ। हेल्म क्लाइन्ट प्याकेज गर्दछ र चार्टहरू भण्डारमा पठाउँछ। सरल भाषामा भन्नुपर्दा, चार्ट रिपोजिटरी index.yaml फाइल र केही प्याकेज गरिएका चार्टहरू भएको आदिम HTTP सर्भर हो।

जबकि त्यहाँ चार्ट रिपोजिटरी API को धेरै आधारभूत भण्डारण आवश्यकताहरू पूरा गर्ने केही फाइदाहरू छन्, त्यहाँ केही बेफाइदाहरू पनि छन्:

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

परियोजना डकर वितरण (डकर रजिस्ट्री v2 को रूपमा पनि चिनिन्छ) डकर रजिस्ट्रीको उत्तराधिकारी हो र अनिवार्य रूपमा डकर छविहरू प्याकेजिङ, ढुवानी, भण्डारण र डेलिभरीका लागि उपकरणहरूको सेटको रूपमा कार्य गर्दछ। धेरै ठूला क्लाउड सेवाहरूले वितरणमा आधारित उत्पादनहरू प्रस्ताव गर्छन्। यस बढ्दो ध्यानको लागि धन्यवाद, वितरण परियोजनाले वर्षौंका सुधारहरू, सुरक्षा उत्कृष्ट अभ्यासहरू, र क्षेत्र परीक्षणबाट लाभान्वित भएको छ जसले यसलाई खुला स्रोत संसारको सबैभन्दा सफल गुमनाम नायकहरू मध्ये एक बनाएको छ।

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

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

हेल्म चार्ट रिपोजिटरीहरूमा केही आगामी परिवर्तनहरूको थप विस्तृत विवरण उपलब्ध छ लिङ्क.

रिलीज व्यवस्थापन

हेल्म 3 मा, एप्लिकेसन स्टेट वस्तुहरूको जोडीद्वारा क्लस्टर भित्र ट्र्याक गरिएको छ:

• रिलीज वस्तु - एक अनुप्रयोग उदाहरण प्रतिनिधित्व गर्दछ;
• रिलीज संस्करण गोप्य - समय मा एक विशेष बिन्दु मा आवेदन को इच्छित स्थिति को प्रतिनिधित्व गर्दछ (उदाहरण को लागी, नयाँ संस्करण को रिलीज)।

चुनौती helm install रिलीज वस्तु र रिलीज संस्करण गोप्य सिर्जना गर्दछ। कल गर्नुहोस् helm upgrade एक रिलीज वस्तु चाहिन्छ (जुन यो परिवर्तन गर्न सक्छ) र नयाँ मान र तयार manifest समावेश नयाँ रिलीज संस्करण गोप्य सिर्जना गर्दछ।

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

रिलिज संस्करण गोप्यले संशोधनहरूको श्रृंखला (स्थापना, अद्यावधिकहरू, रोलब्याकहरू, मेटाउने) सँग रिलीजलाई सम्बद्ध गर्दछ।

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

हेल्म 3 मा, प्रत्येक रिलीज एक वा धेरै रिलीज संस्करण रहस्यहरूसँग सम्बन्धित छ। रिलीज वस्तुले सधैं Kubernetes मा तैनात हालको रिलीज वर्णन गर्दछ। प्रत्येक रिलीज संस्करण गोप्यले त्यो रिलीजको केवल एक संस्करणको वर्णन गर्दछ। अपग्रेडले, उदाहरणका लागि, नयाँ रिलीज संस्करण गोप्य सिर्जना गर्नेछ र त्यसपछि रिलीज वस्तुलाई नयाँ संस्करणमा देखाउन परिवर्तन गर्नेछ। रोलब्याकको अवस्थामा, तपाईंले अघिल्लो स्थितिमा रिलीजलाई रोल ब्याक गर्नको लागि अघिल्लो रिलीज संस्करण रहस्यहरू प्रयोग गर्न सक्नुहुन्छ।

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

चार्ट निर्भरताहरूमा परिवर्तनहरू

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

चार्टको निर्भरता व्यवस्थापन प्रणालीबाट सारियो requirements.yaml и requirements.lock मा Chart.yaml и Chart.lock। यसको अर्थ कमाण्ड प्रयोग गर्ने चार्टहरू helm dependency, Helm 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/, परिवर्तन बिना काम जारी रहनेछ।

पुस्तकालय चार्टहरू प्रस्तुत गर्दै

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

खण्डमा पुस्तकालय चार्टहरू घोषणा गरिएको छ dependencies फाइलमा Chart.yaml। तिनीहरूलाई स्थापना र व्यवस्थापन अन्य चार्टहरू भन्दा फरक छैन।

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

हामी यो कम्पोनेन्ट चार्ट विकासकर्ताहरूका लागि खुल्ने प्रयोगका केसहरूका साथै पुस्तकालय चार्टहरूबाट आउन सक्ने उत्कृष्ट अभ्यासहरूको बारेमा उत्साहित छौं।

के अर्को छ?

Helm 3.0.0-alpha.1 आधार हो जसमा हामी Helm को नयाँ संस्करण निर्माण गर्न सुरु गर्छौं। लेखमा मैले हेल्म ३ का केही रोचक विशेषताहरू वर्णन गरेको छु। तिनीहरूमध्ये धेरै अझै विकासको प्रारम्भिक चरणमा छन् र यो सामान्य छ; अल्फा रिलीजको बिन्दु विचार परीक्षण गर्न, प्रारम्भिक प्रयोगकर्ताहरूबाट प्रतिक्रिया सङ्कलन, र हाम्रो धारणा पुष्टि गर्न हो।

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

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

यदि तपाईंलाई हामीले केही छुटेको जस्तो लाग्छ भने, हामी तपाईंको विचारहरू सुन्न चाहन्छौं!

हाम्रो छलफलमा सामेल हुनुहोस् ढिलो च्यानलहरू:

• #helm-users समुदाय संग प्रश्न र सरल संचार को लागी;
• #helm-dev पुल अनुरोध, कोड र बगहरू छलफल गर्न।

तपाईं हाम्रो साप्ताहिक सार्वजनिक विकासकर्ता कलहरूमा बिहीबार 19:30 MSK मा कुराकानी गर्न सक्नुहुन्छ। बैठकहरू मुख्य विकासकर्ताहरू र समुदायले काम गरिरहेका मुद्दाहरू, साथै हप्ताको लागि छलफलका विषयहरू छलफल गर्न समर्पित छन्। बैठकमा जो कोही सहभागी हुन र भाग लिन सक्छन्। Slack च्यानलमा लिङ्क उपलब्ध छ #helm-dev.

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «Kubernetes को लागि प्याकेज प्रबन्धक - हेलम: अतीत, वर्तमान, भविष्य»;
• «हेल्म 2 मा एक शान्त नजर: "यो के हो ..."»;
• «Kubernetes - Helm को लागि प्याकेज प्रबन्धक को व्यावहारिक परिचय»;
• «Kubernetes सुझाव र युक्तिहरू: हेल्म 2 व्यवस्थापनमा क्लस्टरमा चलिरहेको स्रोतहरू स्थानान्तरण»;
• «Dapp संग अभ्यास गर्नुहोस्। भाग 2. हेल्म प्रयोग गरेर कुबेरनेटमा डकर छविहरू प्रयोग गर्दै"।

स्रोत: www.habr.com