Helm: चार्ट परिनियोजन में बाहरी फ़ाइलों को जोड़ने की अनुमति दें

हाय लीना,

वर्तमान तरीका:
फ़ाइल-सामग्री जोड़ने को लागू करने का वर्तमान तरीका हेल्म इंस्टॉल को कॉल करते समय "--values" n-आयामी-पैरामीटर का उपयोग करना है। प्रत्येक फ़ाइल (सामान्य कॉन्फ़िगरेशन मान, एसएसएल-सामान, लाइसेंस) को एक अलग वाईएमएल फ़ाइल में रखकर बेहतर पठनीयता प्रदान करनी चाहिए।

आइए मान लें कि हम चार्ट रिपोजिटरी नाम के रूप में "फर्स्टस्पिरिट" का उपयोग करते हैं, जो ग्राहक को चार्ट प्रदान करता है। तब ग्राहक आपके चार्ट को कॉल के माध्यम से परिनियोजित कर सकता है:

helm install firstspirit/caas --values myvalues.yml,ssl.yml,foobar-license.yml

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

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

सादर,
मार्कस

हाय मार्कस,
सुनिश्चित नहीं है कि हम एक दूसरे को सही ढंग से समझते हैं। मेरे उपयोग के मामले पर थोड़ा विस्तार करने के लिए, मेरे चार्ट में वर्तमान में यही है:

...
{{ if .Files.Get "config/fs-license.conf" }}
file.fs-license.conf:               {{ .Files.Get "config/fs-license.conf"                                | b64enc }}
{{ else }}
{{ fail "you need to supply your license file! add 'fs-license.conf' to your chart 'config' directory." }}
{{ end }}
...

मैं उपयोगकर्ताओं को yaml फ़ाइलों में बेस 64-एन्कोडेड स्ट्रिंग प्रदान करने के लिए बाध्य नहीं करना चाहता था, बल्कि इसके बजाय सीधे फाइलें देना चाहता था। हालाँकि, फ़ाइलों को चार्ट का ही हिस्सा होना चाहिए और बाहर से नहीं दिया जा सकता है, इसलिए यह टिकट।

मुझे इसकी सटीक आवश्यकता है। मेरा चार्ट /keybase पर फ़ाइल से एक गुप्त पठन प्रकाशित करता है। यह फ़ाइल जानबूझकर चार्ट में नहीं है।

मेरा मानना ​​है कि .Files.Get फाइलों को चार्ट के अंदर नहीं माना जाना चाहिए:

https://github.com/kubernetes/helm/blob/master/pkg/chartutil/files.go#L32

मुझे पूरा यकीन है कि .Files.Get फ़ाइल सिस्टम को मनमाने ढंग से एक्सेस करने में सक्षम नहीं होना एक सुरक्षा विशेषता है, इसलिए मुझे नहीं लगता कि वर्तमान व्यवहार गलत है - यह सभी उपयोग मामलों को पूरा नहीं करता है।

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

हो सकता है कि @ cr4igo ने पहले ही सुझाव दिया हो :)

हमें बहुत समान उपयोग के मामले में एक ही समस्या हो रही है:

हमारे पास Apple और Googles पुश सूचना सेवाओं के लिए प्रमाणपत्र हैं; हमारे पास हमारे परीक्षण और उत्पादन परिवेशों के लिए अलग-अलग प्रमाणपत्र हैं, इसलिए हम केवल चार्ट में प्रमाणपत्र को बंडल नहीं कर सकते हैं (ऐसा करने के आसपास सुरक्षा चिंताओं को अनदेखा कर रहे हैं); हम आदर्श रूप से फ़ाइल पथ को मान फ़ाइल में रखने में सक्षम होना चाहते हैं और उस फ़ाइल को हेल्म लोड करना चाहते हैं।

मेरे पास हेल्म को यह बताने का कोई अच्छा सुझाव नहीं है कि मान फ़ाइल में स्ट्रिंग एक सापेक्ष फ़ाइल पथ है - शायद इसे किसी प्रकार के $file("path/goes/here") निर्माण में लपेटना लेकिन यह गन्दा लगता है।

जैसे
Values.yaml

apns:
  certificatePath: "./mycert.p12"

गुप्त.यमल

...
data:
  apnsCertificate.p12: |-
    {{ Files.Get .Values.apns.certificatePath | b64enc }}

मुझे लगता है, यह #1754 . का डुप्लीकेट है

मुझे नहीं लगता कि यह एक डुप्लिकेट है, यह हेल्म को हेल्म चार्ट "रूट" के बाहर पूर्ण पथ पर फ़ाइलों तक पहुंचने की इजाजत देने के बारे में है।

उदाहरण:

data:$
  dynamicvalues.json: |-$
{{- if .Files.Get (required "Helm Error: .Values.valuesfile is required" .Values.valuesfile) }}$
    {{ .Files.Get (.Values.valuesfile) }}$
{{- else }}$
{{ fail "Helm Error: specified .Values.valuesfile could not be read" }}$
{{- end }}$

यह हेलम रेपो के अंदर फाइलों की ओर इशारा करते हुए प्रस्तुत करने में विफल रहता है, अर्थात:
हेल्म --सेट वैल्यूफाइल =/tmp/my-डायनामिक-फाइल [...]

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

नमस्ते,

मैं सी-प्रीप्रोसेसर के समान एक दृष्टिकोण का सुझाव देना चाहता हूं ... डिफ़ॉल्ट रूप से चार्ट के भीतर खोज पथ है, हालांकि अतिरिक्त निर्देशिकाओं को अनुमति देने के लिए --search-directories= पैरामीटर जोड़ें। यह सुरक्षा आवश्यकताओं को पूरा करेगा क्योंकि sysadmin को यह निर्दिष्ट करना होगा कि अतिरिक्त फ़ाइलें कहाँ रहती हैं, यह Files::glob ठीक से काम करेगा।

तुम क्या सोचते हो?

उदाहरण

पैकेज को निकाले बिना चार्ट पैकेज के बाहर निर्देशिका से .Files.Glob का उपयोग करके configmap/secrets में फ़ाइलों का अतिरिक्त सेट शामिल करें।

संकट

पैकेज अधिकृत खोज निर्देशिकाओं से बच नहीं सकता है।

समाधान

sysadmin द्वारा निर्दिष्ट अतिरिक्त निर्देशिकाओं में फ़ाइलों को खोजने के लिए --search-directories पैरामीटर जोड़ें, फ़ाइलें चार्ट के फ़ाइलसेट में लोड की जाएंगी, फ़ाइलें ऑब्जेक्ट के लिए उपलब्ध हैं।

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

ओपी ( --include-file=foobar-license.conf ) में प्रस्ताव एक उचित समाधान की तरह लगता है अगर कोई इस सुविधा से निपटना चाहता है! मेरा सुझाव है कि हम तब तक प्रतीक्षा करें जब तक कि हमारे पास नए फीचर कार्य पर काम करने से पहले हेल्म 3 की अल्फा रिलीज उपलब्ध न हो जाए; हेल्म 2 और हेल्म 3 का विकास एक ऐसे बिंदु पर पहुंच गया है जहां हम हेल्म 3 में नई हेल्म 2 सुविधाओं को पोर्ट करने में सक्षम नहीं होंगे, यही वजह है कि हम नई सुविधाओं को हालिया रिलीज में मर्ज करने और केवल बगफिक्स पर काम करने में संकोच कर रहे हैं। उम्मीद है ये मदद करेगा!

नमस्ते,

इस मुद्दे की स्थिति पर कोई अपडेट? हेल्म 3 के लिए कैसा चल रहा है?

मैं भी पूछ रहा हूँ.. traefik ssl सामग्री f.ex के लिए इसे बहुत पसंद करेंगे। :)

AFAIK समुदाय से किसी ने भी हेल्म 2 के लिए इस काम से निपटना शुरू नहीं किया है।

नमस्ते, इस विषय पर नवीनतम क्या है? हम अनुरोधित व्यवहार की भी तलाश कर रहे हैं। धन्यवाद

पहले जैसा ही। कोई अपग्रेड नहीं।

अभी भी इस पर एक अपडेट की प्रतीक्षा कर रहा है

यह बहुत अच्छा होना चाहिए यदि आप --include-folder=<path to folder> जैसे विकल्प प्रदान करते हैं और हेल्म ऐसा व्यवहार करता है जैसे फ़ोल्डर हेल्म चार्ट के मूल में है। हमारे मामले में एक भी फाइल शामिल करने से समस्या का समाधान नहीं हो रहा है। उस फ़ोल्डर में सैकड़ों फ़ाइलें और उप निर्देशिकाएं हो सकती हैं।

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

यदि आप हेल्म 3 के लिए इस सुविधा का योगदान करने में रुचि रखते हैं, तो कृपया हमें बताएं ताकि हम बाकी टीम के साथ प्रयासों को समन्वयित करने/संघर्षों को मर्ज करने का प्रयास कर सकें।

अभी भी इस पर एक अपडेट की प्रतीक्षा कर रहा है

यदि और अपडेट हैं, तो हम उन्हें यहां साझा करेंगे।

धन्यवाद!

अगर यह किसी की मदद करता है, तो मैं अपनी जरूरतों के लिए इस सीमा के आसपास काम करने में कामयाब रहा हूं।
मैं थोडा नया हूँ, इसलिए यह एक प्रसिद्ध दृष्टिकोण हो सकता है

मेरी फ़ोल्डर संरचना:

├───mainfests
│   └───[app_name]
│       ├───charts
├───[app_name]
│   └───resources
│       ├───config-prod.json
│       ├───config-staging.json

मेरी समस्या:

मैं कॉन्फ़िगरेशन फ़ाइलों की सामग्री को k8s configMap में कॉपी करने का प्रयास कर रहा था, लेकिन मैंने उस सीमा को मारा है जहां मैं कॉन्फ़िगरेशन फ़ाइलों का संदर्भ नहीं दे सका, क्योंकि वे हेलम चार्ट के बाहर हैं।

मेरा समाधान:

मैंने कॉन्फ़िगरेशन फ़ाइल की सामग्री की प्रतिलिपि बनाने के लिए सेट-फ़ाइल का उपयोग किया है

helm install --set-file ``configValues=./[app-name]/config/config_prod.json

और मेरे शीर्ष परिनियोजन yaml में इसे इस तरह संदर्भित किया गया है:

apiVersion: v1
kind: ConfigMap
metadata:
  name: <config-name>
data:
  {{ printf "config_%s.json" .Values.envType }}: |-
  {{ .Values.configValues }}`

(बिना सफलता के लाइन ब्रेक को ठीक करने के लिए कई बार संपादित)

प्रमाणपत्रों के लिए प्राथमिक रूप से इस तरह की एक आवश्यक विशेषता .. अन्यथा यह नौकरी के लिए बहुत जटिल हो जाती है

आप अतिरिक्त संसाधनों के साथ एक चार्ट बना सकते हैं और फिर आवश्यकताओं के माध्यम से वास्तविक चार्ट को उपचार्ट के रूप में उपयोग कर सकते हैं। yaml

अगर यह किसी की मदद करता है, तो मैं अपनी जरूरतों के लिए इस सीमा के आसपास काम करने में कामयाब रहा हूं।
मैं थोडा नया हूँ, इसलिए यह एक प्रसिद्ध दृष्टिकोण हो सकता है

मेरी फ़ोल्डर संरचना:

├───mainfests
│   └───[app_name]
│       ├───charts
├───[app_name]
│   └───resources
│       ├───config-prod.json
│       ├───config-staging.json

मेरी समस्या:

मैं कॉन्फ़िगरेशन फ़ाइलों की सामग्री को k8s configMap में कॉपी करने का प्रयास कर रहा था, लेकिन मैंने उस सीमा को मारा है जहां मैं कॉन्फ़िगरेशन फ़ाइलों का संदर्भ नहीं दे सका, क्योंकि वे हेलम चार्ट के बाहर हैं।

मेरा समाधान:

मैंने कॉन्फ़िगरेशन फ़ाइल की सामग्री की प्रतिलिपि बनाने के लिए सेट-फ़ाइल का उपयोग किया है

helm install --set-file configValues=./[app-name]/config/config_prod.json ``

और मेरे शीर्ष परिनियोजन yaml में इसे इस तरह संदर्भित किया गया है:

apiVersion: v1
kind: ConfigMap
metadata:
  name: <config-name>
data:
  {{ printf "config_%s.json" .Values.envType }}: |-
  {{ .Values.configValues }}`

(बिना सफलता के लाइन ब्रेक को ठीक करने के लिए कई बार संपादित)

संसाधन फ़ाइलें क्या हैं टेक्स्ट या जेसन प्रारूप नहीं थे, मेरे मामले में मेरे पास संसाधन फ़ाइलें हैं क्योंकि मेरे आवेदन की कॉन्फ़िगरेशन के लिए उपयोग की जाने वाली युद्ध फाइलें हैं

मैं वर्तमान में इसे configmap के साथ करता हूं:

 data:                                                                                                                                                                                                                              
   my-configuration.php: |-                                                                                                                                                                                                      
     {{- .Files.Get "admin-configs/my-configuration.php" | nindent 4 }}  
   other-configuration.yaml: |-                                                                                                                                                                                                    
     {{- .Files.Get "admin-configs/other-configuration.yaml" | nindent 4 }} 

और मैं कॉन्फ़िगरेशन फ़ाइलों को व्यवस्थापक-कॉन्फ़िगरेशन फ़ोल्डर (चार्ट के नीचे) में रखता हूं - हेल्म चलाने से पहले, और यह उन फ़ाइलों की सामग्री को कॉन्फिगमैप में जोड़ता है - जिसे बाद में पॉड्स के अंदर रखा जा सकता है, और फाइलों के रूप में लैंड किया जा सकता है।

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

मैंने टिप्पणियों के माध्यम से पढ़ा है और लोग दो उपयोग-मामलों के बारे में बात करते हैं: प्रमाणपत्र और चार्ट ओवरराइड।

1. प्रमाण पत्र।
ये सीक्रेट्स या कॉन्फिगमैप्स में जाते हैं। मुझे विश्वास है कि जब आप helm कॉल करते हैं तो आपको इन्हें स्ट्रिंग के रूप में सेट करना चाहिए, उदाहरण के लिए बैश स्क्रिप्ट से। इससे आगे जाकर, आप एक स्क्रिप्ट लिख सकते हैं जो भंडारण से रहस्य प्राप्त करती है, जैसे हाशीकॉर्प की तिजोरी, और रनटाइम पर मूल्यों के माध्यम से पॉप्युलेट होती है।

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

तो, यह समाधान लचीला और पर्याप्त स्क्रिप्ट योग्य है। मेरे दिमाग में, हेल्म को अपने तत्काल दायरे से बाहर के रहस्यों को प्रबंधित करने की कोशिश नहीं करनी चाहिए, जो कि एक चार्ट है; इसमें कहीं से भी रहस्य लाना शामिल है, यहां तक ​​कि फाइलें भी।

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

@bacongobbler , आपने इस मुद्दे को हेल्प वांटेड के रूप में सेट किया है, इसलिए मैं आपको टैग कर रहा हूं। कोई विचार?

अरे @vladfr - मैं आंशिक रूप से सहमत हूं, लेकिन 100% नहीं :)। मैं अब प्रमाण पत्र के उपयोग के मामले के बारे में बात कर रहा हूं, और यह विशुद्ध रूप से व्यक्तिगत अनुभव पर आधारित है, जिसका अर्थ है कि यह व्यापक रूप से लागू नहीं हो सकता है। एक आंतरिक परियोजना के लिए, मैं सहमत हूँ। आप अपने प्रमाणपत्रों को तिजोरी जैसी किसी चीज़ में संग्रहीत करना चाहते हैं । एक स्क्रिप्ट लिखना जो वहां से डेटा प्राप्त करता है और बस पैरामीटर के माध्यम से बेस 64-कोडित मान जोड़ता है, ठीक है। आपके पास नियंत्रण है, कोई बात नहीं।

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

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

प्रमाणपत्रों के अलावा हमारे पास एक और उपयोग-मामला जोड़ने के लिए: लाइसेंस (जैसे लाइसेंस कुंजी फ़ाइलें) जो सॉफ़्टवेयर उपयोग को प्रतिबंधित करते हैं। यह मामला आसान है क्योंकि हम पहले से ही --set माध्यम से इसे सेट करने की अनुमति देने के लिए बेस 64-एन्कोडेड प्रारूप में लाइसेंस प्रदान कर सकते हैं, या पूर्व-कॉन्फ़िगर किए गए values.yaml जिसे आप अभी लागू कर सकते हैं।

इसलिए, मुझे अभी भी लगता है कि यह सुविधा बहुत उपयोगी होगी।

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

धन्यवाद, @vladfr।

मैं इस पर @lenalebt के साथ

मुझे यकीन है कि इसे लागू करने के कुछ तरीके हैं, और सामुदायिक प्रतिक्रिया सबसे शानदार तरीका निर्धारित करने में मदद कर सकती है।

व्यक्तिगत रूप से, मैं .Files.GetExternal की तर्ज पर एक नया फ़ंक्शन प्रदान करूंगा, जिसे .Files.Get असुरक्षित विकल्प के रूप में अच्छी तरह से प्रलेखित किया जा सकता है।

कृपया इसे लागू करने पर विचार करें। यहां तक ​​कि kustomize बाहरी फाइलों को एक्सेस करने की अनुमति देने के लिए कमांड लाइन फ्लैग प्रदान कर रहा है।

ऐसा लगता है कि इस सुविधा के लिए पर्याप्त सहमति से अधिक है। हम इसे लागू करने के लिए समय देने के इच्छुक स्वयंसेवकों की तलाश कर रहे हैं। हमारे पास वास्तव में इसे स्वयं लिखने का समय नहीं है लेकिन हम सीखने की प्रक्रिया के माध्यम से दूसरों की मदद करने को तैयार हैं। @solacens क्या आप इसे लागू करने के लिए समय देना चाहेंगे?

@bacongobbler मैं इस पर एक

महान!

मैं यह सुनिश्चित करने के लिए @ankul के साथ जांच उठा रहा है। उन्होंने मुझे आज से पहले स्लैक पर मैसेज किया और फीचर को लागू करने में रुचि व्यक्त की।

प्रस्तावित --include-file=foobar-license.conf ध्वज के लिए:

• क्या हम उम्मीद करते हैं कि उपयोगकर्ता सभी फाइलों को एक निर्देशिका में एकत्र करेंगे और उन्हें उचित नाम देंगे? यदि हां, तो उपयोक्ता को उपयुक्त नामों की सूचना कैसे दी जाती है ?
  https://github.com/helm/helm/issues/1754#issuecomment -271381902 से उद्धरण

  मैं value.yml (और --set) को "इंटरफ़ेस" के रूप में देखता हूं जिसमें इनपुट हेलम को पास किए जाते हैं।

  इस दृष्टिकोण में, फ़ाइल नाम अब चार्ट में एक मनमाना इनपुट होगा।

• क्या हमारे पास files निर्माण values समान होना चाहिए ताकि यह सूचीबद्ध किया जा सके कि चार्ट किस फ़ाइल नाम की अपेक्षा करता है? उपयोगकर्ता उन फ़ाइलों को --include-file key1=path1 key2=path2 रूप में पास कर सकते हैं जहां अपेक्षित कुंजी helm show files में सूचीबद्ध हैं files.yml ।

  .. या क्या उपयोगकर्ता ने फ़ाइल नाम को मान के रूप में निर्दिष्ट किया है?

@ juliohm1978 मुझे यकीन नहीं है कि कैसे Files.GetExternal असुरक्षित होगा (या इसकी आवश्यकता क्यों है)। इन फ़ाइलों को Files ऑब्जेक्ट ( Get , GetBytes , Glob , Lines आदि) पर मौजूद समान विधियों के माध्यम से उपलब्ध कराया जा सकता है। .

मुझे आशा है कि मैं कुछ ऐसा याद नहीं कर रहा हूँ जिस पर अब तक पहले ही चर्चा की जा चुकी है।

@anukul आप यह पता लगाने के बारे में एक अच्छी बात करते हैं कि किस फ़ाइल नाम की अपेक्षा की जाए। दस्तावेज़ीकरण एक तरीका है लेकिन यह आदर्श नहीं है।

मैं एक अलग दृष्टिकोण का सुझाव देना चाहूंगा।

फ़ाइल सामग्री को मान में प्राप्त करने के लिए उपयोग-मामला है। फ़ाइल को सीधे मान चर में पढ़ने के बारे में कैसे? कुछ इस तरह: --set certificate={{file://path/to/your/file}} । हेल्म को प्रत्येक मान को पार्स करने और यह देखने की आवश्यकता होगी कि क्या यह file:// योजना में फिट बैठता है, फिर फ़ाइल को स्ट्रिंग के रूप में पढ़ें और कुंजी सेट करें। यह yaml माध्यम से भी काम करेगा।

इस तरह, फ़ाइल नाम अब प्रासंगिक नहीं हैं। चार्ट लेखकों का नियंत्रण होगा कि फ़ाइल सामग्री कहाँ प्राप्त करें, और उपयोगकर्ता आसानी से मनमानी फ़ाइलों को मूल्यों के रूप में पास कर सकते हैं, कहीं भी उन्हें पसंद करते हैं। Files.Get अब और उपयोग नहीं किया जाएगा।

क्या इसका कोई मतलब है?

यह --set-file जैसा लगता है, जो आज पहले से मौजूद है। अपने उदाहरण में, आप --set-file certificate=/path/to/your/file , फिर फ़ाइल के डेटा तक पहुंचने के लिए अपने टेम्प्लेट में .Values.certificate कॉल करें।

https://github.com/helm/helm/blob/07a3d7299c7fa9e0e36953623b6a4917f06bbe53/cmd/helm/flags.go#L37

नमस्ते,
मेरे मन में जो था वह -I cc लिए स्विच या -L स्विच करने जैसा है ld , फ़ाइल खोज पथ में अतिरिक्त निर्देशिका जोड़ें।
वर्तमान में, जेनेरिक फाइलों को पुनरावृत्त/पढ़ते समय फाइलों के लिए केवल चार्ट निर्देशिकाओं की खोज की जाती है, जबकि आवश्यकता उसी तरह से आउट-ऑफ-ट्री फाइलों को खोजने की है।
उदाहरण के लिए, एक चार्ट में एक निर्देशिका हो सकती है जिसमें कॉन्फ़िगरेशन फ़ाइलों को संग्रहीत किया जाता है *.yaml , चार्ट प्रत्येक फ़ाइल के लिए प्रविष्टि के साथ एक कॉन्फिगरमैप बनाने के लिए इस निर्देशिका में सभी फ़ाइलों को पुनरावृत्त करता है।
आवश्यकता यह है कि चार्ट को चार्ट रूट या टारबॉल के बाहर अतिरिक्त फ़ाइलों की खोज करने की अनुमति दी जाए, ताकि इस मामले में sysadmin अतिरिक्त *.yaml फ़ाइलों को कॉन्फिगमैप में इंजेक्ट करने के लिए जोड़ सके।
चार्ट तर्क को बदले बिना अतिरिक्त छाया निर्देशिकाओं की खोज के लिए इसे -I<directory> (एकाधिक स्थानों के विकल्प के साथ) के साथ आसानी से स्थापित किया जा सकता है।
धन्यवाद!

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

apiVersion: v1
kind: ConfigMap
metadata:
  name: conf
data:
  boot.properties: |
    <paste file content here>
  jndi.properties: |
    <paste file content here>

मैं समझता हूं कि यह एक सुरक्षा विशेषता है, लेकिन हम में से कुछ वास्तव में शीर्ष चार्ट के लेखक हैं और हमें खुद पर भरोसा है कि हम खुद पर हमला करने की कोशिश नहीं कर रहे हैं। इसलिए मैं इस सुरक्षा सुविधा को अक्षम करने की संभावना जोड़ने का सुझाव देता हूं (--allow-all-files)

FWIW मामले में कोई ConfigMap निर्माण की तलाश में है: https://helm.sh/docs/chart_template_guide/accessing_files/

@रवींद्रनाथकीला

हेल्म दस्तावेज़ीकरण काम नहीं करता है।

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

@theAkito , जैसा कि मैंने इस सूत्र में कुछ समय पहले उल्लेख किया

अब तक, मैंने सुझाव के अनुसार इस सुविधा

मैं देख रहा हूँ कि आप इस विशेषता के बारे में काफी भावुक महसूस कर रहे हैं। इसे लागू करने पर काम करने के बारे में आप कैसा महसूस करेंगे?

पोस्ट-रेंडर हुक पेश किए जाने के बाद से अब भी आप किसी भी बाहरी फाइल को इंस्टॉलेशन में जोड़ सकते हैं

https://github.com/helm/helm/issues/7260

मैं देख रहा हूँ कि आप इस विशेषता के बारे में काफी भावुक महसूस कर रहे हैं। इसे लागू करने पर काम करने के बारे में आप कैसा महसूस करेंगे?

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

पोस्ट-रेंडर हुक के माध्यम से अनुकूलन का उपयोग करने का एक उदाहरण यहां दिया गया है
https://github.com/helm/helm/issues/7260

यहाँ बाहरी फ़ाइल से कॉन्फिगरेशन बनाने का एक उदाहरण दिया गया है:
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/#configmapgenerator

मुझे विश्वास है कि इस मुद्दे को बंद किया जा सकता है।

यहाँ एक और भी सरल उदाहरण है:

श.शो

#!/bin/bash

sed "s/TOKEN_TO_REPLACE/$(cat file.txt)/"

फ़ाइल.txt

some content

का आनंद लें:
helm install --post-renderer ./sh.sh stable/some_helm_chart

आपको नकली सामग्री TOKEN_TO_REPLACE साथ कॉन्फिग मैप बनाने की जरूरत है

_लेकिन yaml_ में लाइन इंडेंटेशन के साथ समस्या हो सकती है

@ आर-ओएमके, जैसा कि डॉक्टर में कहा गया है:
"_हुक द्वारा बनाए गए संसाधनों को वर्तमान में रिलीज़ के हिस्से के रूप में ट्रैक या प्रबंधित नहीं किया जाता है।_"

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

एक नए " --search-folder " ध्वज के बारे में क्या जिसे कई बार सेट किया जा सकता है? और जहां तक ​​फाइलों को छानने की समस्या है, यह ठीक उसी तरह के नियमों को लागू कर सकता है, जैसा कि वर्तमान में .File.Glob आदि द्वारा लागू किया गया है, इसलिए यहां कोई नई जटिलता या विवरण नहीं है।

@titou10titou10

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

इसके बारे में हुक: pre/post - install/delete/upgrade/rollback

post-renderer एक पूरी तरह से अलग तरह का हुक है

@ आर-ओम्क, काफी उचित। डॉक्टर इसमें पिछड़ रहे हैं
लेकिन मैं अभी भी नहीं देख सकता कि मैं पोस्ट-रेंडरर हुक के साथ अपनी समस्याओं को कैसे हल कर सकता हूं।
हमारे उपयोग के मामले में से एक:

• हम एक जावा ऐप बनाने के लिए जेनकींस पाइपलाइन का उपयोग करते हैं और इसे ओपनशिफ्ट में तैनात करते हैं
• हम इसके लिए ओपनशिफ्ट "टेम्पलेट्स" का उपयोग कर रहे थे और हेल्म में जाने की कोशिश कर रहे थे क्योंकि यह अधिक लचीला है और हमने तैनाती के लिए एक कस्टम चार्ट बनाया है
• परिनियोजन प्रक्रिया में बिल्ड द्वारा गतिशील रूप से बनाई गई विभिन्न क्लासिक गुण फ़ाइलों के साथ एक ConfigMap बनाना शामिल है, वे सभी एक ही निर्देशिका में हैं (बिल्ड उन्हें किसी भी स्थान पर रख सकता है ..)
• यह " Files.Glob(<ext dir>) / AsConfig() " फ़ंक्शन के लिए एक आदर्श उम्मीदवार है, दुर्भाग्य से गुण फ़ाइलें चार्ट के बाहर बनाई गई हैं, यह वर्तमान में संभव नहीं है
• टिप्पणियाँ: गुण फ़ाइलों के नाम गतिशील हैं, फ़ाइलों की संख्या भी गतिशील है, निर्माण उन्हें एक निर्देशिका में समूहित करता है

हो सकता है कि पोस्ट-रेंडरर हुक का उपयोग करने से हमें मदद मिल सके, लेकिन मैं यह नहीं देखता कि कैसे, और IMHO यह सिर्फ एक वर्कअराउंड होगा, लेकिन इस स्तर पर सभी "वर्कअराउंड" का स्वागत है
और या तो " --search-folder " ध्वज जोड़ना या .Files.GlobExternal() / .Files.GetExternal() फ़ंक्शंस जोड़ना जैसा कि कोई सुझाव देता है एक वैध समाधान प्रतीत होता है लेकिन पहला अधिक सुरक्षित आईएमएचओ है क्योंकि यह चार्ट को स्थानीय तक पहुंच प्रदान करता है फ़ोल्डरों

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

हालाँकि, एक स्पष्ट -इनक्लूड-फाइल या -इनक्लूड-डीआईआर को स्वीकार किया जाएगा, जैसा कि पहले की टिप्पणी में बताया गया है: https://github.com/helm/helm/issues/3276#issuecomment -412942372

ऐसे मामले हैं जहां आप उन टेम्प्लेट के लिए रेंडरिंग चरण के भाग के रूप में फ़ाइलें शामिल करना चाहेंगे। एक पोस्ट-रेंडर सभी मामलों को संभाल नहीं सकता है।

@bacongobbler काफी अच्छा है।
आइए आशा करते हैं कि एक --include-dir नया ध्वज इस उपयोग के मामले को पूरा करने के लिए .Files.Glob(<dir>).AsConfig() या समकक्ष सुविधा का उपयोग करने की अनुमति देगा, जो मुझे लगता है, एक पाइपलाइन में बहुत आम है

या शायद सीआईसीडी पाइपलाइन परिदृश्य में सही उपकरण नहीं है जहां कई "डेटा" को शुद्ध "मूल्य" तरीके से व्यक्त नहीं किया जा सकता है ( -f , --set या --set-file ) और चार्ट के बाहर आयोजित किया जाता है

अभी के लिए मैं केवल एक ही समाधान देख रहा हूं कि चार्ट को कहीं और लाना है, चार्ट ट्री के नीचे बाहरी फाइलों को कॉपी करें, उस स्थानीय कॉपी से रन हेल्म

मुझे समझ में नहीं आता क्यों रिलीज के अंदर कच्ची फाइलें?

हेल्म v3 अब सर्वर साइड टेम्प्लेट रेंडरिंग नहीं चलाता है। इसलिए, आप Files.Glob का उपयोग नहीं कर सकते।
यह समस्या केवल हेलम v2 के लिए वास्तविक है।

@bacongobbler मैं इस सुविधा को जोड़ने के लिए 100% नीचे हूं। मेरा प्रस्तावित कार्यान्वयन ( kubectl create secret generic --from-file=... से प्रेरित) होगा:

helm install --include-file [<key>=]<path>[,[<key2>=]<path2>...] --include-dir [<prefix>=]<dirpath>

जहां <key> वह पथ है जिसे .Files.Get तर्क के रूप में स्वीकार किया जाएगा, और <path> के बेसनाम में डिफ़ॉल्ट रूप से स्वीकार किया जाएगा। उदाहरण के लिए, --include-file foo.txt=../dir/bar.txt की सामग्री बनाना होगा ../dir/bar.txt के माध्यम से सुलभ .Files.Get "foo.txt" ।

निर्देशिका के लिए, की सभी सामग्री dirpath करने के लिए उनके रास्ते रिश्तेदार के तहत उपलब्ध कराया जाएगा <dirpath> एक वैकल्पिक साथ, prefix संलग्न। उदाहरण के लिए, यदि mydir/ में foo.txt और bar.txt , और मैं इसे --include-dir mydir/ रूप में आमंत्रित करता हूं, तो फ़ाइलें foo.txt और bar.txt दृश्यमान हो जाना; जब --include-dir baz/qux=mydir/ रूप में बुलाया जाता है, तो वे फ़ाइलें baz/qux/foo.txt और baz/qux/bar.txt रूप में दिखाई देती हैं।

अगर यह उचित लगता है, तो मैं इस सप्ताह के अंत में शुरू कर सकता हूं।

(मुख्य नकारात्मक पक्ष यह है कि हम/मेरे नियोक्ता वैसे भी कुछ समय के लिए इसका उपयोग नहीं कर पाएंगे, क्योंकि हमें हेलम के पुराने संस्करणों का भी समर्थन करना होगा, लेकिन मुझे लगता है कि पहले से कहीं ज्यादा देर हो चुकी है)

यह बहुत अच्छा लगता है, धन्यवाद! मैं पीआर के लिए तत्पर हूं।

@misberner क्या आप पुष्टि कर सकते हैं कि --include-dir <prefix>=<dirpath> का उपयोग करने से हमें .Files.Glob(<prefix>).AsConfig() का उपयोग करने की अनुमति मिल जाएगी, और इसलिए <dirpath> में सीएम प्रति फ़ाइल में एक प्रविष्टि के साथ एक ConfigMap बनाएं?

हाँ यही विचार है। मेरे दृष्टिकोण से एक खुला प्रश्न यह है कि क्या --include-dir एक निर्दिष्ट <prefix> साथ एक ओवरले का परिचय देता है, या पिछले आर्ग से और बंडल से ही <prefix>/ तहत सब कुछ छाया करता है। मैं उस पर सुपर राय नहीं रखता लेकिन पूर्व को पसंद करूंगा।

पिंग @misberner. कोइ प्रगति?

अरे! मुझे अभी एक और मामला मिला है जहाँ यह सुविधा उपयोगी होगी।
@bacongobbler मैं देख रहा हूँ कि यह अभी भी खुला है - क्या यह समस्या

स्वतंत्र महसूस करना

कुछ समय बिताया, मेरे पास फाइल फ्लैग काम कर रहा है, और एक प्राथमिकी झंडा भी जोड़ने की योजना बना रहा है।

मैंने चार्ट इनक्यूबेटर/कच्चे को दूसरे चार्ट के रूप में तैनात करके इसके आसपास काम किया है

पीआर अब समीक्षा के लिए खुला है।

@vladfr लगता है कि पीआर को

हमने पिछले हफ्ते देव कॉल पर इसके बारे में बात की थी। @vladfr मौजूद था और उसने सवाल उठाया कि क्या हम इसे 3.3.0 के लिए प्राप्त कर सकते हैं।

3.3.0 के हमारे वर्तमान कार्यभार के साथ हमारे पास इस पीआर की समीक्षा करने के लिए निवेश करने के लिए पर्याप्त समय नहीं है। अभी हम उन समुदाय के सदस्यों तक पहुंच रहे हैं जिन्होंने 3.3.0 के लिए पीआर लिखा है और मर्ज विंडो बंद होने से पहले उन्हें अपने पीआर को ठीक करने के लिए कह रहे हैं और हमने रिलीज को काट दिया है। E_TOO_MANY_PRS_TO_REVIEW

एक बार जब 3.3.0 दरवाजे से बाहर हो जाता है तो हम इस बातचीत को फिर से देख सकते हैं।

निम्नलिखित

निम्नलिखित भी

आसपास काम था:
{{- श्रेणी $datakey, $dataval:= $cm.fileList }}
{{- $डेटाकी | निंडेंट 2 }}: |-
{{- $fullPath := printf "configFiles/%s" $dataval }}
{{- $. फ़ाइलें। $fullPath प्राप्त करें | निंडेंट 4 }}
{{- समाप्त }}

इस पर कोई अपडेट, हम 3.3.1 पोस्ट कर रहे हैं

--include-dir का उपयोग करना एक अच्छा तरीका लगता है। v3.4.0 प्रतीक्षा कर रहे हैं

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

यह कार्यक्षमता इतनी उपयोगी होगी - क्या हम इसे जल्द ही प्राप्त कर सकते हैं?

कृपया इसमें अपना +1 जोड़ने के लिए कृपया। मैंने अभी 4 घंटे बिताए हैं यह पता लगाने की कोशिश में कि मेरा सिंटैक्स गलत कैसे था; जब वास्तव में यह चुपचाप इस तथ्य को अनदेखा कर रहा था कि मैं चार्ट परिनियोजन फ़ोल्डर के बाहर एक पूर्ण पथ से गुजर रहा था। जब तक मुझे यह समस्या नहीं मिली, तब तक काम नहीं किया!

यूनिक्स सिस्टम में हेलम चार्ट डायरेक्टरी ट्री के बाहर निर्देशिकाओं में फाइलों तक पहुंच प्रतीकात्मक लिंक का उपयोग करके प्राप्त की जा सकती है (कम से कम हेल्म 3.3.4 का उपयोग करके)

कृपया इसमें अपना +1 जोड़ने के लिए कृपया। मैंने अभी 4 घंटे बिताए हैं यह पता लगाने की कोशिश में कि मेरा सिंटैक्स गलत कैसे था; जब वास्तव में यह चुपचाप इस तथ्य को अनदेखा कर रहा था कि मैं चार्ट परिनियोजन फ़ोल्डर के बाहर एक पूर्ण पथ से गुजर रहा था। जब तक मुझे यह समस्या नहीं मिली, तब तक काम नहीं किया!

@catdevnull - उसी स्थिति से