Helm: प्रस्ताव: मूल्यों में टेम्पलेटिंग की अनुमति दें। yaml

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

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

इसलिए, उदाहरण के लिए, आप अपने value.yaml में myval: ${RELEASE_NAME}.foo.bar कर पाएंगे।

गोलांग पक्ष पर, यह os.Exand() को कॉल करने जितना आसान होना चाहिए, जिसमें चर की एक कस्टम सूची का विस्तार किया जाना चाहिए।

@seh के बिंदु पर, यह तय करना थोड़ा मुश्किल है कि आप विस्तार को चलाना चाहते हैं। मुझे लगता है कि मूल्यों को समेकित करने के बाद आप इसे करना चाहते हैं, लेकिन टेम्पलेट इंजन में मान भेजे जाने से पहले। यह इसके साथ चेतावनी लाएगा कि चर को अच्छी तरह से गठित वाईएएमएल के रूप में प्रदर्शित करना होगा। लेकिन मुझे लगता है कि यह व्यावहारिक है

@seh मैंने व्यक्तिगत रूप से इसे पहले विकल्प के करीब कुछ के रूप में कल्पना की, जिसमें शाब्दिक मूल्यों को प्रतिपादन से पहले टेम्पलेट में रखा गया है।

@technosophos ने दिया कि, मुझे लगता है कि आप जो सुझाव दे रहे हैं वह एक अच्छे समाधान की तरह लगता है।

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

मैं अभी इस विचार के खिलाफ बहस नहीं कर रहा हूँ; हमें केवल इस बात पर संदेह करने की आवश्यकता है कि ऊपर दिए गए @technosophos के सरल प्रतिस्थापन पर्याप्त होंगे।

लेकिन अगर यह value.yaml फ़ाइल के माध्यम से आ रहा है, तो परिवर्तन और सत्यापन अभी भी टेम्पलेट्स में हो सकता है, है ना? उदाहरण के लिए: myPort: ${port} को अभी भी इस तरह के टेम्पलेट में एक्सेस किया जा सकता है: {{ .myPort | int }} ।

बड़ी बाधा यह है कि values.yaml फ़ाइल हमेशा एक वैध YAML फ़ाइल होनी चाहिए।

यह वह बाधा है जो मेरे मन में थी: क्या होता है यदि "पोर्ट" चर मान रखता है

"ए

या कुछ अन्य अनुक्रम जो अमान्य वाईएएमएल बनाता है? जैसा कि आपने कहा, ध्यान में रखने के लिए वाक्य रचनात्मक बाधाएं हैं, हालांकि कोई उनके आसपास काम कर सकता है:

myport: '${port}'

ठीक है, इसलिए मूल्यों से बचना होगा या किसी तरह से उद्धृत करना होगा, उदाहरण के लिए value.yaml में:

portValue: "{{ .myPort | int }}"

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

शाब्दिक मूल्यों को मूल्यों से प्रक्षेपित करने का विचार। उदाहरण के लिए यह अपेक्षा के अनुरूप काम नहीं करेगा:

Values.yaml:

otherServiceName: "{{ .Release.Name }}-my-service"

परिनियोजन.yaml

otherService: {{ .Values.otherServiceName | lower }}

क्या पहले value.yaml को प्रक्षेपित करने में समस्याएं हैं (जाहिर है बिना पहुंच के .Values ) और फिर अन्य टेम्पलेट्स को प्रक्षेपित करने के लिए परिणामी value.yaml का उपयोग करना?

@braedon हां, कई समस्याएं हैं:

1. Values.yaml फ़ाइल को उसकी पार्स न की गई स्थिति में मान्य YAML होना चाहिए। यह टेम्पलेट निर्देशों पर दिलचस्प सीमाएं रखता है।
2. मान चरणों में मर्ज किए जाते हैं, और कुछ चरणों में टेम्प्लेट सबसिस्टम तक पहुंच नहीं होती है (अर्थात्, --सेट रिज़ॉल्यूशन, आवश्यकताएँ। yaml बाधाएँ, और -f मर्ज संचालन।)
3. टेम्प्लेट सिस्टम के कुछ हिस्सों को आरंभ करने से पहले सभी मानों की गणना की जानी चाहिए। अन्यथा, {{ define }} और {{ include }} अनुमानित रूप से काम नहीं करते हैं, और {{ template }} भी नहीं करते हैं।

अनिवार्य रूप से, एक env var सिंटैक्स values.yaml में एम्बेड करने के लिए काफी आसान है कि हम इसे बहुत जटिलता पेश किए बिना कर सकते हैं। लेकिन पूर्ण विकसित टेम्प्लेट का उपयोग करना एक प्रमुख उपक्रम है, और सफल होने पर भी इसका परिणाम बग रिपोर्ट की एक अंतहीन श्रृंखला में होगा जब लोग किनारे के मामलों को हिट करते हैं।

लेकिन मुझे कुछ याद आ रहा होगा... मैं ऊपर आपका उदाहरण समझ नहीं पा रहा हूं। क्या प्रस्तावित किया जा रहा है:

Values.yaml

otherServiceName: "${RELEASE_NAME}-my-service"

परिनियोजन.yaml

otherService: {{ .Values.otherServiceName | lower }}

संचालन के क्रम में रिलीज़ ऑब्जेक्ट बनने के बाद values.yaml रेंडर किया जाएगा, लेकिन टेम्प्लेट संकलित या रेंडर किए जाने से पहले। यदि रिलीज़ का नाम FOO है, तो उपरोक्त का परिणाम otherService: foo-my-service होगा।

@technosophos मैं किसी अन्य पार्सिंग/कोलेसिंग/आदि से पहले value.yaml फ़ाइलों पर टेम्पलेटिंग इंजन चलाने की कल्पना कर रहा था। फ़ाइलों का किया गया था (यदि यह सुविधा इसे नहीं बनाती है, तो मैंने मान उत्पन्न करने के लिए एक अलग टेम्पलेटिंग सिस्टम चलाने पर विचार किया है। यमल फाइलें फिर हेल्म में पास हो जाती हैं)।

ऐसा लगता है कि मुद्दों 1 और 2 से बचना चाहिए, और ग्रोक करने के लिए एक बहुत ही सहज प्रणाली होनी चाहिए? मुझे नहीं पता कि हेल्म के कोडबेस में इसे लागू करना कितना मुश्किल है, और 3 अभी भी एक मुद्दा होगा (सुनिश्चित नहीं है कि उन कार्यों को अस्वीकार करना कितना सीमित होगा?)

मेरे उदाहरण समाधान के संदर्भ में थे @seh और @benjigoldberg आपके प्रस्ताव के बजाय चर्चा कर रहे थे।
उनके प्रस्ताव में (यह मानते हुए कि मैंने इसे सही ढंग से समझा है) मेरे उदाहरण का परिणाम पहले पास के बाद होगा:

otherService: {{ .release.name }}-my-service

(अर्थात value.yaml से otherServiceName का कच्चा मूल्य परिनियोजन.yaml को पास किया जाएगा, और लोअरकेस किया जाएगा)
जो तब दूसरे पास के इरादे से नहीं चलेगा।

मैं जो सोच रहा था वह है:

यदि एक /templates/values.yaml फ़ाइल मौजूद है, तो तर्क यह है कि टेम्पलेट को रेंडर करने के लिए /values.yaml से वेरिएबल को पढ़ा जाए, और फिर रेंडर किया गया values.yaml अन्य सभी टेम्प्लेट के रेंडर होने से पहले पूरी तरह से अपने ऊपर ले लेता है। . दूसरे शब्दों में, /values.yaml टेम्पलेट को बूटस्ट्रैप करता है।

मैंने एक उपयोग के मामले में भी भाग लिया है जो मुझे लगता है कि इससे लाभ होगा। मुझे संदेह है कि यह @braedon के otherService उदाहरण के समान हो सकता है।

जिस समस्या में मैं चल रहा हूं वह यह है कि .Release.Name के माध्यम से किसी सेवा के नाम को ओवरराइड करते समय वर्तमान में $# values.yaml .Release.Name शामिल करना संभव नहीं है। इसके लिए उपयोग का मामला तब होता है जब पूरी तरह से डिकूप्ड चार्ट का निर्माण किया जाता है जिसे बाद में मूल चार्ट का उपयोग करके एक साथ तारित किया जा सकता है।

उदाहरण के लिए, एक इलास्टिक्स खोज चार्ट में इसकी values.yaml फ़ाइल में serviceNameOverride मान हो सकता है जो उपयोगकर्ता को सेवा नाम को ओवरराइड करने की अनुमति देगा। इसी तरह, किबाना चार्ट की values.yaml फ़ाइल में एक elasticsearch.host मान हो सकता है जिसका उपयोग उपयोगकर्ता इलास्टिक्स खोज क्लस्टर के स्थान को सेट करने के लिए कर सकता है। ये चार्ट एक दूसरे के कार्यान्वयन विवरण के बारे में कुछ नहीं जानते हैं। वे स्वतंत्र हैं और एक उपयोगकर्ता को, उदाहरण के लिए, मौजूदा इलास्टिक्स खोज क्लस्टर की निगरानी के लिए किबाना को तैनात करने की अनुमति देगा जो कि पतवार के साथ तैनात नहीं किया गया था।

आदर्श रूप से, इन स्वतंत्र चार्टों का उपयोग माता-पिता "इलास्टिक्स खोज-किबाना" चार्ट बनाने के लिए बिल्डिंग ब्लॉक्स के रूप में भी किया जा सकता है जो उन्हें सबचार्ट्स के माध्यम से "तार" करते हैं। पैरेंट चार्ट निम्नलिखित को values.yaml में सेट करके सेवाओं को एक साथ जोड़ देगा:

elasticsearch.serviceNameOverride: {{ .Release.Name }}-elasticsearch
kibana.elasticsearch.host: {{ .Release.Name }}-elasticsearch

वर्तमान में मूल्यों में {{ .Release.Name }} को शामिल किए बिना ऐसा करना संभव है, लेकिन यह असुविधाजनक है क्योंकि यह उपयोगकर्ता को प्रत्येक स्थापना के लिए मान फ़ाइल को बदले बिना एक ही नाम स्थान में एकाधिक "पैरेंट" चार्ट स्थापित करने से रोकेगा।

@alexbrand आप चर वाले मानों को प्रस्तुत करने के लिए tpl फ़ंक्शन का उपयोग कर सकते हैं:

Values.yaml

elasticsearch.serviceNameOverride: {{ .Release.Name }}-elasticsearch
kibana.elasticsearch.host: {{ .Release.Name }}-elasticsearch

टेम्पलेट.yaml:

name: {{.Values.elasticsearch.serviceNameOverride | quote | tpl }}

@eicnix ऐसा करने के लिए उपचार्ट में template.yaml पर नियंत्रण रखने की आवश्यकता है, और जहां कहीं भी इसकी आवश्यकता है, इसके लिए स्पष्ट रूप से समर्थन जोड़ना चाहते हैं।

मैं जो चाहता हूं वह मूल चार्ट लिखने का एक तरीका है जो सबचार्ट्स को ब्लैक बॉक्स के रूप में मानते हुए इस तरह का काम करता है। मुझे लगता है कि @alexbrand भी यही कह रहा था?

उपरोक्त किसी ने पहले ही tpl फ़ंक्शन का उल्लेख किया है जिसे हाल ही में जोड़ा गया था (#1978)। मैं कुछ जटिलताओं को गलत समझ सकता हूं जो यहां शामिल हैं, लेकिन मेरे उपयोग के मामले और ऊपर वर्णित कुछ अन्य लोगों के लिए, जो कुछ आवश्यक लगता है वह tpl या समकक्ष के माध्यम से मूल्यांकन करने वाले मूल्यों पर एक निहित पास है, टेम्पलेट्स को प्रस्तुत करने से पहले . (मुझे लगता है कि आपको पुनरावर्ती संदर्भों से निपटने के लिए, जब तक कोई परिवर्तन नहीं किया जाता है, तब तक आपको पास करना जारी रखना होगा।) मुझे लगता है कि आप इसे कमांड पर --expand-values तर्क के माध्यम से सक्षम करने की आवश्यकता कर सकते हैं। लाइन, लेकिन क्या इस तरह के समाधान के साथ कोई अन्य समस्या है?

@eicnix सुझाव के लिए धन्यवाद!

मैं टेम्पलेट में पाइपलाइन प्राप्त करने में असमर्थ था। yaml काम कर रहा था, लेकिन मेरे लिए नीचे का कार्यकर्ता (ऊपर value.yaml के साथ):

टेम्पलेट.yaml

name: {{ tpl .Values.elasticsearch.serviceNameOverride . }}

मुझे लगता है कि यह और #2133 एक ही मुद्दा है, बीटीडब्ल्यू। (सुनिश्चित नहीं है कि कौन सा खुला रखना सबसे अच्छा है।)

हम हेल्म सर्वर के 2.6.1 में ठीक प्रतीत होते हैं (लेकिन 2.3.0 में नहीं)

@obriensystems क्या आप उस विचार पर थोड़ा और विस्तार कर सकते हैं? :)

v2.6 के लिए इस प्रस्ताव के बारे में क्या ठीक लगता है लेकिन v2.3 में नहीं? शायद आप दूसरे टिकट की बात कर रहे हैं?

मुझे @travishaagen और @braedon द्वारा प्रस्तावित दृष्टिकोण पसंद है। मैं कई -f मानों का उपयोग करने की कल्पना भी कर सकता हूं। yaml तर्क, उदाहरण के लिए

हेल्म इंस्टॉल -f raw_values.yaml -tf value_rendered_with_templating.yaml ...

सबसे पहले यह raw_values.yaml पढ़ेगा जिसे वैध yaml होना होगा। फिर पतवार values_rendered_with_templating.yaml पढ़ेगा और इसे टेम्पलेट इंजन के माध्यम से चलाएगा जिसकी raw_values.yaml में चरों तक पहुंच है। रेंडर किए गए टेम्प्लेट को फिर अगले चरण में फीड किया जाता है और इसी तरह।

मैंने उपरोक्त कमांड लाइन में tf का उपयोग यह संकेत देने के लिए किया है कि यह एक मान फ़ाइल है जिसे उपयोग किए जाने से पहले टेम्पलेट्स के साथ प्रस्तुत किया जाना चाहिए। @travishaagen द्वारा प्रस्तावित फ़ाइल संरचना डिफ़ॉल्ट सेटअप होगी।

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

90d निष्क्रियता के बाद मुद्दे पुराने हो जाते हैं।
/remove-lifecycle stale के साथ समस्या को ताज़ा के रूप में चिह्नित करें।
अतिरिक्त 30d निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

अगर इस मुद्दे को अभी बंद करना सुरक्षित है तो कृपया इसे /close के साथ करें।

सिग-टेस्टिंग, कुबेरनेट्स/टेस्ट-इंफ्रा और/या फेजटा को फीडबैक भेजें।
/जीवनचक्र बासी

/निकालें-जीवनचक्र बासी

मुझे लगता है कि ऐसा करने के लिए जरूरी नहीं कि हम पतवार को जटिल करें। उदाहरण के लिए, एक साधारण टूल जैसे https://github.com/roboll/helmfile का उपयोग मूल्यों में टेम्पलेटिंग के लिए किया जा सकता है।

@मुमोशू मैं कुछ मामलों में भाग गया जहां मुझे values.yaml में रिलीज नाम तक पहुंच की आवश्यकता होगी (हाल ही में काफ्का चार्ट जिसे सेट किया जा सकता है कि आवश्यकता के रूप में ज़ूकीपर चार्ट का उपयोग न करें, लेकिन फिर जरूरत है Value के रूप में एक ज़ूकीपर स्थान, जो हमारे परिनियोजन में रिलीज़ नाम पर आधारित है ...) हालांकि मैं अभी तक कुछ अतिरिक्त टूलिंग की आवश्यकता नहीं चाहता हूं और इसे प्राप्त करने के लिए इसे अपने उपयोगकर्ताओं पर लागू करता हूं: मुस्कान:

@NicolasT अपना उपयोग-मामला साझा करने के लिए धन्यवाद

आप पहले से ही जानते होंगे लेकिन किसी के लिए अभी तक नहीं है - आप अपने ज़ूकीपर को एक ठोस नाम helm install incubator/zookeeper --name myzookeeper नाम दे सकते हैं और फिर उस नाम को काफ्का रिलीज के मूल्य के रूप में पुन: उपयोग कर सकते हैं।

और आपका उपयोग-मामला इस धागे में सुझाए गए समाधानों द्वारा समर्थित प्रतीत नहीं होता है। क्षमा करें यदि मैं आपका अनुसरण नहीं कर रहा हूँ, लेकिन आप किसी अन्य रिलीज़ के नाम को किसी अन्य, स्वतंत्र रिलीज़ से एक्सेस नहीं कर सकते हैं, है ना?

आपका "मानों में टेम्पलेटिंग की अनुमति देने" के बजाय "टेम्पलेट्स से संदर्भित किए जा सकने वाले विस्तार" के बारे में अधिक प्रतीत होता है।

हालांकि मैं चाहता हूं कि अभी तक कुछ अतिरिक्त टूलिंग की आवश्यकता न हो और इसे प्राप्त करने के लिए इसे अपने उपयोगकर्ताओं पर लागू करें

मैं और अधिक सहमत नहीं हो सकता
हर किसी के उपयोग के मामलों का समर्थन करने के लिए एक ऑल-इन-वन टूल वास्तव में एक गॉडसेंड होगा।

असल में, मैं एक बार कामना करता था कि क्या हेल्म एक घोषणात्मक वर्कफ़्लो प्रबंधक के साथ गतिशील सेवा निर्भरता संकल्प (आपका उपयोग केस) सुविधा जैसे एटलसियन/स्मिथ के साथ एकीकृत कर सकता है।

हेलम सीआरडी + स्मिथ के एक एकीकृत समाधान की कल्पना करें - क्या उम्मीद है कि आपकी समस्या का समाधान सुरुचिपूर्ण ढंग से होगा?

हालांकि, दूसरी तरफ, मुझे ऐसा लगता है कि एक गंभीर वर्कफ़्लो इंजन को अन्य उद्देश्यों के लिए एक उपकरण में एकीकृत/कार्यान्वित करना रखरखाव के संबंध में दुःस्वप्न होगा।

इसलिए, मैं चाहता हूं कि हेल्म कोर सरल रहे और हेल्म प्लगइन सिस्टम को "वैल्यूज ट्रांसफॉर्मर" जैसे एक्सटेंशन पॉइंट को सपोर्ट करने के लिए किसी तरह बढ़ाया जाए, जो एक से दूसरे में जाने से पहले वैल्यूज को संशोधित करने में सक्षम है। हम्म, हालांकि यह लगभग स्मिथ जैसा लगता है!

मेरा प्राथमिक उपयोग मामला #2506 है। सामान्य स्थिति में, मुझे पैकेज समय पर उन मूल्यों को जानने के बिना अपने स्वयं के मूल्यों को एक उपचार्ट में पास करने में सक्षम होने के लिए एक मूल चार्ट की आवश्यकता होती है।

नमस्कार गुरुओं, मैं इस चर्चा से भ्रमित हूँ। प्रस्तावित समाधान मेरे उपयोग के मामले की समस्या का समाधान नहीं कर सकता है:

मान.वाईएमएल:
ui_गुप्त:# यहां "{{tpl RandAlpha 8 }}" का उपयोग करने से त्रुटि की सूचना मिलती है।

टेम्पलेट1.वाईएमएल:
UI_SECRET: {{ .Values.ui_secret }}

टेम्पलेट2.वाईएमएल:
UI_SECRET: {{ .Values.ui_secret }}

मुझे पता है कि परम ui_secret को पतवार के बाहर उत्पन्न किया जा सकता है और इसे --set 'ui_secret=xxx' के माध्यम से पास किया जा सकता है। लेकिन क्यों न पतवार को एक डिफ़ॉल्ट यादृच्छिक मान उत्पन्न करने दिया जाए?
डिफ़ॉल्ट यादृच्छिक मान का उपयोग नमक/पासवर्ड/ca_certificate/certificate_pair, आदि के लिए किया जा सकता है।

लेकिन क्यों न पतवार को एक डिफ़ॉल्ट यादृच्छिक मान उत्पन्न करने दिया जाए?

नमस्ते! आप इसे कैसे हासिल करना चाहेंगे?

मेरे लिए, values.yaml में टेम्प्लेट करना इसे हल नहीं करता है। क्या होगा यदि आपके पास एक IMAGINARY value.yaml जैसे:

ui_secret: "{{ randAlpha 8 }}"

और आप helm upgrade --install yourrelease yourchart -f values.yaml कई बार चलाते हैं?
मेरे लिए, ui_secret को कब करना है/न करना है, तो हेलम/टिलर के लिए कोई रास्ता नहीं लगता है।

इसलिए, मेरा मानना ​​है कि आपको --set के माध्यम से एक पूर्व-निर्मित रहस्य प्रदान करना चाहिए, जैसा कि आपने उल्लेख किया है, भले ही यह प्रस्ताव स्वीकार किया गया हो या नहीं।

इसके बजाय, क्या आपके लिए k8s रहस्य के अंदर केवल एक यादृच्छिक मान उत्पन्न करना संभव होगा?
ताकि आपके हेलम चार्ट के माध्यम से बनाए गए सभी पॉड्स इसके नाम से रहस्य का उल्लेख कर सकें।

@मुमोशू अपग्रेड परिदृश्य के लिए:
1) यदि ui_secret value.yaml में सेट है, तो कोई प्रभाव नहीं;
2) अन्यथा पतवार को मौजूदा मूल्यों को पुनः प्राप्त करना चाहिए। कहीं से (शायद टिलर), फिर इस मौजूदा मूल्यों को मर्ज करें।

यादृच्छिक नमक/पासवर्ड/ca_certificate/certificate_pair उत्पन्न करने के लिए पतवार स्व-निहित होना चाहिए, और अंतिम उपयोगकर्ता को बाहरी पतवार उत्पन्न करने की आवश्यकता नहीं है। यह बहुत बेहतर उपयोगिता प्रदान करता है।

"एक k8s रहस्य के अंदर एक यादृच्छिक मान उत्पन्न करें" करने योग्य है, लेकिन 'ui_secret: {{ RandAlpha 8 }}' की तुलना में सीधा नहीं है।

अन्यथा हेल्म को मौजूदा मूल्यों को पुनः प्राप्त करना चाहिए। कहीं से (शायद टिलर), फिर इस मौजूदा मूल्यों को मर्ज करें। yaml को '-f value.yaml' के साथ मिलाएं।

वास्तव में अपमानजनक नहीं है लेकिन ऐसा लगता है कि यह अधिक बढ़त के मामलों को पेश करता है।
हेलम/टिलर कैसे अंतर करेगा कि मान पहले से ही सेट है या नहीं, और यदि --set या -f values.yaml से ओवरराइड करना है या नहीं, तो आपके मान दिए गए हैं। yaml में हमेशा ui_secret: {{ randAlpha 8 }} होता है?

"एक k8s रहस्य के अंदर एक यादृच्छिक मान उत्पन्न करें" करने योग्य है, लेकिन 'ui_secret: {{ RandAlpha 8 }}' की तुलना में सीधा नहीं है।

सहमत। लेकिन वैसे भी, टेम्प्लेटिंग मेरे लिए कोई समाधान नहीं लगता है।

सेवा निर्भरताओं से निपटने के लिए आपको https://github.com/atlassian/smith जैसे वर्कफ़्लो इंजन की आवश्यकता होगी (परिणामस्वरूप, आश्रित helm install s द्वारा उपभोग किए जाने वाले मूल्यों को पारित करने की क्षमता के साथ)।

मुझे लगता है कि आप इस उपयोग-मामले (कार्यप्रवाह इंजन, सेवा निर्भरता प्रबंधन) का समर्थन करने के लिए एक सुविधा अनुरोध सबमिट कर सकते हैं। हालांकि, मुझे नहीं पता कि यह हेलम/टिलर के दायरे में संभव है या नहीं।

चार्ट स्थापित करते समय, चार्ट में '--set' > '-f value.yaml' >values.yaml
चार्ट को अपग्रेड करते समय, '--सेट' > '-f value.yaml' > जेनरेट किए गए मान.yaml स्थापित चार्ट के लिए

मैंने जो प्रस्तावित किया वह BOSH https://bosh.io/docs/variable-types.html में लागू किया गया है। BOSH स्पष्ट चर प्रकार परिभाषा का समर्थन करता है, जबकि हेलम चार्ट में value.yaml सादे yaml का समर्थन करता है। तो मान.yaml में टेम्पलेट फ़ंक्शन का समर्थन करना बहुत अच्छा होगा, उदाहरण के लिए 'ui_secret: {{ RandAlpha 8 }}'।

हालांकि यह कुछ उपयोगकर्ताओं के लिए बेहतर उपयोगिता प्रदान करेगा, लेकिन यह भी शीर्ष पर पहुंच जाएगा।

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

मैंने जो प्रस्तावित किया वह BOSH https://bosh.io/docs/variable-types.html में लागू किया गया है। BOSH स्पष्ट चर प्रकार की परिभाषा का समर्थन करता है, जबकि हेलम चार्ट में value.yaml सादे yaml का समर्थन करता है

मैंने परिवर्तनीय इंटरपोलेशन के बारे में बोश के दस्तावेज़ीकरण की समीक्षा की है। यह मेरे लिए पता चला है कि बोश आपके ऐप्स के आउटपुट से (1) पॉप्युलेटिंग वेरिएबल्स का समर्थन नहीं करता है (हमारे मामले में हेल्म/टिलर द्वारा बनाई गई k8s ऑब्जेक्ट्स), और (2) टेम्पलेट के माध्यम से लगातार मूल्य उत्पन्न करता है। https://bosh.io/docs/cli-int.html में -v internal_ip=192.168.56.6 की धारणा देखें ।

यहां तक ​​​​कि बॉश भी बॉक्स के बाहर आपके उपयोग-मामले का समर्थन नहीं करता है।
फिर, मेरा सबसे अच्छा अनुमान अभी भी है कि आपको वर्कफ़्लो इंजन जैसा कुछ चाहिए जैसा मैंने पहले बताया है।
या मुझे अभी भी कुछ याद आ रहा है..?

@johngmyers हाय! कहने के लिए खेद है, लेकिन ऐसा लगता है कि आपका उपयोग-मामला अकेले टेम्पलेटिंग द्वारा समर्थित नहीं है।

आपके उपयोग-मामले का समर्थन करने के लिए, न केवल टेम्प्लेटिंग, हेल्म/टिलर को चार्ट और उसके रिलीज के समन्वय का प्रबंधन करने की भी आवश्यकता होती है, पूर्ववर्ती रिलीज (रिलीज) से आश्रित चार्ट (ओं) के प्रचार में।

AFAICS, जो हेलम/टिलर नहीं है, उसके बारे में वर्तमान में जानकारी है। इसे हेल्म/टिलर के दायरे में करने से यह काफी हद तक फूल जाएगा, जैसा कि @eicnix ने बताया।

चर्चाओं को अलग करने के लिए, मैं आपको एक और मुद्दा प्रस्तुत करने का सुझाव दे सकता हूं। लेकिन दूसरी ओर, ईमानदारी से, मेरे पास इसे बिना फुलाए हेलम/टिलर के अंदर लागू करने का एक व्यवहार्य तरीका नहीं है।

तो आपकी सबसे अच्छी शर्त एटलसियन/स्मिथ (मुझे स्मिथ के लेखकों द्वारा भुगतान नहीं किया जाता है। कृपया मुझे बताएं कि क्या कोई विकल्प है) जैसे किसी अन्य वर्कफ़्लो इंजन की जांच करना होगा + शायद आगामी हेल्म सीआरडी।

@ मुमोशु मेरा मानना ​​​​है कि मेरे उपयोग के मामले को # 2506 द्वारा पर्याप्त रूप से वर्णित किया गया है। मैं नहीं देखता कि किसी अन्य मुद्दे को सबमिट करने से कैसे मदद मिलती है।

मैं यह नहीं देखता कि values.yaml का टेम्प्लेटिंग मेरे उपयोग के मामले को कैसे संभालता है। हेल्म उपचार्ट का समर्थन करता है, जो या तो requirements.yaml charts निर्देशिका में उपचार्ट को एम्बेड करते हैं। पैरेंट चार्ट मान को कुछ इस तरह से पास कर सकता है:

subchart:
  serviceName: {{.Chart.Name}}
  serviceVersion: {{.Chart.AppVersion}}

बेशक, टेम्प्लेटिंग value.yaml एक चार्ट को उन मानों को पास करने की अनुमति देने का एकमात्र तरीका नहीं है जो पैकेज समय पर एक सबचार्ट में ज्ञात नहीं हैं। लेकिन अगर यह हेल्म "ब्लोटिंग" है, तो किसी भी फीचर को बहुत ज्यादा जोड़ना "ब्लोटिंग" हेल्म होगा।

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

मेरे पास एक उपयोग का मामला है जहां मुझे इसके .Values ​​​​से प्राप्त मूल्य को पारित करने के लिए एक मूल चार्ट की आवश्यकता है। यह माता-पिता के बिना सबचार्ट में चिंताओं को अलग करने की अनुमति देता है कि यह एक सबचार्ट का उपयोग करके लागू किया गया है।

उदाहरण के लिए, हमारे पास एक "प्लेटफ़ॉर्म" सबचार्ट होगा जो हमारे आंतरिक प्लेटफ़ॉर्म लाइब्रेरी में लागू सेवाओं के लिए आवश्यक सामान्य सामग्री को इनकैप्सुलेट करता है। यह एक मान "platform.oauthClient" रखना चाहेगा, जिसमें सेवा चार्ट यह इंगित करने के लिए पास होगा कि सेवा को OAuth क्लाइंट बनने के लिए कॉन्फ़िगर करने की आवश्यकता है या नहीं। इसका कार्यान्वयन उस .Values.oauthClient को "प्लेटफ़ॉर्म" सबचार्ट के एक उप-चार्ट में पास करने के लिए हो सकता है। भविष्य में हम "प्लेटफ़ॉर्म" चार्ट की उस सुविधा के कार्यान्वयन को किसी और चीज़ में बदलना चाहेंगे।

टेम्प्लेट किए गए मान शीर्ष-स्तरीय values.yaml (शायद templates/_values.yaml ) के अलावा कहीं और रहना चाहते हैं ताकि वे पैरेंट चार्ट के बाहरी एपीआई का हिस्सा न दिखें। यह चक्रीय संदर्भ मुद्दे को भी संबोधित कर सकता है।

@johngmyers पैरेंट चार्ट मान भी चाइल्ड चार्ट में उपलब्ध होने चाहिए। मुझे विश्वास है कि मैंने पहले जो तरीका प्रस्तावित किया था वह भी आपकी समस्या का समाधान करेगा। आप मूल चार्ट में एक टेम्प्लेटेड मान बना सकते हैं जैसा आपने पहले बताया था और इसे चाइल्ड चार्ट में पास करने दें।

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

जनसंपर्क ने अब तक बहुत प्रगति नहीं की है। किसी भी प्रतिक्रिया, या तो पीआर पर या किसी बिल्ड में फीचर को आज़माने से, जाहिर तौर पर बहुत स्वागत है।

@eicnix हेल्म दस्तावेज कहता है:

लेकिन निचले स्तर के चार्ट पेरेंट चार्ट में चीजों तक नहीं पहुंच सकते हैं, इसलिए MySQL शीर्षक संपत्ति तक नहीं पहुंच पाएगा। न ही, उस मामले के लिए, यह apache.port तक पहुंच सकता है।

ताकि यह संभव न लगे।

@johngmyers चाइल्ड चार्ट पेरेंट वैल्यू तक नहीं पहुंच सकते हैं लेकिन पैरेंट चार्ट चाइल्ड चार्ट में वैल्यू पास कर सकते हैं। मान लें कि आपके पास एक चाइल्ड चार्ट है जिसे माईचाइल्ड कहा जाता है, तो आप इसे मूल मूल्यों से मूल्यों को पास कर सकते हैं। yaml इस तरह:

mychild:
  overridenValue: true

@eicnix लेकिन ऐसे मूल्यों को हेलम पैकेज समय पर जाना जाना चाहिए। क्या आपने मेरे उपयोग के मामलों को भी पढ़ा?

क्या हेल्म टीम इस मुद्दे/प्रस्ताव से अवगत है? इसे 10 महीने पहले 25 मई 2017 को बनाया गया था। यहां बहुत चर्चा हुई है, और कई डुप्लीकेट/समान मुद्दे बनाए गए हैं।
यह मुद्दा अभी तक किसी को नहीं सौंपा गया है।

हम टिप्पणियां देख रहे हैं 'यह शीर्ष पर फूल जाएगा'। तो कौन सा घोल फूलता नहीं है? क्या हेल्म टीम इस प्रस्ताव के लिए एक योजना और ईटीए प्रदान कर सकती है और कम से कम एक उचित समाधान/समाधान दे सकती है?

लगता है पीआर https://github.com/kubernetes/helm/pull/3252 value.yml में टेम्प्लेटिंग का समर्थन कर सकता है। यदि हेल्म टीम ऐसा सोचती है, तो कृपया इसे विलय करने में तेजी लाएं।
धन्यवाद।

@mparry का समाधान https://github.com/kubernetes/helm/pull/3252 में मेरे उपयोग के मामले को सुरुचिपूर्ण ढंग से संभालने लगता है। यह आश्चर्यजनक होगा यदि इसे विलय किया जा सकता है!

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

90d निष्क्रियता के बाद मुद्दे पुराने हो जाते हैं।
/remove-lifecycle stale के साथ समस्या को ताज़ा के रूप में चिह्नित करें।
अतिरिक्त 30d निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

अगर इस मुद्दे को अभी बंद करना सुरक्षित है तो कृपया इसे /close के साथ करें।

सिग-टेस्टिंग, कुबेरनेट्स/टेस्ट-इन्फ्रा और/या फेजटा को फीडबैक भेजें।
/जीवनचक्र बासी

/निकालें-जीवनचक्र बासी

@johngmyers क्या आपको कभी https://github.com/helm/helm/issues/2492#issuecomment -370895073 के लिए कोई अच्छा समाधान मिला? मैं उसी एनकैप्सुलेशन मुद्दे में भाग रहा हूं। मैं वास्तव में helm के लिए एक रैपर लिखने से बचना चाहता हूं ताकि मेरे टेम्पलेट मानों को value.yaml फ़ाइलों में पुन: प्रस्तुत किया जा सके।

मेरे पास कोई अच्छा समाधान नहीं है। मेरे पास एक वर्कअराउंड है जो # 3471 के साथ हेलम के एक निजी निर्माण का उपयोग करता है, जिससे मुझे (अनावश्यक रूप से) मूल चार्ट नाम और संस्करण को पैकेज समय पर सबचार्ट में पास करने की अनुमति मिलती है।

यह और खराब मर्ज समर्थन मूल रूप से मुझे कोई भी उचित एनकैप्सुलेशन करने से रोक रहे हैं। मुझे उम्मीद है कि हेल्म 3 के एलयूए के उपयोग से इस मुद्दे में मदद मिलेगी।

टिलर का टेम्प्लेट रेंडरिंग इंजन कैसे काम करता है, इसके पीछे विभिन्न तकनीकी और डिज़ाइन कारणों से, हम हेल्म 2 या हेल्म 3 के लिए गो टेम्प्लेट के रूप में प्री-प्रोसेसिंग वैल्यूज़ का समर्थन करने का इरादा नहीं रखते हैं। हालाँकि, हम समुदाय को रैपर या हेल्म लिखने के लिए अत्यधिक प्रोत्साहित करते हैं। प्लगइन्स जो उनके उपयोग के मामले में इस सुविधा का समर्थन करते हैं! ऐसा ही एक उदाहरण हमने उपयोगकर्ताओं से सुना है gomplate , लेकिन हम ऐसे अन्य प्री-प्रोसेसर देखना पसंद करेंगे जो helm install चलाने से पहले यह कार्यक्षमता प्रदान कर सकें।

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

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

असुविधा के लिए हम क्षमा चाहते हैं, और समझने के लिए धन्यवाद!

@bacongobbler - मैंने मूल रूप से इस मुद्दे को खोला इससे पहले कि मुझे लगता है कि मैं वास्तव में पूरी तरह से समझ गया हूं कि मेरे वर्कफ़्लो में प्रभावी ढंग से हेलम का उपयोग कैसे किया जाए। मैं टिकट बंद करने के फैसले से पूरी तरह सहमत हूं. मैंने इसे मुख्य रूप से खुला छोड़ दिया क्योंकि इस मुद्दे पर अच्छी मात्रा में सामुदायिक चर्चा हुई। जब से मैंने इस टिकट को खोला है और मैंने और अधिक "मानक" कार्यप्रवाह सीखे हैं, मुझे वास्तव में नहीं लगता कि मैंने कभी खुद को इस विशेष सुविधा के लिए चाहा है। तो, किसी भी मामले में,

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

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

@benjigoldberg क्या होगा यदि आप सबचार्ट्स को नियंत्रित नहीं करते हैं? उदाहरण के लिए ग्राफाना तीसरी पार्टी है। हम छत्र चार्ट में परिभाषित एक रहस्य का उपयोग करने के लिए इसके टेम्प्लेट को आसानी से नहीं बदल सकते हैं।

@dtshepherd हमने निश्चित रूप से उन मुद्दों में भाग लिया है - उन परिदृश्यों में हमने हेलम चार्ट रेपो को फोर्क किया है और विकल्प को अपस्ट्रीम में योगदान दिया है और फिर परिवर्तन विलय होने तक अपने स्वयं के फोर्क चार्ट का उपयोग किया है (तब हम मुख्य रेपो में वापस माइग्रेट करते हैं चार्ट)। चलने वाले हिस्से हैं, लेकिन आजकल ऐसा नहीं होता है। मुख्य चार्ट रेपो काफी परिपक्व हो गया है और बहुत सारे चार्ट में यह लचीलापन है।

हां, अधिकांश तृतीय पक्ष चार्ट चीजों को ठीक करते हैं। हालांकि, अगर मेरे पास उन तृतीय पक्ष चार्ट को समाहित करने के लिए एक रैपर चार्ट है, तो मैं तृतीय पक्ष चार्ट में tpl डाले बिना कुछ सामान्य चर पर सामान्यीकृत नहीं कर सकता।

@dtshepherd आप उस शीर्ष स्तर की मान फ़ाइल से चर/गुप्त के नाम को नियंत्रित कर सकते हैं और फिर इसे सबचार्ट्स में दबा सकते हैं, है ना?

Elasticsearch/किबाना मामले में, सेवा का नाम रिलीज़ नाम से लिया गया है। लेकिन यह रिलीज़ नाम के बराबर _ नहीं है। क्या कोई सुझाव दे सकता है कि परिणामी सेवा नाम को केवल परिवर्तनीय नामकरण का उपयोग करके किबाना को कैसे पास किया जाए?

@benjigoldberg हां, लेकिन इससे एनकैप्सुलेशन टूट जाता है क्योंकि शीर्ष स्तर के चार्ट को तीसरे पक्ष के चार्ट में चर नामों को जानने की आवश्यकता होगी। बीच में चार्ट एब्स्ट्रैक्शन लेयर होना चाहिए, लेकिन बिना टेम्प्लेट वैल्यू.yaml फ़ाइल के नहीं हो सकता।

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

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

कुछ और हम इसमें भाग गए जो मेरे दिमाग में आते हैं:

• लगातार वॉल्यूम के दावे जिन्हें कई सबचार्ट के बीच साझा करने की आवश्यकता है, लेकिन उन्हें कई रिलीज का भी समर्थन करना चाहिए।
• एक साझा चर जो एक उपयोगकर्ता प्रदान करता है, जिसे कई उप-चार्टों में धकेलने की आवश्यकता होती है।

हेलम की इनकैप्सुलेट करने में असमर्थता हमारे लिए एक प्रमुख दर्द बिंदु है। बस दूसरे हफ्ते में मैंने इस मुद्दे पर एक बड़ी क्लाउड सेवा कंपनी को हेल्म से दूर रहने की चेतावनी दी।

यह टिकट थोड़ा अधिक बाध्य है। आवश्यकता एक मूल चार्ट को एक उप-चार्ट के लिए एक मान पास करने की अनुमति देने के लिए है जहां मूल्य पैकेज समय पर ज्ञात नहीं है, लेकिन मूल चार्ट के अपने .Value , .Chart , और/या .Release से प्राप्त किया गया है।

templates/_values.yaml से ऊपर का मेरा प्रस्ताव बिना किनारे की स्थिति और #2133 की जटिलता के इसे हासिल करने का एक तरीका हो सकता है। अनुरक्षकों ने कहा है कि वे value.yaml के टेम्प्लेटिंग का समर्थन नहीं करेंगे, लेकिन यह स्पष्ट नहीं है कि क्या वे इस तरह के वैकल्पिक मूल्यों को टेम्प्लेट करने के प्रस्ताव पर विचार करेंगे।

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

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

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

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

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

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

उम्मीद है कि यह इसे सभी के लिए कुछ और स्पष्ट करता है!

यह विस्तृत स्पष्टीकरण @ thomastaylor312 प्रदान करने के लिए समय निकालने के लिए धन्यवाद, जो इस निर्णय को बहुत बेहतर तरीके से स्पष्ट करता है।

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

xref: https://github.com/helm/community/blob/master/helm-v3/002-events.md

शानदार प्रतिक्रिया के लिए धन्यवाद @nuwang! हम हेल्म 3 के सभी कार्यों के साथ इसे ध्यान में रखना सुनिश्चित करेंगे

इसके लिए यहां एक उपाय है।

सादे yaml स्ट्रिंग के रूप में values.yaml में बस कुछ टेम्पलेट अभिव्यक्ति लिखना।
पसंद।

helloworld: Hello World!!
sometemplate: '{{ .Values.helloworld }}'

और टेम्प्लेट फ़ाइल में sometemplate tpl मूल्यांकन करने के लिए tpl का उपयोग करना।

{{ $global := . }}
{{ tpl (trimAll "\"'" .Values.sometemplate) $global }}

आउटपुट होगा

हैलो वर्ल्ड!

@ wpc009 हाँ, यह काम करता है, केवल असुविधा यह है कि tpl केवल एक बार स्ट्रिंग का मूल्यांकन करता है जो कि एक बुरी बात नहीं है, लेकिन कुछ ऐसा है जिसे आपको ध्यान में रखना चाहिए:

publicHost: "{{ .Release.Name }}-{{ .Release.Namespace }}-paymentgw.{{ .Values.global.publicDomain }}"
callbackUrl: "{{ .Values.global.publicDomainSchema }}://{{ .Release.Name }}-{{ .Release.Namespace }}-paymentgw.{{ .Values.global.publicDomain }}/validate" # this will work
# callbackUrl: "{{ .Values.global.publicDomainSchema }}://{{ paymentgw.publicHost }}/validate" # this will not

@ wpc009 हाँ, यह काम करता है, केवल असुविधा यह है कि tpl केवल एक बार स्ट्रिंग का मूल्यांकन करता है जो कि एक बुरी बात नहीं है, लेकिन कुछ ऐसा है जिसे आपको ध्यान में रखना चाहिए:

publicHost: "{{ .Release.Name }}-{{ .Release.Namespace }}-paymentgw.{{ .Values.global.publicDomain }}"
callbackUrl: "{{ .Values.global.publicDomainSchema }}://{{ .Release.Name }}-{{ .Release.Namespace }}-paymentgw.{{ .Values.global.publicDomain }}/validate" # this will work
# callbackUrl: "{{ .Values.global.publicDomainSchema }}://{{ paymentgw.publicHost }}/validate" # this will not

यह सच है। संदर्भित किया जाने वाला मान स्थिर होना चाहिए।
या आपको नेस्टेड tpl लिखने की आवश्यकता होगी।

@eicnix ने {{ .Values.labels | quote | tpl | toYaml | indent 4 }} की कोशिश की, लेकिन यह त्रुटि मिली: executing "financial-accounting/templates/worker-deployment.yaml" at <tpl>: wrong number of args for tpl: want 2 got 0 ।

Values.yaml

labels:
  revision: revision-{{ .Release.Revision }}-{{ .Release.Revision | quote | b64enc }}

विकास.यामल

metadata:
  labels:
{{ .Values.labels | quote | tpl | toYaml | indent 4 }}

मुझे इसके साथ काम करना पड़ा:

Values.yaml

dbName: test_{{ .Release.Namespace }}

परिनियोजन.yaml

env:
  - name: DB_NAME
    value: {{ tpl .Values.dbName . | quote }}

मैं फ़ैब्रिक 8.io एक्सपोज़ कंट्रोलर का उपयोग कर रहा हूं, जो उजागर सेवा के लिए एक डिफ़ॉल्ट यूआरएल देता है। अब मैं नेमस्पेस के आधार पर एक कस्टम यूआरएल बनाना चाहता हूं, कुछ इस तरह
fabric8.io/exposeUrl: https://{{ tpl .Release.Namespace }}.jx.org.co , कुछ ऐसा जिसे एक्सपोज़ कंट्रोलर चुनने जा रहा है, इसलिए मेरे पास {{ tpl ... }} का उपयोग करने का विकल्प नहीं है। क्या कोई ऐसा तरीका है जिससे नाम का समाधान value.yaml में ही किया जा सकता है?

कुछ वर्कअराउंड जो दूसरों ने विभिन्न उप-सूत्रों में इंगित किए हैं:

1. माता-पिता से बच्चे तक चर पारित करने के लिए हेल्म वैश्विक मूल्यों का उपयोग करें ( रेफरी )।
2. अपने मूल्यों के भीतर सूखापन सुधारने के लिए वाईएएमएल एंकर का उपयोग करें। yaml फ़ाइल ( रेफरी , धन्यवाद @szwed)।

ये सभी उपयोग के मामलों को कवर नहीं करते हैं, फिर भी वे आपके टूल बेल्ट में अच्छे हैं।

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

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

बेशर्म प्लग के लिए @nicorikken Sry, लेकिन मैं सुझाव देता हूं कि टेम्प्लेटिंग वैल्यू और लेयरिंग टेम्प्लेटेड हेल्म रिलीज़ के लिए हेल्मफाइल की कोशिश करें और बिना फोर्किंग के चार्ट को संशोधित करने के लिए हेल्म-एक्स , और यहां तक ​​​​कि हेल्मफाइल + हेल्म-एक्स का संयोजन।

मैं सहमत हूं कि आपके द्वारा उल्लिखित मुद्दों से निपटने के लिए हमें कुछ चाहिए। दूसरी ओर मैं स्कोप-रेंगना नहीं चाहता। इसलिए मैंने दो आउट-ऑफ-ट्री प्रोजेक्ट्स का रखरखाव खुद करना शुरू किया।

@mumoshu प्लग के लिए धन्यवाद। मैंने इसे पहले संभावित समाधान के रूप में उल्लेख किया था। मैं इसे देख लूंगा। यह अतिरिक्त टूलिंग की लागत लाएगा, जिसे हमें Argo-CD के साथ भी एकीकृत करना पड़ सकता है (क्या यह भी संभव है?) अभी के लिए मैंने रेपो को फोर्क किया है और नेमस्पेस को पैरामीटर किया है, और अपस्ट्रीम स्थिर चार्ट रेपो के लिए पीआर बना दिया है। आइए देखें कि अनुरक्षक इससे क्या बनाते हैं।

@nicorikken उत्तर देने के लिए धन्यवाद!

मुझे लगता है कि मैं अतिरिक्त टूलिंग की लागत को समझता हूं। लेकिन दूसरी तरफ मैं खुद से सवाल कर रहा हूं - अगर कोई बड़ा टूल होता जो सभी हेलम + हेल्मफाइल + हेल्म-एक्स उपयोग-मामलों को कवर करता है, तो क्या सीखना/उपयोग करना आसान होगा?

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

क्या यह संभव भी है?

हाँ :) helmfile template argo-cd के "कॉन्फ़िगरेशन प्रबंधन प्लगइन" सुविधा के साथ अच्छी तरह से चलता है।

नाम स्थान निर्दिष्ट करने के विशिष्ट उपयोग-मामले के लिए, मैंने जेनकिंस हेल्म चार्ट के लिए एक अपस्ट्रीम पीआर बनाया है https://github.com/helm/charts/pull/15202 यह एक namespaceOverride पैरामीटर जोड़ता है। मुझे उम्मीद है कि क्लस्टर-वाइड हेल्म चार्ट परिनियोजन को सक्षम करने के लिए इस पैटर्न को अधिक व्यापक रूप से अपनाया जाएगा।
मुझे हेल्मफाइल में और अधिक देखने के लिए कुछ समय लेना होगा। यह निश्चित रूप से अपस्ट्रीम चार्ट के शीर्ष पर उन्नत क्लस्टर-व्यापी टेम्पलेटिंग को सक्षम करके और Argo-CD के साथ एकीकृत करके हमारी आवश्यकता को पूरा करता प्रतीत होता है।

क्या कोई affinity नियम के लिए कुछ सेट करते समय यह कैसे करना जानता है? उदाहरण के लिए, stable/nginx-ingress पर NGINX इनग्रेड चार्ट पर, मैं निम्नलिखित होने के लिए controller.affinity मान सेट करना चाहता हूं:

Values.yaml

controller:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 5
        podAffinityTerm:
          topologyKey: "kubernetes.io/hostname"
          labelSelector:
            matchLabels:
              app: {{ template "nginx-ingress.name" . }}
              component: "{{ .Values.controller.name }}"
              release: {{ .Release.Name }}

{{ tpl .Values.controller.name }} का उपयोग component कुंजी कार्यों के लिए, लेकिन मुझे app और release भागों की भी आवश्यकता है, जो ऊपर दिखाई देने पर काम नहीं करते हैं।

क्या किसी और को डाउनस्ट्रीम template फ़ंक्शंस और Release.Name मानों को कॉल करने की आवश्यकता है?

@sc250024 अरे! आप अपने value.yaml टेम्पलेट में nginx-ingress.name टेम्पलेट को कहाँ परिभाषित करते हैं?

इसे https://golang.org/pkg/text/template/#hdr -Actions में बताए गए अनुसार {{define ... के साथ पहले से परिभाषित करने की आवश्यकता है

साथ ही - {{.Release.Name}} केवल releases[].values में helmfile.yaml के तहत स्ट्रिंग्स के भीतर काम करता है।

यह काम करना चाहिए:

releases:
- ...
  values:
  - {{`{{.Release.Name}}`}}/values.yaml

यह काम नहीं करता है:

releases:
- ...
  values:
  - foo: {{`{{.Release.Name}}`}}/values.yaml

मुझे लगता है कि यदि आपको उनमें से किसी एक की आवश्यकता है तो यह एक समर्पित सुविधा अनुरोध के लायक है।

@mumoshu यह मेरी मान फ़ाइल में परिभाषित नहीं है, यह कुछ ऐसा है जो stable/nginx-ingress पर स्थित NGINX हेल्म चार्ट में शामिल है। यह मेरी बात है वास्तव में, मैं उस टेम्पलेट का उपयोग करने की कोशिश कर रहा हूं जो पहले से ही उस चार्ट में है।

रिकॉर्ड के लिए, मैं एक चार्ट में उपचार्ट के रूप में stable/nginx-ingress का उपयोग नहीं कर रहा हूं जिसे मैं विकसित कर रहा हूं; मैं इसे सीधे एनजीआईएनएक्स प्रवेश को तैनात करने के लिए उपयोग कर रहा हूं।

यह मेरी मान फ़ाइल में परिभाषित नहीं है, यह कुछ ऐसा है जो स्थिर/nginx-ingress पर स्थित NGINX हेल्म चार्ट में शामिल है। यह मेरी बात है वास्तव में, मैं उस टेम्पलेट का उपयोग करने की कोशिश कर रहा हूं जो पहले से ही उस चार्ट में है।

दुर्भाग्य से यह असंभव है क्योंकि हेल्मफाइल (मान) टेम्प्लेट हेल्म (चार्ट) टेम्प्लेट से स्वतंत्र रूप से काम करते हैं, और nginx-ingress.name चार्ट टेम्प्लेट में उपयोग के लिए हेल्म चार्ट के भीतर परिभाषित एक टेम्प्लेट है।

संभवत: एकमात्र तरीका यह होगा कि nginx चार्ट में परिभाषित {{define "nginx-ingress.name"}} ब्लॉक को आपके हेल्मफाइल मान टेम्पलेट values.yaml में कॉपी किया जाए?

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

Values.yaml में:

keys:
  - name: key_for_test
    value: CHANGEFORRELEASE-my-value

और मैं इसे एक गुप्त यमल में उपयोग करूंगा:

रहस्य_kv.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: {{ .Release.Name }}-test-kv
  annotations:
    description: Key/Value pairs to save in test datastore
  labels:
    app: test
    tier: backend
    vendor: test
    support: {{ template "supportMethod" . }}
    chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
    release: "{{ .Release.Name }}"
    heritage: "{{ .Release.Service }}"
type: Opaque
data:
  {{- $var := .Release.Name }}
  kv.yaml: {{ toYaml .Values.keys | replace "CHANGEFORRELEASE" $var | b64enc | quote }}

मुझे उम्मीद है कि यह किसी के लिए मददगार होगा।

यह पहला धागा है जिसमें मैंने भाग लिया, यहां भी टिप्पणी करने से ...
यह भी देखें #2514

:) शुक्र है, नवीनतम हेल्म मैनुअल कहता है कि इसे कैसे प्राप्त किया जाए।
https://helm.sh/docs/howto/charts_tips_and_tricks/#use -the-tpl-function

चाल " या एक yaml ब्लॉक |- में चर को संलग्न कर रही है, और इसे टेम्पलेट में {{ tpl .Values.variable . }} के रूप में संदर्भित करने के बजाय
यह हेल्म को खुश करने लगता है।

उदाहरण:

$ cat Chart.yaml | grep appVersion
appVersion: 0.0.1-SNAPSHOT-d2e2f42


$ cat platform/shared/t/values.yaml | grep -A2 image:
image: 
  tag: |-
    {{ .Chart.AppVersion }}


$ cat templates/deployment.yaml | grep image:
          image: "{{ .Values.image.repository }}:{{ tpl .Values.image.tag . }}"


$ helm template . --values platform/shared/t/values.betradar.yaml | grep image
          image: "docker-registry.default.svc:5000/namespace/service:0.0.1-SNAPSHOT-d2e2f42"
          imagePullPolicy: Always
      image: busybox

अन्यथा एक त्रुटि फेंक दी गई है ..

$ cat platform/shared/t/values.yaml | grep -A1 image:
image: 
  tag: {{ .Chart.AppVersion }}

1 $ helm template . --values platform/shared/t/values.yaml | grep image
Error: failed to parse platform/shared/t/values.yaml: error converting YAML to JSON: yaml: invalid map key: map[interface {}]interface {}{".Chart.AppVersion":interface {}(nil)}

अभी के लिए, मैंने CI जॉब में जो किया है, वह value.yaml फ़ाइल पर helm template चलाया जाता है। यह बहुत अच्छा एटीएम काम करता है।

cp values.yaml templates/
helm template $CI_BUILD_REF_NAME ./ | sed -ne '/^# Source: templates\/values.yaml/,/^---/p' > values.yaml
rm templates/values.yaml

helm upgrade --install ...

यह टूट जाता है यदि आपके पास एकाधिक -f values.yml फ़ाइलें हैं, लेकिन मैं एक छोटा helm रैपर लिखने की सोच रहा हूं जो अनिवार्य रूप से प्रत्येक values.yaml फ़ाइल के लिए उस बैश स्क्रिप्ट को चलाता है।

एक उपयोग मामला है जहां आपको निर्भरता चार्ट पर परिनियोजन नाम पास करने की आवश्यकता होगी जहां आपका कोई नियंत्रण नहीं है।

उदाहरण के लिए, मैं ज़ूकीपर के लिए पॉडएफ़िनिटी सेट करने का प्रयास कर रहा हूँ। और मेरे पास एक एप्लिकेशन हेल्म चार्ट है जो ज़ूकीपर को निर्भरता के रूप में सेट करता है। इस मामले में, मैं मूल्यों के माध्यम से ज़ूकीपर को पॉड एंटीफिनिटी पास कर रहा हूं। तो मेरे ऐप्स में value.yaml फ़ाइल में मेरे पास एक zookeeper.affinity अनुभाग है। यदि मेरे पास yaml मानों के अंदर रिलीज़ नाम प्राप्त करने की क्षमता है तो मैं इसे डिफ़ॉल्ट रूप से सेट कर दूंगा और इसके साथ किया जाएगा।

लेकिन अब प्रत्येक परिनियोजन के लिए मुझे इस मान को ओवरराइड करना होगा, जो एक बड़ी समस्या है।

@ thomastaylor312 और अन्य:

मैंने इस सामान्य विषय पर कई संबंधित मुद्दों के माध्यम से पढ़ा है, और ऐसा लगता है कि values.yaml को टेम्प्लेट करने की धारणा अव्यावहारिक, गैर-तुच्छ, आदि है।

इसके बजाय चार्ट टेम्प्लेटिंग/तैनाती/आदि के दौरान कुछ अतिरिक्त मध्यवर्ती चरण का समर्थन करना उचित होगा। जहां कुछ मनमानी (यानी उपयोगकर्ता द्वारा प्रदान की गई) स्क्रिप्ट (यानी पायथन, बाश, लुआ, आदि) को स्थिर values.input.yaml (उर्फ values.yaml ) की एक प्रति प्राप्त होती है और विभिन्न चरों तक पहुंच होती है (यानी .Release.* ), और स्क्रिप्ट गतिशील रूप से "अंतिम" values.output.yaml फ़ाइल बनाने के लिए ज़िम्मेदार हो सकती है (जो वास्तव में शेष चार्ट टेम्पलेट्स द्वारा सीधे उपयोग की जाती है)? यदि हेल्म इसके लिए "हुक" की आपूर्ति करने में सक्षम है, तो ऐसा लगता है कि यह एक व्यवहार्य समझौता हो सकता है, अर्थात "यहां values.output.yaml बनाने के लिए आपकी स्क्रिप्ट को ट्रिगर करने के लिए सभी डेटा और एक हुक है, मज़े करो!"।

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

मैं वर्तमान में ऐसा कुछ करता हूं, लेकिन इसके लिए मुझे अपने चार्ट के लिए "लॉन्चर" स्क्रिप्ट प्रदान करने की आवश्यकता है, इसलिए डाउनस्ट्रीम उपभोक्ता मेरे चार्ट को "हेल्म इंस्टॉल" नहीं कर सकते हैं (कुछ हद तक समान उपयोग केस helmfile ) . यह तीसरे पक्ष के चार्ट/कंटेनरों के लिए मूल्यों को टेम्प्लेट करने की आवश्यकता से उत्पन्न हुआ (जिसे मैं तकनीकी और कानूनी कारणों से संशोधित नहीं कर सकता)। इन चार्टों में, मेरे पास .Release.Namespace के बराबर हार्ड-कोडेड मान हैं जो हर जगह शाब्दिक रूप से दिखाई देते हैं (K8S सेवाओं के लिए इन-क्लस्टर FQDN के लिए URI/URL स्ट्रिंग्स के अंदर, होस्ट नामों की सरणियाँ, env vars, आदि)। हर बार मुझे शीर्ष-स्तरीय चार्ट को एक अलग नामस्थान पर तैनात करने की आवश्यकता होती है, अगर यह मेरी सहायक स्क्रिप्ट के लिए नहीं होती, तो मुझे values.yaml में लगभग 30 प्रविष्टियों को संशोधित करना पड़ता। अगर इस पर मानकीकरण करने का कोई तरीका था (भले ही यह ऊपर वर्णित कार्यान्वयन के माध्यम से न हो), यह सहायक होगा।

@IAXES क्या नई पोस्ट-रेंडर सामग्री संभवतः इसे हल करने में मदद करेगी?

@ thomastaylor312 मेरे अपने विशिष्ट उपयोग के मामले में, निश्चित रूप से हाँ। उपयोग के मामलों में दूसरों ने वर्णन किया है (अर्थात जो गैर-तुच्छ हैं और values.yaml फ़ाइल की कुछ हद तक गतिशील पीढ़ी की आवश्यकता होती है, साथ ही साथ परिनियोजन-समय चर जैसे .Release.Namespace , आदि तक पहुंच की आवश्यकता होती है। ।), मुझे दृढ़ता से संदेह है कि यह उन समस्याओं को भी हल कर सकता है (दूसरों से कुछ अतिरिक्त प्रतिक्रिया की आवश्यकता होगी जो इस धागे/मुद्दे के शीर्ष पर वर्णित मूल विशेषता चाहते/चाहते हैं)।

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

अगर यह खोज के लायक कुछ समझा जाता है, तो helmfile अनुरक्षकों/मालिकों (परामर्श/राय/फीडबैक/आदि) को +CC करना भी एक अच्छा विचार हो सकता है, क्योंकि मौजूदा समाधान में हुक करना संभव हो सकता है अवधारणा का सबूत। यदि कोई इन हुकों को स्थापित कर सकता है और "रिक्त स्थान भरने" के लिए कोई मनमाना समाधान कदम उठा सकता है, और अंतिम उपभोक्ता/उपयोगकर्ता को अभी भी helm install निष्पादित करना है (साथ ही apt/yum/apk कुछ निर्भरताएं स्थापित करें) , यह कमाल का होगा!

@benjigoldberg @fsniper क्या मेरे द्वारा ऊपर वर्णित उपयोग के मामले संभावित रूप से आपके उपयोग के मामलों को उचित तरीके से संबोधित करेंगे?

@IAXES अगर मैं सही ढंग से समझता हूं कि आप सुझाव दे रहे हैं, बाहरी अनुप्रयोगों को हुक प्रदान करने और फिर उनके आउटपुट को स्टेटिक्स के रूप में उपयोग करने का सुझाव दे रहे हैं।

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

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

या इसके लिए पहले से चर्चा की गई और प्रलेखित लुआ स्क्रिप्टिंग को लागू करने के लिए इस्तेमाल किया जा सकता है। बेशक यह भी उपलब्ध नहीं है।

वर्तमान में मेरा दृष्टिकोण हेल्समैन मान फ़ाइल पर्यावरण मान प्रतिस्थापन का उपयोग कर रहा है। यह सीमित है, लेकिन कुछ हॉप्स के साथ प्रयोग करने योग्य है।

यह समस्या आपके सभी ऐप्स के लिए पैरेंट हेल्म चार्ट के साथ नीले-हरे रंग की तैनाती का उपयोग करना अधिक चुनौतीपूर्ण बनाती है, कम से कम यदि आपका कोई मान पर्यावरण-विशिष्ट URL या डेटाबेस कनेक्शन है। अभी के लिए मैं @ leox-phq के समाधान की कोशिश करने जा रहा हूँ।

मुझे यह भी आश्चर्य है कि अगर values.yaml फ़ाइल के बजाय templates/values.yaml values.yaml बनाने का उपयोग हेलम को मूल्य प्रतिस्थापन करने के लिए कहने के लिए एक सम्मेलन के रूप में किया जा सकता है ... सुनिश्चित नहीं है कि इससे कुछ को संबोधित करने में मदद मिलेगी मूल रूप से हेल्म में इसे लागू करने में आने वाली समस्याओं का उल्लेख किया गया था ...

अपडेट: sed के --show-only विकल्प का उपयोग करके प्रतिस्थापन की आवश्यकता से बचने के लिए @ leox-phq के समाधान में सुधार किया जा सकता है helm template :

helm template . --show-only templates/values.yaml > values.yaml

मैं value.yaml फ़ाइलों में Chart.yaml appVersion का उपयोग करने का एक तरीका ढूंढ रहा हूं। सुनिश्चित नहीं है कि पहले से ही कोई समाधान है या इस समस्या की आवश्यकता है।

@nodesocket यह पहले से ही .Chart में मौजूद है! https://docs.helm.sh/docs/chart_template_guide/builtin_objects/

@ thomastaylor312 मैंने सोचा था कि आप केवल .Chart.AppVersion टेम्प्लेट के अंदर उपयोग कर सकते हैं न कि value.yaml फ़ाइलों में?

आह क्षमा करें, मुझे वह हिस्सा याद आया। हां, यहां बताए गए कारणों से वैल्यू फाइलों का कोई टेम्प्लेट नहीं है।

values.yaml में टेम्प्लेटिंग के बारे में पढ़ने और विभिन्न समाधानों को आज़माने के बाद ऐसा लगता है कि यह इस समय के लिए सबसे साफ समाधान हैं (बहुत अधिक स्थानों पर न देखने के द्वारा सबसे अधिक पठनीय होने के संदर्भ में):

• टेराफॉर्म के माध्यम से हेल्म चार्ट को तैनात करें, एक बाहरी फ़ाइल values.yaml.tmpl प्रदान करें, और टेराफॉर्म चर प्रस्तुत करने के लिए templatefile("values.yaml.tmpl",..) का उपयोग करें।
• हेल्मफाइल के माध्यम से हेल्म चार्ट को तैनात करें, सभी मान इन-लाइन प्रदान करें, और पर्यावरण चर प्रस्तुत करने के लिए {{ requiredEnv "..." }} का उपयोग करें।

https://github.com/helm/helm/issues/2492#issuecomment -413635332 द्वारा उठाई गई चिंताओं को हल करते हुए, # 6876 भी है जो इस मुद्दे पर एक नया दृष्टिकोण है। हालांकि, यह बड़ा है, और इसकी समीक्षा होने में काफी समय लग रहा है।