हेल्म 3 सादर करत आहे

नोंद. अनुवाद: या वर्षाचा 16 मे हा कुबर्नेट्स - हेल्मसाठी पॅकेज मॅनेजरच्या विकासातील एक महत्त्वाचा टप्पा आहे. या दिवशी, प्रकल्पाच्या भविष्यातील प्रमुख आवृत्तीचे पहिले अल्फा रिलीझ - 3.0 - सादर केले गेले. त्याचे प्रकाशन हेल्ममध्ये महत्त्वपूर्ण आणि दीर्घ-प्रतीक्षित बदल घडवून आणेल, ज्यासाठी कुबरनेट समुदायातील अनेकांना मोठ्या आशा आहेत. आम्ही स्वतः यापैकी एक आहोत, कारण आम्ही हेल्म हे ऍप्लिकेशन डिप्लॉयमेंटसाठी सक्रियपणे वापरतो: आम्ही ते CI/CD लागू करण्यासाठी आमच्या टूलमध्ये समाकलित केले आहे. werf आणि आम्ही वेळोवेळी अपस्ट्रीमच्या विकासासाठी आमचे योगदान देत असतो. हे भाषांतर अधिकृत हेल्म ब्लॉगवरील 7 नोट्स एकत्र करते, जे हेल्म 3 च्या पहिल्या अल्फा प्रकाशनासाठी समर्पित आहेत आणि प्रकल्पाच्या इतिहासाबद्दल आणि हेल्म 3 च्या मुख्य वैशिष्ट्यांबद्दल बोलतात. त्यांचे लेखक मॅट “बॅकनगोब्बलर” फिशर आहेत, मायक्रोसॉफ्टचे कर्मचारी आणि हेल्मच्या मुख्य देखभालकर्त्यांपैकी एक.

15 ऑक्टोबर 2015 रोजी, आता हेल्म म्हणून ओळखल्या जाणार्‍या प्रकल्पाचा जन्म झाला. त्याच्या स्थापनेनंतर फक्त एक वर्षानंतर, हेल्म समुदाय कुबर्नेट्समध्ये सामील झाला, हेल्म 2 वर सक्रियपणे काम करत असताना, जून 2018 मध्ये, हेल्म CNCF मध्ये सामील झाले विकसनशील (उष्मायन) प्रकल्प म्हणून. वर्तमानात जलद पुढे जा, आणि नवीन हेल्म 3 चे पहिले अल्फा रिलीज होण्याच्या मार्गावर आहे. (हे प्रकाशन आधीच झाले आहे मध्य मे मध्ये - अंदाजे. अनुवाद.).

या भागामध्ये, हे सर्व कोठून सुरू झाले, आज आपण जिथे आहोत तिथे कसे पोहोचलो, हेल्म 3 च्या पहिल्या अल्फा रिलीझमध्ये उपलब्ध असलेल्या काही वैशिष्ट्यांचा परिचय करून देईन आणि पुढे जाण्याची आमची योजना कशी आहे हे मी सांगेन.

सारांश:

• हेल्मच्या निर्मितीचा इतिहास;
• टिलरला एक निविदा निरोप;
• चार्ट रेपॉजिटरीज;
• प्रकाशन व्यवस्थापन;
• चार्ट अवलंबनांमध्ये बदल;
• लायब्ररी चार्ट;
• पुढे काय?

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

जन्म

हेल्म 1 हा Deis द्वारे तयार केलेला मुक्त स्त्रोत प्रकल्प म्हणून सुरुवात केली. आम्ही एक छोटेसे स्टार्टअप होतो शोषून घेतले वसंत ऋतु 2017 मध्ये मायक्रोसॉफ्ट. आमच्‍या इतर ओपन सोर्स प्रोजेक्‍टचे, त्‍याचे नावही Deis आहे, यात एक टूल होते deisctl, ज्याचा वापर (इतर गोष्टींबरोबरच) मध्ये Deis प्लॅटफॉर्म स्थापित आणि ऑपरेट करण्यासाठी केला गेला फ्लीट क्लस्टर. त्या वेळी, फ्लीट हे कंटेनर ऑर्केस्ट्रेशन प्लॅटफॉर्मपैकी एक होते.

2015 च्या मध्यात, आम्ही अभ्यासक्रम बदलण्याचा निर्णय घेतला आणि Deis (त्यावेळी Deis Workflow चे नाव बदलून) Fleet वरून Kubernetes वर हलवले. पुन्हा डिझाइन केलेले पहिले एक स्थापना साधन होते. deisctl. आम्ही ते फ्लीट क्लस्टरमध्ये Deis Workflow स्थापित आणि व्यवस्थापित करण्यासाठी वापरले.

हेल्म 1 हे होमब्रू, ऍप्ट आणि यम सारख्या प्रसिद्ध पॅकेज व्यवस्थापकांच्या प्रतिमेमध्ये तयार केले गेले. कुबर्नेट्सवर पॅकेजिंग आणि ऍप्लिकेशन्स स्थापित करणे यासारखी कार्ये सुलभ करणे हे त्याचे मुख्य ध्येय होते. 2015 मध्ये सॅन फ्रान्सिस्कोमधील कुबेकॉन कॉन्फरन्समध्ये हेल्मची अधिकृतपणे ओळख झाली.

हेल्मसोबतचा आमचा पहिला प्रयत्न यशस्वी झाला, पण तो काही गंभीर मर्यादांशिवाय नव्हता. त्याने कुबर्नेट्स मॅनिफेस्टचा एक संच घेतला, ज्याचा परिचय YAML ब्लॉक्स म्हणून जनरेटरसह केला होता (समोरची गोष्ट)*, आणि Kubernetes मध्ये परिणाम लोड केले.

* नोंद. अनुवाद: हेल्मच्या पहिल्या आवृत्तीपासून, YAML सिंटॅक्स कुबर्नेट्स संसाधनांचे वर्णन करण्यासाठी निवडले गेले आणि कॉन्फिगरेशन लिहिताना जिन्जा टेम्पलेट्स आणि पायथन स्क्रिप्ट्सना समर्थन दिले. आम्ही याबद्दल अधिक लिहिले आणि सामान्यतः हेल्मच्या पहिल्या आवृत्तीच्या संरचनेबद्दल "हेल्मचा संक्षिप्त इतिहास" या अध्यायात लिहिले. हे साहित्य.

उदाहरणार्थ, YAML फाइलमधील फील्ड बदलण्यासाठी, तुम्हाला मॅनिफेस्टमध्ये खालील रचना जोडणे आवश्यक आहे:

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

आज टेम्पलेट इंजिन अस्तित्वात आहेत हे छान आहे, नाही का?

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

मागील चुकांच्या अनुभवावर आधारित, आम्ही हेल्म 2 विकसित करण्यास सुरुवात केली.

हेल्म बनवणे 2

2015 च्या शेवटी, Google टीमने आमच्याशी संपर्क साधला. ते Kubernetes साठी समान साधन काम करत होते. Kubernetes साठी डिप्लॉयमेंट मॅनेजर हे विद्यमान टूलचे पोर्ट होते जे Google Cloud Platform साठी वापरले जात होते. "आम्हाला आवडेल का," त्यांनी विचारले, "काही दिवस साम्य आणि फरकांवर चर्चा करायला घालवायला?"

जानेवारी 2016 मध्ये, हेल्म आणि डिप्लॉयमेंट मॅनेजर टीम सिएटलमध्ये विचारांची देवाणघेवाण करण्यासाठी भेटली. वाटाघाटी एका महत्त्वाकांक्षी योजनेसह संपल्या: हेल्म 2 तयार करण्यासाठी दोन्ही प्रकल्प एकत्र करणे. Deis आणि Google सोबत, येथील लोक स्किपबॉक्स (आता बिटनामीचा भाग - अंदाजे अनुवाद.), आणि आम्ही हेल्म 2 वर काम करायला सुरुवात केली.

आम्हाला हेल्मचा वापर सुलभ ठेवायचा होता, परंतु पुढील गोष्टी जोडा:

• सानुकूलित करण्यासाठी चार्ट टेम्पलेट्स;
• संघांसाठी इंट्रा-क्लस्टर व्यवस्थापन;
• जागतिक दर्जाचे चार्ट रेपॉजिटरी;
• स्वाक्षरी पर्यायासह स्थिर पॅकेज स्वरूप;
• सिमेंटिक व्हर्जनिंग आणि आवृत्त्यांमधील बॅकवर्ड सुसंगतता राखण्यासाठी मजबूत वचनबद्धता.

ही उद्दिष्टे साध्य करण्यासाठी, हेल्म इकोसिस्टममध्ये दुसरा घटक जोडला गेला आहे. या इंट्रा-क्लस्टर घटकाला टिलर असे म्हणतात आणि हेल्म चार्ट स्थापित करण्यासाठी आणि त्यांचे व्यवस्थापन करण्यासाठी जबाबदार होते.

2 मध्ये हेल्म 2016 रिलीज झाल्यापासून, कुबर्नेट्सने अनेक प्रमुख नवकल्पना जोडल्या आहेत. भूमिका-आधारित प्रवेश नियंत्रण जोडले (RBAC), ज्याने अखेरीस विशेषता-आधारित प्रवेश नियंत्रण (ABAC) बदलले. नवीन संसाधन प्रकार सादर केले गेले (त्यावेळी उपयोजन अद्याप बीटामध्ये होते). सानुकूल संसाधन व्याख्या (मूळतः थर्ड पार्टी रिसोर्सेस किंवा टीपीआर म्हणतात) चा शोध लावला गेला. आणि सर्वात महत्त्वाचे म्हणजे, सर्वोत्तम पद्धतींचा एक संच उदयास आला आहे.

या सर्व बदलांदरम्यान, हेल्मने कुबर्नेट्सच्या वापरकर्त्यांना विश्वासूपणे सेवा देणे सुरू ठेवले. तीन वर्षांनंतर आणि अनेक नवीन जोडण्यांनंतर, हे स्पष्ट होते की हेल्म विकसित होत असलेल्या इकोसिस्टमच्या वाढत्या गरजा पूर्ण करणे सुरू ठेवू शकेल याची खात्री करण्यासाठी कोडबेसमध्ये महत्त्वपूर्ण बदल करण्याची वेळ आली आहे.

टिलरला एक निविदा निरोप

हेल्म 2 च्या विकासादरम्यान, आम्ही Google च्या उपयोजन व्यवस्थापकासह आमच्या एकत्रीकरणाचा भाग म्हणून टिलरची ओळख करून दिली. टिलरने एका सामान्य क्लस्टरमध्ये काम करणार्‍या संघांसाठी महत्त्वाची भूमिका बजावली: यामुळे इन्फ्रास्ट्रक्चर ऑपरेट करणार्‍या भिन्न तज्ञांना समान प्रकाशनांच्या संचाशी संवाद साधण्याची परवानगी दिली.

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

विशिष्ट परिस्थितींमध्ये समुदायाने हेल्मचा वापर कसा केला हे जाणून घेतल्यानंतर, आमच्या लक्षात आले की टिलरच्या रिलीझ व्यवस्थापन प्रणालीला रिलीझ माहितीसाठी राज्य किंवा केंद्रीय केंद्र म्हणून कार्य करण्यासाठी इंट्रा-क्लस्टर घटकावर अवलंबून राहण्याची आवश्यकता नाही. त्याऐवजी, आम्ही फक्त कुबर्नेट्स एपीआय सर्व्हरकडून माहिती प्राप्त करू शकतो, क्लायंटच्या बाजूने एक चार्ट तयार करू शकतो आणि कुबर्नेट्समध्ये स्थापनेचा रेकॉर्ड संग्रहित करू शकतो.

टिलरचे मुख्य उद्दिष्ट टिलरशिवाय साध्य करता आले असते, म्हणून हेल्म 3 संबंधी आमच्या पहिल्या निर्णयांपैकी एक म्हणजे टिलरचा पूर्णपणे त्याग करणे.

टिलर गेल्याने, हेल्मचे सुरक्षा मॉडेल मूलभूतपणे सोपे केले गेले आहे. Helm 3 आता सध्याच्या Kubernetes च्या सर्व आधुनिक सुरक्षा, ओळख आणि अधिकृतता पद्धतींना समर्थन देते. हेल्म परवानग्या वापरून निर्धारित केल्या जातात kubeconfig फाइल. क्लस्टर प्रशासक कोणत्याही स्तरावरील ग्रॅन्युलॅरिटीसाठी वापरकर्ता अधिकार प्रतिबंधित करू शकतात. रिलीझ अजूनही क्लस्टरमध्ये सेव्ह केले जातात आणि हेल्मची उर्वरित कार्यक्षमता अबाधित राहते.

चार्ट रेपॉजिटरीज

उच्च स्तरावर, चार्ट रेपॉजिटरी ही अशी जागा आहे जिथे चार्ट संग्रहित आणि सामायिक केले जाऊ शकतात. हेल्म क्लायंट पॅकेज करते आणि रेपॉजिटरीमध्ये चार्ट पाठवते. सोप्या भाषेत सांगायचे तर, चार्ट रेपॉजिटरी हा एक index.yaml फाइल आणि काही पॅकेज केलेले चार्ट असलेले एक आदिम HTTP सर्व्हर आहे.

जरी चार्ट रेपॉजिटरी API चे काही फायदे आहेत जे बहुतेक मूलभूत स्टोरेज आवश्यकता पूर्ण करतात, परंतु काही तोटे देखील आहेत:

• चार्ट रेपॉजिटरीज उत्पादन वातावरणात आवश्यक असलेल्या बहुतेक सुरक्षा अंमलबजावणीशी सुसंगत नाहीत. प्रमाणीकरण आणि अधिकृततेसाठी मानक API असणे उत्पादन परिस्थितींमध्ये अत्यंत महत्वाचे आहे.
• हेल्मची चार्ट प्रोव्हेंन्स टूल्स, चार्टची अखंडता आणि मूळता तपासण्यासाठी, स्वाक्षरी करण्यासाठी वापरली जातात, हे चार्ट प्रकाशन प्रक्रियेचा पर्यायी भाग आहेत.
• बहु-वापरकर्ता परिस्थितींमध्ये, समान सामग्री संचयित करण्यासाठी आवश्यक असलेल्या जागेच्या दुप्पट करून, समान चार्ट दुसर्‍या वापरकर्त्याद्वारे अपलोड केला जाऊ शकतो. या समस्येचे निराकरण करण्यासाठी अधिक स्मार्ट भांडार विकसित केले गेले आहेत, परंतु ते औपचारिक तपशीलाचा भाग नाहीत.
• शोध, मेटाडेटा संग्रहित करण्यासाठी आणि चार्ट पुनर्प्राप्त करण्यासाठी एकल अनुक्रमणिका फाइल वापरल्याने सुरक्षित बहु-वापरकर्ता अंमलबजावणी विकसित करणे कठीण झाले आहे.

प्रकल्प डॉकर वितरण (डॉकर रेजिस्ट्री v2 म्हणूनही ओळखले जाते) डॉकर रेजिस्ट्रीचा उत्तराधिकारी आहे आणि मूलत: डॉकर प्रतिमा पॅकेजिंग, शिपिंग, संचयित आणि वितरित करण्यासाठी साधनांचा संच म्हणून कार्य करते. अनेक मोठ्या क्लाउड सेवा वितरण-आधारित उत्पादने देतात. या वाढलेल्या लक्षाबद्दल धन्यवाद, वितरण प्रकल्पाला अनेक वर्षांच्या सुधारणा, सुरक्षितता सर्वोत्तम पद्धती आणि फील्ड चाचणीचा फायदा झाला आहे ज्यामुळे तो मुक्त स्त्रोत जगतातील सर्वात यशस्वी नसलेल्या नायकांपैकी एक बनला आहे.

परंतु तुम्हाला माहिती आहे का की वितरण प्रकल्प केवळ कंटेनर प्रतिमाच नव्हे तर कोणत्याही प्रकारची सामग्री वितरीत करण्यासाठी डिझाइन केले होते?

प्रयत्नांना धन्यवाद ओपन कंटेनर पुढाकार (किंवा OCI), हेल्म चार्ट कोणत्याही वितरण उदाहरणावर ठेवता येतात. सध्या ही प्रक्रिया प्रायोगिक आहे. संपूर्ण हेल्म 3 साठी आवश्यक लॉगिन समर्थन आणि इतर वैशिष्ट्ये हे काम प्रगतीपथावर आहे, परंतु OCI आणि वितरण कार्यसंघांनी गेल्या काही वर्षांत केलेल्या शोधांमधून शिकण्यास आम्ही उत्सुक आहोत. आणि त्यांच्या मार्गदर्शन आणि मार्गदर्शनाद्वारे, आम्ही मोठ्या प्रमाणावर उपलब्ध सेवा ऑपरेट करणे काय असते हे शिकतो.

हेल्म चार्ट रेपॉजिटरीजमधील काही आगामी बदलांचे अधिक तपशीलवार वर्णन उपलब्ध आहे दुवा.

प्रकाशन व्यवस्थापन

हेल्म 3 मध्ये, क्लस्टरमध्ये ऑब्जेक्ट्सच्या जोडीद्वारे अनुप्रयोग स्थितीचा मागोवा घेतला जातो:

• रिलीझ ऑब्जेक्ट - अनुप्रयोग उदाहरण दर्शवते;
• रिलीझ आवृत्ती गुप्त - विशिष्ट वेळी अनुप्रयोगाची इच्छित स्थिती दर्शवते (उदाहरणार्थ, नवीन आवृत्तीचे प्रकाशन).

आव्हान helm install रिलीझ ऑब्जेक्ट आणि रिलीझ आवृत्ती गुप्त तयार करते. कॉल करा helm upgrade रिलीझ ऑब्जेक्टची आवश्यकता आहे (जे ते बदलू शकते) आणि नवीन मूल्ये आणि तयार मॅनिफेस्ट असलेले नवीन रिलीज व्हर्जन सिक्रेट तयार करते.

रिलीझ ऑब्जेक्टमध्ये रिलीझबद्दल माहिती असते, जेथे रिलीझ हे नामांकित चार्ट आणि मूल्यांची विशिष्ट स्थापना असते. हा ऑब्जेक्ट रिलीझबद्दल उच्च-स्तरीय मेटाडेटा वर्णन करतो. रिलीझ ऑब्जेक्ट ऍप्लिकेशनच्या संपूर्ण जीवनचक्रामध्ये टिकून राहतो आणि सर्व रिलीझ आवृत्ती रहस्ये तसेच हेल्म चार्टद्वारे थेट तयार केलेल्या सर्व ऑब्जेक्ट्सचा मालक असतो.

रिलीझ आवृत्ती गुप्त रिलीझ पुनरावृत्तींच्या मालिकेसह संबद्ध करते (स्थापना, अद्यतने, रोलबॅक, हटवणे).

हेल्म 2 मध्ये, आवर्तने अत्यंत सुसंगत होती. कॉल करा helm install v1 तयार केले, त्यानंतरचे अपडेट (अपग्रेड) - v2, आणि असेच. रिलीझ आणि रिलीझ आवृत्तीचे रहस्य पुनरावृत्ती म्हणून ओळखल्या जाणार्‍या एकाच ऑब्जेक्टमध्ये संकुचित केले गेले आहे. टिलर सारख्याच नेमस्पेसमध्ये पुनरावृत्ती संग्रहित केल्या गेल्या, ज्याचा अर्थ प्रत्येक प्रकाशन नेमस्पेसच्या दृष्टीने "जागतिक" होते; परिणामी, नावाचा फक्त एकच प्रसंग वापरला जाऊ शकतो.

हेल्म 3 मध्ये, प्रत्येक रिलीझ एक किंवा अधिक रिलीझ आवृत्ती रहस्यांशी संबंधित आहे. रिलीझ ऑब्जेक्ट नेहमी Kubernetes वर तैनात वर्तमान प्रकाशन वर्णन. प्रत्येक रिलीझ आवृत्तीचे रहस्य त्या प्रकाशनाच्या फक्त एका आवृत्तीचे वर्णन करते. एक अपग्रेड, उदाहरणार्थ, नवीन रिलीझ आवृत्ती गुप्त तयार करेल आणि नंतर त्या नवीन आवृत्तीकडे निर्देशित करण्यासाठी रिलीझ ऑब्जेक्ट बदलेल. रोलबॅकच्या बाबतीत, तुम्ही रिलीझला मागील स्थितीत परत आणण्यासाठी मागील रिलीझ आवृत्ती रहस्ये वापरू शकता.

टिलर सोडून दिल्यानंतर, हेल्म 3 रिलीझ प्रमाणेच नेमस्पेसमध्ये डेटा रिलीझ करते. हा बदल तुम्हाला वेगळ्या नेमस्पेसमध्ये समान रिलीझ नावासह चार्ट स्थापित करण्याची परवानगी देतो आणि डेटा क्लस्टर अपडेट्स/रीबूट मधील etcd मध्ये सेव्ह केला जातो. उदाहरणार्थ, तुम्ही "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

चार्ट डेव्हलपरसाठी हा घटक कोणत्या वापराच्या केसेस उघडेल, तसेच लायब्ररी चार्टमधून उद्भवू शकणार्‍या सर्वोत्तम पद्धतींबद्दल आम्ही उत्सुक आहोत.

पुढील काय आहे?

Helm 3.0.0-alpha.1 हा पाया आहे ज्यावर आम्ही Helm ची नवीन आवृत्ती तयार करण्यास सुरुवात करतो. लेखात मी हेल्म 3 च्या काही मनोरंजक वैशिष्ट्यांचे वर्णन केले आहे. त्यापैकी बरेच अद्याप विकासाच्या सुरुवातीच्या टप्प्यात आहेत आणि हे सामान्य आहे; अल्फा रिलीजचा मुद्दा म्हणजे कल्पनेची चाचणी घेणे, सुरुवातीच्या वापरकर्त्यांकडून अभिप्राय गोळा करणे आणि आमच्या गृहितकांची पुष्टी करणे.

अल्फा आवृत्ती प्रसिद्ध होताच (लक्षात ठेवा की हे आहे आधीच झाले आहे - अंदाजे अनुवाद.), आम्ही समुदायाकडून हेल्म 3 साठी पॅच स्वीकारण्यास सुरुवात करू. तुम्‍हाला एक मजबूत पाया तयार करण्‍याची आवश्‍यकता आहे जी नवीन कार्यक्षमतेचा विकास आणि अवलंब करण्‍याची अनुमती देईल आणि वापरकर्त्‍यांना तिकिटे उघडून आणि निराकरणे करून प्रक्रियेत सामील वाटेल.

मी हेल्म 3 मध्ये येणार्‍या काही प्रमुख सुधारणा हायलाइट करण्याचा प्रयत्न केला आहे, परंतु ही यादी कोणत्याही प्रकारे संपूर्ण नाही. हेल्म 3 साठी पूर्ण रोडमॅपमध्ये सुधारित अपडेट धोरणे, OCI नोंदणीसह सखोल एकीकरण आणि चार्ट मूल्ये प्रमाणित करण्यासाठी JSON स्कीमाचा वापर यासारख्या वैशिष्ट्यांचा समावेश आहे. गेल्या तीन वर्षांपासून दुर्लक्षित राहिलेल्या कोडबेसची साफसफाई आणि त्यातील काही भाग अपडेट करण्याचीही आमची योजना आहे.

जर तुम्हाला वाटत असेल की आमच्याकडून काहीतरी चुकले आहे, तर आम्हाला तुमचे विचार ऐकायला आवडेल!

आमच्या चर्चेत सामील व्हा स्लॅक चॅनेल:

• #helm-users प्रश्नांसाठी आणि समाजाशी साध्या संवादासाठी;
• #helm-dev पुल विनंत्या, कोड आणि बग्सवर चर्चा करण्यासाठी.

तुम्ही आमच्या साप्ताहिक सार्वजनिक विकसक कॉल्समध्ये गुरुवारी 19:30 MSK वाजता चॅट देखील करू शकता. मुख्य विकासक आणि समुदाय ज्या मुद्द्यांवर काम करत आहेत, तसेच आठवड्यातील चर्चेच्या विषयांवर चर्चा करण्यासाठी मीटिंग समर्पित आहे. मीटिंगमध्ये कोणीही सहभागी होऊ शकतो आणि भाग घेऊ शकतो. स्लॅक चॅनेलमध्ये लिंक उपलब्ध आहे #helm-dev.

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर देखील वाचा:

• «कुबर्नेट्ससाठी पॅकेज व्यवस्थापक - हेल्म: भूतकाळ, वर्तमान, भविष्य";
• «हेल्म 2 वर एक शांत दृष्टीक्षेप: "हे असे आहे..."";
• «कुबर्नेट्स - हेल्मसाठी पॅकेज मॅनेजरचा व्यावहारिक परिचय";
• «Kubernetes टिपा आणि युक्त्या: हेल्म 2 व्यवस्थापनामध्ये क्लस्टरमध्ये चालू असलेली संसाधने हस्तांतरित करणे";
• «डॅप सह सराव करा. भाग 2. हेल्म वापरून डॉकर प्रतिमा कुबर्नेट्सवर तैनात करणे».

स्त्रोत: www.habr.com