Helm: السماح للدفة بإضافة ملفات خارجية لتخطيط النشر

مرحبا لينا ،

الطريقة الحالية:
الطريقة الحالية لتنفيذ إضافة محتوى الملف هي استخدام المعلمة "--values" n-dimensional- عند استدعاء تثبيت helm. يجب أن يوفر وضع كل ملف (قيم التكوين العادية ، عناصر SSL ، الترخيص) في ملف YML منفصل إمكانية قراءة أفضل.

لنفترض أننا نستخدم "Firstspirit" كاسم مستودع رسم بياني ، والذي يوفر بعد ذلك المخطط (المخططات) للعميل. ثم يمكن للعميل نشر الرسم البياني الخاص بك عبر المكالمة:

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

ضمن المخطط الخاص بك ، يمكنك الآن التحقق من صحة ما إذا كانت جميع المفاتيح المطلوبة بها مجموعة قيم (ssl cert (s) ، الترخيص ، ..).
يمكن تخزين ملف الترخيص محليًا ، وعند الإرسال إلى مجموعة kubernetes ، يجب تخزينها كأسرار kubernets. لزيادة سرعة التطوير ، يمكنك توفير ssl zert مُنشأ مسبقًا كقيمة افتراضية.

كمحترفين آخرين ، يمكن للعميل أتمتة إنشاء شهادة SSL بواسطة أدوات الطرف الثالث وإنشاء ملفات .yml بنفسه لتعيين قيم سرية kubernetes الخاصة بك خارج Helm وتمرير الملفات التي تم إنشاؤها إلى Helm لأمر "تثبيت الدفة".

تحياتي الحارة،
ماركوس

مرحبًا ماركوس ،
غير متأكدين مما إذا كنا نفهم بعضنا البعض بشكل صحيح. للتوسع قليلاً في حالة الاستخدام الخاصة بي ، هذا ما يحتويه الرسم البياني الخاص بي حاليًا:

...
{{ 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 }}
...

أردت عدم إجبار المستخدمين على توفير سلاسل بتشفير base64 في ملفات yaml ، ولكن بدلاً من ذلك أعطي الملفات مباشرة. ومع ذلك ، يجب أن تكون الملفات جزءًا من المخطط نفسه ولا يمكن تقديمها من الخارج ، ومن هنا تأتي هذه التذكرة.

لدي هذه الحاجة بالضبط. ينشر المخطط الخاص بي قراءة سرية من ملف في /keybase . هذا الملف غير موجود في الرسم البياني عمدًا.

أعتقد أن ملفات .Files.Get لا يجب أن تُفترض أن تكون داخل المخطط:

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

أنا متأكد تمامًا من أن عدم القدرة على الوصول إلى نظام الملفات بشكل تعسفي هو ميزة أمان .Files.Get ، لذلك لا أعتقد أن السلوك الحالي خاطئ - فهو لا يفي بجميع حالات الاستخدام.

يتمثل أحد الحلول البديلة في توزيع الشهادات والتراخيص الخاصة بك كإصدار منفصل للدفة. عندما تضعهم في خرائط التكوين باسم يعرفه نشر الخدمة ، استخدم configmap / secrets volume mount في نشر الخدمة.

ربما كان هذا ما اقترحه @ cr4igo بالفعل :)

نواجه نفس المشكلة مع حالة استخدام مشابهة جدًا:

لدينا شهادات لخدمات إشعارات الدفع من Apple و Googles ؛ لدينا شهادات مختلفة لبيئات الاختبار والإنتاج الخاصة بنا ، لذلك لا يمكننا تجميع الشهادة في المخطط (تجاهل المخاوف الأمنية حول القيام بذلك) ؛ نود بشكل مثالي أن نكون قادرين على وضع مسار الملف في ملف القيم وجعل Helm يقوم بتحميل هذا الملف.

ليس لدي أي اقتراحات جيدة حول كيفية إخبار هيلم بأن السلسلة الموجودة في ملف القيم هي مسار ملف نسبي - ربما يتم لفها في نوع من بناء $file("path/goes/here") لكن يبدو أنها فوضوية.

على سبيل المثال
القيم

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 }}$

يفشل هذا في العرض في حالة الإشارة إلى الملفات الموجودة داخل helm repo ، على سبيل المثال:
helm - set valuefile = / tmp / my-dynamic-file [...]

إذا تم نسخ الملف نفسه إلى جذر الدفة وأشار بمسار نسبي ، فسيعمل الأمر نفسه.
يعمل المثال أدناه فقط في حالة الإشارة إلى الملفات الموجودة داخل helm repo أو فشل أي شيء خارجي ،

أهلا،

أود أن أقترح نهجًا مشابهًا للمعالج C ... افتراضيًا يكون له مسار البحث داخل المخطط ، ولكن أضف --search-directories = معلمة للسماح بدلائل إضافية. هذا سوف يفي بمتطلبات الأمان حيث يجب أن يحدد مسؤول النظام مكان وجود الملفات الإضافية ، وسوف يجعل Files :: glob تعمل بشكل صحيح.

ماذا تعتقد؟

حالة الاستخدام

قم بتضمين مجموعة إضافية من الملفات إلى configmap / secrets باستخدام .Files.Glob من دليل خارج حزمة المخطط ، دون استخراج الحزمة.

مشكلة

يجب ألا تتخطى الحزمة أدلة البحث المصرح بها.

المحلول

إضافة معلمة --search-directories للبحث عن الملفات في الدلائل الإضافية التي يحددها مسؤول النظام ، سيتم تحميل الملفات في مجموعة ملفات المخطط ، المتاحة لكائن الملفات.

نعتذر عن التأخير في الرد. كان الفريق الأساسي (بما فيهم أنا) يركز فقط على الحصول على إصدار ألفا من Helm 3 خارج المنزل ، لذا فإن أي تطوير على المساهمات الكبيرة في Helm 2 كان أكثر صعوبة لتخصيص الموارد لمراجعة الأقران وأعمال التصميم في هذا الوقت.

يبدو الاقتراح في OP ( --include-file=foobar-license.conf ) كحل معقول إذا أراد شخص ما معالجة الميزة! أقترح بشدة الانتظار حتى يتوفر لدينا إصدار ألفا من Helm 3 قبل العمل على ميزة جديدة للعمل بالرغم من ذلك ؛ تباعد تطوير Helm 2 و Helm 3 لدرجة أننا لن نكون قادرين على نقل ميزات Helm 2 الجديدة إلى Helm 3 ، وهذا هو سبب ترددنا في دمج الميزات الجديدة في الإصدارات الحديثة والعمل فقط على إصلاحات الأخطاء. أتمنى أن يساعدك هذا!

أهلا،

أي تحديث عن حالة هذه القضية؟ كيف تسير الأمور بالنسبة إلى Helm 3؟

أنا أسأل أيضا .. سوف يعجبني كثيرا بالنسبة لأشياء traefik ssl f.ex. :)

AFAIK لم يبدأ أي شخص من المجتمع في معالجة هذا العمل لـ Helm 2.

مرحبًا ، ما آخر أخبار هذا الموضوع؟ نحن نبحث أيضًا عن السلوك المطلوب. شكرا

كما في وقت سابق. لا تحديث.

ما زلت في انتظار التحديث على هذا

يجب أن يكون رائعًا أيضًا إذا قمت بتوفير خيار مثل --include-folder=<path to folder> ويتصرف Helm مثل هذا المجلد في جذر مخطط Helm. تضمين ملف واحد لا يحل المشكلة في حالتنا. قد يكون هناك مئات الملفات والأدلة الفرعية في هذا المجلد.

أنا أضع علامة على هذه الميزة على أنها "مطلوب مساعدة". سيكون من الرائع الحصول على هذه الميزة ، لكننا مشغولون بإعادة تشغيل بنية Helm 3 بحيث لا يتوفر لدينا الوقت للتركيز على تنفيذ ميزات جديدة مثل هذه الميزة.

إذا كنت مهتمًا بالمساهمة بهذه الميزة في Helm 3 ، فيرجى إخبارنا حتى نتمكن من محاولة تنسيق الجهود / دمج التعارضات مع بقية الفريق.

ما زلت في انتظار التحديث على هذا

إذا كانت هناك تحديثات أخرى ، فسنشاركها هنا.

شكرا!

في حال كان ذلك يساعد أي شخص ، فقد تمكنت من التغلب على هذا القيد لاحتياجاتي.
أنا جديد نوعا ما في القيادة ، لذلك قد يكون نهجا معروفا

هيكل مجلدي:

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

مشكلتي:

كنت أحاول نسخ محتوى ملفات التكوين إلى ملف configMap k8s ، لكنني وصلت إلى الحد حيث لم أتمكن من الرجوع إلى ملفات التكوين ، لأنها خارج مخطط الدفة.

بلدي الحل:

لقد استخدمت ملف التعيين لنسخ محتوى ملف التكوين

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

مشكلتي:

كنت أحاول نسخ محتوى ملفات التكوين إلى ملف configMap k8s ، لكنني وصلت إلى الحد حيث لم أتمكن من الرجوع إلى ملفات التكوين ، لأنها خارج مخطط الدفة.

بلدي الحل:

لقد استخدمت ملف التعيين لنسخ محتوى ملف التكوين

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 }}`

(تم تعديله عدة مرات لإصلاح فواصل الأسطر دون نجاح)

ما هي ملفات الموارد ليست نصية أو بتنسيق json ، في حالتي لدي ملفات موارد كملفات حرب مستخدمة لتكوين تطبيقي

أفعل ذلك حاليًا باستخدام ملف 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 }} 

وأنا فقط أضع ملفات التكوين في مجلد admin-configs (الرسم البياني أدناه) - قبل تشغيل الدفة ، ويضيف محتوى هذه الملفات إلى configmap - والتي يمكن بعد ذلك تحميلها داخل الكبسولات ، والأرض كملفات.

كنت أهدف إلى أخذ طعنة في هذا كأول مساهمة لي ، لأنه على السطح يبدو وكأنه طلب ميزة لائق ومفيد. لكن الآن ، أشعر أنه يمكن معالجة ذلك من خلال الوظائف الحالية.

لقد قرأت التعليقات ويتحدث الناس عن حالتين من حالات الاستخدام: الشهادات وتجاوزات المخططات.

1. الشهادات.
تذهب هذه في الأسرار أو ConfigMaps. أنا على يقين أنه يجب عليك تعيين هذه كسلاسل عند استدعاء helm ، على سبيل المثال من نص bash. بعد ذلك ، يمكنك كتابة نص يجلب الأسرار من التخزين ، على سبيل المثال HashiCorp's Vault ، ويتم ملؤه عبر القيم في وقت التشغيل.

للحصول على مثال لما يمكن القيام به ، ألق نظرة على مشروع Helmfile الرائع. لقد استخدمت هذا لجلب الأسرار من الخزنة إلى ملفات secret.yaml ، والتي يتم تمريرها بعد ذلك إلى الدفة عبر helmfile ، واحد لكل مخطط ، ويتم حذفه في النهاية.

لذلك ، هذا الحل مرن وقابل للبرمجة بدرجة كافية. في رأيي ، لا ينبغي على Helm محاولة إدارة الأسرار من خارج نطاقها المباشر ، وهو الرسم البياني ؛ وهذا يشمل الاضطرار إلى جلب الأسرار من أي مكان ، حتى من الملفات.

2. تجاوزات المخطط.
يجب أن تحل ميزة مخطط المكتبة الجديدة في Helm حالة الاستخدام هذه. يجب أن يكون مخطط المكتبة ، جنبًا إلى جنب مع مثال مخطط "التثبيت" ، كافيًا لبدء استخدام المخططات التي تتطلب تخصيصات تتجاوز ما يمكن القيام به باستخدام القيم البسيطة. أعتقد أن هذا سيكون حلاً أنيقًا لمشكلة OPs.

bacongobbler ، لقد قمت بتعيين هذه المشكلة على أنها Help Wanted ، لذلك أقوم بوضع علامة عليك. أي أفكار؟

مرحبًا vladfr - أوافق جزئيًا ، لكن ليس 100٪ :). أنا أتحدث عن حالة استخدام الشهادات الآن ، وهي تستند فقط إلى الخبرة الشخصية ، مما يعني أنها قد لا تكون قابلة للتطبيق على نطاق واسع. بالنسبة لمشروع داخلي ، أوافق. تريد تخزين شهاداتك في شيء مثل قبو. كتابة برنامج نصي يجلب البيانات من هناك ويضيف ببساطة القيمة المشفرة إلى base64 عبر المعلمات أمر جيد. لديك السيطرة ، لا مشكلة.

بالنسبة لبرنامجنا ، يعمل التوزيع عبر مخططات الدفة. يقوم الأشخاص بشراء منتجنا وتثبيته في أماكن العمل في مجموعة kubernetes الخاصة بهم. لا يعني ذلك أن الأشخاص الذين يقومون بتثبيت البرنامج عادةً ما يكون لديهم الكثير من الخبرة مع kubernetes ، ويستخدمون مجموعة متنوعة من أنظمة التشغيل (لقد رأوا جميع أنظمة Linux و mac و windows) عند استدعاء helm. نحن لا نقدم الشهادات بأنفسنا ، يشتريها العملاء في مكان آخر ؛ نحن نوفر مخططات خوذة ويضيفون الشهادات. ليس لدينا سيطرة على خطوط أنابيب CI / CD الخاصة بهم أيضًا. إنه بالفعل إشكالي من حيث التعقيد مع k8s والقيادة نفسها.

لقد تلقيت حالات استخدام للدعم حيث لم ينجح الأشخاص في تحويل شهادتهم إلى base64 بشكل صحيح - قد تكون مشكلات في تغذية السطر أو على حد سواء. لدينا مشاكل أقل في إخبار الأشخاص بفك ضغط المخطط ووضع الشهادة في موقع معين ثم تثبيت المخطط من الدليل. أعلم أن هذا بعيد جدًا عن المثالية ، ولكنه يعمل - إلى حد بعيد - أفضل من قول "تأكد من إضافة الشهادة بترميز base64 هنا". لكنها مرهقة.

لإضافة حالة استخدام أخرى لدينا ، بالإضافة إلى الشهادات: التراخيص (مثل ملفات مفتاح الترخيص) التي تقيد استخدام البرنامج. هذه الحالة أسهل من حيث أنه يمكننا توفير تراخيص بتنسيق base64 المشفر بالفعل للسماح بتعيينه عبر --set ، أو كصيغة values.yaml تكوينها مسبقًا والتي يمكنك تطبيقها للتو.

لذلك ، ما زلت أعتقد أن الميزة ستكون مفيدة للغاية.

lenalebt نشكرك على وصف حالة الاستخدام هذه بمثل هذه التفاصيل. أوافق ، في هذه الحالة الأمر مرهق. ما زلت أشعر بضرورة التعامل مع هذا الأمر من الخارج ، ولكن إذا شعر المشرفون بخلاف ذلك ، فسأكون سعيدًا بتجربة تنفيذ ذلك.

شكرا لك فلادفر.

أنا أوافقlenalebt على هذا. من الممكن التغلب على هذا ، ولكن إذا كنت تبيع منتجًا بالفعل بناءً على k8s / helm ، فإن التعقيد الإضافي للحل النهائي يمكن أن يعرض نقاطًا سلبية لحالة العرض الخاصة بك. إما أن تطلب من العميل التعامل مع بعض التفاصيل الفنية يدويًا ، أو إخفائها خلف البرامج النصية المغلفة أو واجهة المستخدم الرسومية التي ترقى إلى تكلفة الصيانة مع الوقت الإضافي.

أنا متأكد من أن هناك عدة طرق لتنفيذ ذلك ، ويمكن أن تساعد تعليقات المجتمع في تحديد الطريقة الأكثر أناقة.

أنا شخصياً سأقدم وظيفة جديدة على سطور .Files.GetExternal ، والتي يمكن توثيقها جيدًا كبديل غير آمن لـ .Files.Get .

يرجى النظر في تنفيذه. حتى kustomize يوفر علامة سطر أوامر للسماح بالوصول إلى الملفات الخارجية.

يبدو أن هناك إجماعًا كبيرًا على هذه الميزة. نحن نبحث عن متطوعين على استعداد لتخصيص الوقت لتنفيذ ذلك. ليس لدينا الوقت الكافي لكتابة هذا بأنفسنا ولكننا على استعداد لمساعدة الآخرين من خلال عملية التعلم. solacens هل ستكون على استعداد

bacongobbler أود أن أحاول طعنة في ذلك. لقد كنت أبحث عن مشكلة أولى جيدة لبدء المساهمة.

رائعة!

كنت أتحقق من ankul للتأكد من أن لا أحد يدوس على أصابع قدم الآخر. لقد أرسل إليّ على Slack في وقت سابق اليوم للتعبير عن اهتمامه بتطبيق الميزة أيضًا.

بالنسبة إلى العلم المقترح --include-file=foobar-license.conf :

• هل نتوقع من المستخدمين جمع كل الملفات في دليل واحد وتسميتها بشكل مناسب؟ إذا كان الأمر كذلك ، كيف يتم إبلاغ الأسماء المناسبة للمستخدم؟
  نقلاً عن https://github.com/helm/helm/issues/1754#issuecomment -271381902

  أرى القيم .yml (و - ضبط) كنوع من "الواجهة" التي يتم فيها تمرير المدخلات إلى الدفة.

  في هذا الأسلوب ، ستكون أسماء الملفات الآن إدخالًا عشوائيًا للمخطط.

• هل يجب أن يكون لدينا بناء 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}} . سيحتاج Helm إلى تحليل كل قيمة ومعرفة ما إذا كانت تناسب مخطط 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 ، يقوم الرسم البياني بتكرار جميع الملفات في هذا الدليل من أجل إنشاء configmap بإدخال لكل ملف.
يتمثل المطلب في السماح للمخطط بالبحث عن ملفات إضافية خارج جذر المخطط أو تاربل ، بحيث يمكن لمدير النظام في هذه الحالة إضافة ملفات *.yaml ليتم حقنها في configmap.
يمكن إنشاء هذا بسهولة باستخدام -I<directory> (مع خيار لمواقع متعددة) للبحث عن أدلة ظل إضافية ، دون تغيير منطق الرسم البياني.
شكرا!

هل من الممكن تحديد مسار لملفات التكوين في قيمي.yaml واستخدام هذا المسار لقراءة المحتويات لإنشاء خرائط تكوين متعددة؟
أريده أساسًا إنشاء yaml التالي
لنفترض أن لديّ مستودع git آخر حيث يتم تخزين ملفات التكوين الخاصة بي وأريد سحبها لأسفل في دليل خارج مخطط الدفة. أريد أن أكون قادرًا على الرجوع إلى هذا الدليل والاستيلاء على جميع الملفات الموجودة فيه. ربما يمكننا فقط عمل طبقة واحدة أولاً. لا حاجة للحصول على العودية حتى الآن.

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 ، كما ذكرت عدة مرات سابقًا في هذا الموضوع ، نحن نبحث عن متطوعين على استعداد لتخصيص الوقت لتنفيذ ذلك. بصفتنا مشرفين أساسيين ، يتم قضاء الغالبية العظمى من وقتنا في مساعدة الآخرين من خلال عملية المساهمة في الإصلاحات والميزات في Helm. نحن ببساطة لا نملك الوقت لكتابة ميزات جديدة بأنفسنا ، لكننا أكثر من راغبين في مساعدة الآخرين من خلال عملية التعلم.

حتى الآن ، لم أر أي طلبات سحب تنفذ هذه الميزة على النحو المقترح . ما زلنا نبحث عن متطوع.

أرى أنك متحمس جدًا لهذه الميزة. ما هو شعورك حيال العمل على تنفيذ هذا؟

حتى الآن يمكنك إضافة أي ملفات خارجية إلى التثبيت منذ أن تم تقديم Post-Render Hooks

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

أرى أنك متحمس جدًا لهذه الميزة. ما هو شعورك حيال العمل على تنفيذ هذا؟

بالتأكيد ، إذا لم يكن مكتوبًا في Go. يبدو الأمر كما لو أن كل مستخدم آخر لـ Github يعرف كيف يذهب ، لذلك لا ينبغي أن يكون هناك مشكلة في العثور على شخص مهتم. في الواقع ، لدي بالفعل بضعة أشخاص هنا على Github في ذهني يمكنني أن أسألهم ، لأنهم يشاركون في العمل المتعلق بـ Kubernetes وجميعهم يقومون بالكثير. يشبه العثور على مبرمج Go البحث عن حبة رمل على الشاطئ.

فيما يلي مثال على كيفية استخدام التخصيص عبر خطافات Post-Render
https://github.com/helm/helm/issues/7260

فيما يلي مثال على كيفية إنشاء التكوين من ملف خارجي:
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/#configmapgenerator

أعتقد أنه يمكن إغلاق هذه القضية.

هذا مثال أبسط:

sh.sh

#!/bin/bash

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

file.txt

some content

التمتع:
helm install --post-renderer ./sh.sh stable/some_helm_chart

تحتاج فقط إلى إنشاء خريطة تكوين بمحتوى مزيف TOKEN_TO_REPLACE

_ ولكن يمكن أن يكون هناك مشكلة في المسافة البادئة للسطر في yaml_

@ R-omk كما قيل في الوثيقة:
"_ لا يتم حاليًا تعقب الموارد التي ينشئها الخطاف أو إدارتها كجزء من الإصدار ._"

IMHO ، الحل هو الذي تم اقتراحه مسبقًا ، أي أن يكون لديك علامة لإضافة أدلة إلى مسار البحث الخاص بوظيفة ".Files".
لا توجد مشكلة أمنية في IMHO حيث يحدد مستخدم المخطط بدقة المكان الذي يمكن أن يلعب فيه المخطط بالملفات ، وهذا ليس المخطط الذي يمكنه إدارة الملفات في أماكن عشوائية

ماذا عن العلامة الجديدة " --search-folder " التي يمكن تعيينها عدة مرات؟ أما بالنسبة لقضايا تصفية الملفات ، فيمكنه تنفيذ نفس القواعد تمامًا كما تم تنفيذها حاليًا بواسطة .File.Glob وما إلى ذلك ، لذلك لا يوجد تعقيد أو وصف جديد هنا

@ titou10titou10

"لا يتم حاليًا تعقب الموارد التي ينشئها الخطاف أو إدارتها كجزء من الإصدار."

حول الخطافات: pre/post - install/delete/upgrade/rollback

post-renderer نوع مختلف تمامًا من الخطاف

@ R- omk ، عادل بما فيه الكفاية. المستند متأخر في هذا الشأن
لكن ما زلت لا أستطيع أن أرى كيف يمكنني حل مشاكلنا مع hoosk post-renderer.
إحدى حالات الاستخدام الخاصة بنا:

• نستخدم خط أنابيب jenkins لإنشاء تطبيق جافا ونشره في OpenShift
• كنا نستخدم "قوالب" OpenShift لهذا ونحاول الانتقال إلى Helm لأنه أكثر مرونة ، وقمنا بإنشاء مخطط مخصص للنشر
• تتضمن عملية النشر إنشاء ConfigMap واحد بملفات خصائص كلاسيكية متنوعة تم إنشاؤها ديناميكيًا بواسطة البنية ، وكلها في نفس الدليل (يمكن للبناء وضعها في أي مكان ..)
• هذا مرشح مثالي لوظيفة " Files.Glob(<ext dir>) / AsConfig() " ، لسوء الحظ ، نظرًا لأن ملفات الخصائص يتم إنشاؤها خارج المخطط ، فهذا غير ممكن حاليًا
• ملاحظات: أسماء ملفات الخصائص ديناميكية ، وعدد الملفات ديناميكي أيضًا ، والبناء يجمعهم في دليل واحد

ربما يمكن أن يساعدنا استخدام أداة ربط ما بعد العرض ولكني لا أرى كيف ، وسيكون IMHO مجرد حل بديل ولكن جميع "الحلول البديلة" مرحب بها في هذه المرحلة
ويبدو أن إضافة علامة " --search-folder " أو إضافة وظائف .Files.GlobExternal() / .Files.GetExternal() كما يقترح شخص ما حل صالح ولكن الأول هو IMHO الأكثر أمانًا لأن هذا هو المخطط الذي يسمح بالوصول إلى المحلي المجلدات

تذكير سريع: لن نقبل العلاقات العامة التي تقدم .Files.GetExternal أو علامة مجلد البحث. يمكن أن يؤدي ذلك إلى إدخال مشكلات أمنية من جانب المثبت. يمكن للمرء أن يكتب مخططًا ضارًا ينسخ ملفًا حساسًا ويشحنه في مكان آخر مع ربط الرسم البياني.

ومع ذلك ، سيتم قبول - تضمين - ملف أو - تضمين - دير ، كما هو مذكور في تعليق سابق: https://github.com/helm/helm/issues/3276#issuecomment -412942372

هناك حالات تريد فيها تضمين الملفات كجزء من مرحلة العرض لتلك القوالب. قد لا يعالج ما بعد التصيير جميع الحالات.

bacongobbler جيدة بما فيه الكفاية.
دعونا نأمل أن تسمح العلامة الجديدة --include-dir باستخدام .Files.Glob(<dir>).AsConfig() أو ميزة مكافئة لملء حالة الاستخدام هذه ، والتي أعتقد أنها شائعة جدًا في خط الأنابيب

أو ربما هيلم ليست الأداة الصحيحة في سيناريو خط أنابيب CICD حيث لا يمكن التعبير عن العديد من "البيانات" بطريقة "قيمة" خالصة (عبر -f ، --set أو --set-file ) وتقام خارج الرسم البياني

في الوقت الحالي ، الحل الوحيد الذي أراه هو إحضار المخطط وإلغاء تحديده في مكان ما ، ونسخ الملفات الخارجية أسفل شجرة الرسم البياني ، وقيادة التشغيل من تلك النسخة المحلية

أنا لا أفهم لماذا الملفات الخام داخل الإصدار؟

لم يعد helm v3 يشغل عرض قالب جانب الخادم. لذلك ، لا يمكنك استخدام Files.Glob.
هذه المشكلة فعلية فقط لـ helm 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() ، ولذا أنشئ ConfigMap بإدخال واحد في CM لكل ملف في <dirpath> ؟

نعم هذه هي الفكرة. السؤال المفتوح من وجهة نظري هو ما إذا كان --include-dir مع <prefix> المحدد يقدم تراكبًا ، أو يقوم بتظليل كل شيء تحت <prefix>/ من المجموعات السابقة ومن الحزمة نفسها. أنا لست شديد الرأي بشأن ذلك ولكني أفضل الأول.

pingmisberner. أي تقدم؟

مهلا! لقد وجدت للتو حالة أخرى حيث ستكون هذه الميزة مفيدة.
bacongobbler أرى أن هذا لا يزال مفتوحًا - هل هذه المشكلة غير محددة؟ قد يكون لدي بعض الوقت في الأسبوع المقبل لإلقاء نظرة.

خذ راحتك

قضيت بعض الوقت ، لديّ علامة الملف تعمل ، وأخطط لإضافة علامة التنوب أيضًا.

لقد عملت حول هذا من خلال نشر الرسم البياني الحاضنة / الخام مثل الرسم البياني الثاني

العلاقات العامة مفتوحة الآن للمراجعة.

vladfr يبدو أن العلاقات العامة مشقوقة لإصدار 3.4.0.

تحدثنا عن ذلك الأسبوع الماضي في مكالمة ديف. vladfr كان حاضرًا وأثار السؤال عما إذا كان بإمكاننا الحصول على هذا في 3.3.0.

مع عبء العمل الحالي الخاص بنا 3.3.0 ، ليس لدينا الوقت الكافي للاستثمار في مراجعة هذه العلاقات العامة. في الوقت الحالي ، نتواصل مع أعضاء المجتمع الذين كتبوا علاقات عامة لـ 3.3.0 ونطلب منهم إصلاح العلاقات العامة الخاصة بهم قبل إغلاق نافذة الدمج ونقطع الإصدار. E_TOO_MANY_PRS_TO_REVIEW

بمجرد خروج 3.3.0 من الباب ، يمكننا إعادة النظر في هذه المحادثة.

التالية

يتبع أيضا

كان العمل حول:
{{- range $ datakey، $ dataval: = $ cm.fileList}}
{{- $ datakey | nindent 2}}: | -
{{- $ fullPath: = printf "configFiles /٪ s" $ dataval}}
{{- $ .Files.Get $ fullPath | نيندنت 4}}
{{- نهاية }}

أي تحديثات في هذا الصدد ، نظرًا لأننا ننشر 3.3.1

يبدو استخدام --include-dir طريقة جيدة. نتطلع إلى v3.4.0

أهلا. كيف تأتي هذه الميزة؟ أرى أن هناك علاقات عامة مغلقة ومفتوحة ، آخر مرجع منذ حوالي شهر؟

ستكون هذه الوظيفة مفيدة جدًا - هل يمكننا الحصول عليها قريبًا؟

فقط لإضافة +1 إلى هذا من فضلك. لقد أمضيت للتو 4 ساعات في محاولة اكتشاف كيف كان تركيب الجمل الخاص بي خاطئًا ؛ بينما في الحقيقة كان يتجاهل بصمت حقيقة أنني كنت أعبر في مسار مطلق خارج مجلد نشر الرسم البياني. لم ينجح الأمر حتى وجدت هذه المشكلة!

في أنظمة Unix ، يمكن الوصول إلى الملفات الموجودة في الدلائل خارج شجرة دليل مخطط الدفة باستخدام روابط رمزية (على الأقل باستخدام Helm 3.3.4)

فقط لإضافة +1 إلى هذا من فضلك. لقد أمضيت للتو 4 ساعات في محاولة اكتشاف كيف كان تركيب الجمل الخاص بي خاطئًا ؛ بينما في الحقيقة كان يتجاهل بصمت حقيقة أنني كنت أعبر في مسار مطلق خارج مجلد نشر الرسم البياني. لم ينجح الأمر حتى وجدت هذه المشكلة!

catdevnull - مرت بنفس الموقف. +1 لهذه القضية.