Helm: الاقتراح: السماح بالقيم في قالب. yaml

هل تقترح استيفاء القيم الحرفية من ملف _values.yaml_ الافتراضي هذا في قوالب الرسم البياني ، ثم أقحم هذه القوالب بالكامل مرة أخرى لتوسيع اسم الإصدار (لاستخدام مثالك) ، أو هل تتخيل استيفاء ملف _values.yaml_ أولاً ، ومن ثم التعامل مع شكله الموسع كمدخل لاستيفاء باقي قوالب الرسم البياني؟

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

لذلك ، على سبيل المثال ، ستكون قادرًا على عمل myval: ${RELEASE_NAME}.foo.bar في قيمك. yaml.

على جانب Golang ، يجب أن يكون الأمر بسيطًا مثل استدعاء os.Exand() بقائمة مخصصة من المتغيرات التي يجب توسيعها.

لنقطةseh ، من الصعب تحديد متى تريد تشغيل التوسيع. أعتقد أنك تريد القيام بذلك بعد دمج القيم ، ولكن قبل إرسال القيم إلى محرك القالب. من شأن ذلك أن يجلب معه التحذير بأن المتغيرات يجب أن يتم تمثيلها على أنها YAML جيدة التكوين. لكن أعتقد أن هذا عملي

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

technosophos بالنظر إلى ذلك ، أعتقد أن ما تقترحه يبدو وكأنه حل جيد.

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

أنا لا أجادل ضد الفكرة حتى الآن ؛ نحتاج فقط إلى الشك في أن الاستبدالات البسيطة التي أشار إليها technosophos أعلاه ستكون كافية.

ولكن إذا تم إدخاله من خلال ملف قيم .yaml ، فلا يزال من الممكن إجراء التحويل والتحقق من الصحة في القوالب ، أليس كذلك؟ على سبيل المثال: لا يزال من الممكن الوصول إلى myPort: ${port} في القالب مثل هذا: {{ .myPort | int }} .

القيد الأكبر هو أن الملف values.yaml يجب أن يكون دائمًا ملف YAML صالحًا.

إنه هذا القيد الذي كان يدور في ذهني: ماذا يحدث إذا احتفظ متغير "المنفذ" بالقيمة

"أ

أو تسلسل آخر يجعل YAML غير صالح؟ كما قلت ، هناك قيود نحوية يجب وضعها في الاعتبار ، على الرغم من أنه يمكن للمرء حلها:

myport: '${port}'

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

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

بناءً على الحالات التي أردت فيها ذلك حتى الآن ، أظن أن القوالب الكاملة مطلوبة ، وليس مجرد الاستيفاء البسيط.

فكرة استيفاء القيم الحرفية من القيم. yaml في القوالب ، ثم إقحام القوالب مرة أخرى في حال كانت القيم الحرفية عبارة عن قوالب هي بالفعل مثيرة للاهتمام ، ولكن يبدو أنها ستعتمد على كيفية كتابة القوالب. على سبيل المثال ، هذا لن يعمل كما هو متوقع:

القيم.

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

النشر

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

هل هناك مشاكل في استيفاء القيم. yaml أولاً (من الواضح بدون الوصول إلى .Values ) ثم استخدام القيم الناتجة.yaml لاستكمال النماذج الأخرى؟

braedon نعم ، هناك عدة مشاكل:

1. يجب أن يكون ملف القيم. yaml صالحًا في YAML في حالته التي لم يتم تحليلها. هذا يضع قيودًا مثيرة للاهتمام على توجيهات القالب.
2. يتم دمج القيم على مراحل ، وبعض المراحل لا تملك حق الوصول إلى النظام الفرعي للقالب (على وجه التحديد - ضبط الدقة ، وقيود المتطلبات ، وعمليات الدمج -f.)
3. يجب حساب جميع القيم قبل أن تتم تهيئة أجزاء معينة من نظام القوالب. بخلاف ذلك ، لا يعمل {{ define }} و {{ include }} بشكل متوقع ، ولا يعمل {{ template }} أيضًا.

بشكل أساسي ، تعد بنية env var سهلة بما يكفي لتضمينها في values.yaml بحيث يمكننا القيام بذلك دون تقديم الكثير من التعقيد. لكن استخدام القوالب الكاملة يعد مهمة كبيرة ، وحتى إذا نجحت ، فسيؤدي ذلك إلى سلسلة لا نهاية لها من تقارير الأخطاء التي يتم تقديمها عند وصول الأشخاص إلى الحالات المتطورة.

لكن لابد أني أفتقد شيئًا ... أنا لا أفهم مثالك أعلاه. ما يتم اقتراحه هو:

القيم

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

النشر

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

سيتم تقديم values.yaml لترتيب العمليات بعد إنشاء كائن الإصدار ، ولكن قبل تجميع القوالب أو عرضها. إذا كان اسم الإصدار هو FOO ، فإن نتيجة ما سبق ستكون otherService: foo-my-service .

technosophos كنت أتخيل تشغيل محرك القوالب على ملفات القيم. yaml قبل أي تحليل / دمج / إلخ. تم الانتهاء من الملفات (إذا لم تنجح هذه الميزة ، فقد فكرت في تشغيل نظام قوالب منفصل لتوليد القيم. ملفات yaml لتمريرها بعد ذلك إلى Helm).

يبدو أن هذا يجب أن يتجنب المشكلات 1 و 2 ، وأن يكون نظامًا بديهيًا جدًا للتعبير عن نفسه؟ ليس لدي أي فكرة عن مدى صعوبة تنفيذ ذلك في قاعدة بيانات Helm ، ومع ذلك ، ستظل 3 مشكلة (لست متأكدًا من مدى تقييد عدم السماح بهذه الوظائف؟).

كانت أمثلتي تشير إلى الحل الذي يناقشseh و benjigoldberg ، وليس اقتراحك.
في اقتراحهم (بافتراض أنني فهمته بشكل صحيح) سينتج عن مثالي هذا بعد المرور الأول:

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

(على سبيل المثال ، سيتم تمرير القيمة الأولية لـ otherServiceName من القيم. سيتم تمرير yaml إلى publish.yaml ، وبأحرف صغيرة)
الذي لن يعمل بعد ذلك بالشكل المنشود في التمريرة الثانية.

ما كنت أفكر فيه هو:

إذا كان الملف /templates/values.yaml موجودًا ، فالمنطق هو قراءة المتغيرات من /values.yaml لعرض القالب ، ثم يتولى values.yaml الذي تم عرضه بالكامل ، قبل عرض جميع القوالب الأخرى . بمعنى آخر ، يعمل /values.yaml على تمهيد القالب.

لقد واجهت أيضًا حالة استخدام أعتقد أنها ستستفيد من ذلك. أظن أنه قد يكون مشابهًا لمثالbraedon otherService .

المشكلة التي أواجهها هي أنه لا يمكن حاليًا تضمين .Release.Name عند تجاوز اسم الخدمة عبر values.yaml . حالة الاستخدام لذلك هي عند إنشاء مخططات منفصلة تمامًا يمكن ربطها معًا باستخدام مخطط أصلي.

على سبيل المثال ، يمكن أن يحتوي مخطط elasticsearch على قيمة serviceNameOverride في ملفه values.yaml والذي من شأنه أن يسمح للمستخدم بتجاوز اسم الخدمة. وبالمثل ، يمكن أن يحتوي مخطط kibana على قيمة elasticsearch.host في ملف values.yaml الخاص به والذي يمكن للمستخدم استخدامه لتعيين موقع مجموعة elasticsearch. لا تعرف هذه المخططات شيئًا عن تفاصيل التنفيذ الخاصة ببعضها البعض. إنها مستقلة وستسمح للمستخدم ، على سبيل المثال ، بنشر kibana لمراقبة مجموعة elasticsearch موجودة لم يتم نشرها باستخدام الدفة.

من الناحية المثالية ، يمكن أيضًا استخدام هذه المخططات المستقلة كوحدات بناء لإنشاء مخطط أساسي "elasticsearch-kibana" يقوم بربطها معًا عبر مخططات فرعية. سيقوم المخطط الأصلي بتوصيل الخدمات معًا عن طريق تعيين ما يلي على values.yaml :

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

من الممكن حاليًا القيام بذلك بدون تضمين {{ .Release.Name }} في القيم ، ولكنه غير ملائم لأنه سيمنع المستخدم من تثبيت مخططات "رئيسية" متعددة في نفس مساحة الاسم دون تغيير ملف القيم لكل تثبيت.

alexbrand يمكنك استخدام الدالة tpl لعرض القيم التي تحتوي على متغيرات:

القيم

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

template.yaml:

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

eicnix للقيام بذلك يتطلب التحكم في template.yaml في المخطط الفرعي ، والرغبة في إضافة دعم صريح لهذا أينما كان مطلوبًا.

ما أسعى إليه هو طريقة لكتابة مخططات الوالدين التي تقوم بهذا النوع من الأشياء أثناء التعامل مع المخططات الفرعية على أنها مربعات سوداء. أعتقد أن هذا ما قاله alexbrand أيضًا؟

شخص ما أعلاه قد أشار بالفعل إلى الوظيفة tpl التي تمت إضافتها مؤخرًا إلى حد ما (# 1978). قد أكون قد أسيء فهم بعض التعقيدات المتضمنة هنا ، ولكن بالنسبة لحالة الاستخدام الخاصة بي وبعض الحالات الأخرى الموضحة أعلاه ، كل ما يبدو مطلوبًا هو تمرير ضمني للقيم التي يتم تقييمها عبر tpl أو ما يعادله ، قبل تقديم القوالب . (أعتقد أنك قد تحتاج إلى الاستمرار في إجراء التمريرات حتى لا يتم إجراء أي تغييرات ، للتعامل مع المراجع المتكررة.) أفترض أنك قد ترغب في طلب تمكين هذا عبر ، على سبيل المثال ، وسيطة --expand-values في الأمر الخط ، ولكن هل هناك مشكلة أخرى مع مثل هذا الحل؟

eicnix شكرا على الاقتراح!

لم أتمكن من الحصول على خط الأنابيب في النموذج. yaml يعمل ولكن العامل أدناه بالنسبة لي (مع القيم. yaml أعلاه):

template.yaml

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

أعتقد أن هذه و # 2133 هي نفس المشكلة ، راجع للشغل. (لست متأكدًا من الأفضل الاحتفاظ به مفتوحًا.)

يبدو أننا بخير في 2.6.1 من خادم Helm (لكن ليس في 2.3.0)

obriensystems هل يمكنك توضيح هذا الفكر أكثر قليلاً؟ :)

ما الذي يبدو أنه جيد بخصوص هذا الاقتراح لـ v2.6 ولكن ليس في v2.3؟ ربما كنت تشير إلى تذكرة أخرى؟

يعجبني النهج الذي اقترحه travishaagen و braedon . يمكنني أيضًا تخيل استخدام قيم متعددة

تثبيت helm -f raw_values.yaml -tf value_rendered_with_templating.yaml ...

أولاً ، ستقرأ raw_values.yaml والتي يجب أن تكون yaml صالحة. ثم يقوم helm بقراءة values_rendered_with_templating.yaml وتشغيل هذا من خلال محرك القوالب الذي يمكنه الوصول إلى المتغيرات الموجودة في raw_values.yaml . يتم بعد ذلك تغذية النموذج الذي تم تقديمه إلى المرحلة التالية وما إلى ذلك.

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

هذه المشكلة إلى جانب # 2399 هي حواجز كبيرة جدًا تؤثر حقًا في تكوين المخططات الرئيسية من المخططات الفرعية. نظرًا لأن الأمور في الوقت الحالي ، لا تسمح الدفة بتكوين المخططات لأي شيء غير تافه. أتساءل عما إذا كان هناك حل أفضل لإنشاء المخططات التي من شأنها حل المشكلة المطروحة بالإضافة إلى # 2399.

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها جديدة /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة الحياة التي لا معنى لها

/ إزالة دورة الحياة التي لا معنى لها

أعتقد أننا لا نعقد بالضرورة الدفة للقيام بذلك. على سبيل المثال ، يمكن استخدام أداة بسيطة مثل https://github.com/roboll/helmfile للقوالب في القيم.

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

NicolasT شكرا لمشاركة حالة الاستخدام الخاصة بك 👍

ربما تعرف بالفعل ولكن بالنسبة لأي شخص لم يصل إلى هناك بعد - يمكنك تسمية إصدار Zookeeper الخاص بك باسمًا ملموسًا بـ helm install incubator/zookeeper --name myzookeeper ثم إعادة استخدام هذا الاسم كقيمة لإصدار كافكا.

ويبدو أن حالة الاستخدام الخاصة بك لا تدعمها الحلول المقترحة في هذا الموضوع. اسف إذا لم أتبعك ، لكن لا يمكنك الوصول إلى اسم إصدار آخر من إصدار مستقل آخر ، أليس كذلك؟

يبدو أن عملك يتعلق أكثر بـ "توسيع ما يمكن الرجوع إليه من القوالب" بدلاً من "السماح بالقوالب في القيم".

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

لا أستطيع أن أوافق أكثر
إن أداة الكل في واحد لدعم حالات الاستخدام للجميع ستكون بمثابة هبة من السماء.

في الواقع ، تمنيت ذات مرة إذا كان بإمكان الدفة الاندماج مع مدير سير عمل تصريحي مع ميزة دقة تبعية الخدمة الديناميكية (حالة الاستخدام الخاصة بك) مثل atlassian / smith .

تخيل حلاً متكاملاً من Helm CRD + Smith - هل نأمل أن يحل مشكلتك بأناقة؟

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

لذلك ، أتمنى أن يظل helm core بسيطًا وأن يتم توسيع نظام البرنامج المساعد helm بطريقة ما لدعم نقطة امتداد مثل "محول القيم" القادر على تعديل القيم. yaml قبل تمريرها من واحد إلى آخر. حسنًا ، هذا يبدو وكأنه سميث تقريبًا!

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

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

القيم. yml:
ui_secret:# باستخدام "{{tpl randAlpha 8}}" هنا يبلغ عن خطأ.

template1.yml:
UI_SECRET: {{.Values.ui_secret}}

template2.yml:
UI_SECRET: {{.Values.ui_secret}}

أعلم أنه يمكن إنشاء param ui_secret خارج الدفة ويمررها عبر - اضبط 'ui_secret = xxx'. ولكن لماذا لا ندع الدفة تولد قيمة عشوائية افتراضية؟
يمكن استخدام القيمة العشوائية الافتراضية لـ salt / password / ca_certificate / Certificate_pair ، إلخ.

ولكن لماذا لا ندع الدفة تولد قيمة عشوائية افتراضية؟

مرحبا! كيف تريد تحقيق ذلك؟

بالنسبة لي ، لا يبدو أن استخدام القوالب في values.yaml يحل المشكلة. ماذا لو كان لديك قيم خيالية مثل:

ui_secret: "{{ randAlpha 8 }}"

وقمت بتشغيل helm upgrade --install yourrelease yourchart -f values.yaml عدة مرات؟
بالنسبة لي ، يبدو أنه لا توجد طريقة للقيادة / الحارث عند القيام / عدم إنشاء ui_secret.

لذلك ، أعتقد أنه يجب عليك فقط تقديم سر مُنشأ مسبقًا عبر --set كما لاحظت ، بغض النظر عن قبول هذا الاقتراح أم لا.

بدلاً من ذلك ، هل سيكون من الممكن بالنسبة لك فقط إنشاء قيمة عشوائية داخل سر k8s؟
بحيث يمكن لجميع الكبسولات التي تم إنشاؤها عبر مخطط الدفة الخاص بك أن تشير إلى السر باسمه.

mumoshu لسيناريو الترقية:
1) إذا تم تعيين ui_secret في قيم.yaml ، فلا يوجد تأثير ؛
2) يجب أن يقوم helm باسترداد القيم الموجودة .yaml من مكان ما (ربما تيلر) ، ثم يدمج هذه القيم الموجودة. yaml مع "قيم -f.yaml"

يجب أن تكون الدفة مستقلة لتوليد عشوائي / كلمة مرور / ca_certificate / Certificate_pair ، ولا تتطلب من المستخدم النهائي إنشاء قيادة خارجية. هذا يوفر قابلية استخدام أفضل بكثير.

يمكن تنفيذ "إنشاء قيمة عشوائية داخل سر k8s" ، ولكن ليس بشكل مباشر مقارنة بـ 'ui_secret: {{randAlpha 8}}'

يجب أن يقوم "else helm" باسترداد القيم الموجودة. yaml من مكان ما (ربما تيلر) ، ثم يدمج هذه القيم الموجودة. yaml مع "قيم -f.yaml"

ليس مسيئًا حقًا ولكن يبدو أنه يقدم المزيد من الحالات المتطورة.
كيف يميز helm / الحارث القيمة التي تم تعيينها بالفعل أم لا ، ومتى يتم تجاوزها إذا كانت من --set أو -f values.yaml أم لا ، بالنظر إلى القيم الخاصة بك. يحتوي yaml دائمًا على ui_secret: {{ randAlpha 8 }} ؟

يمكن تنفيذ "إنشاء قيمة عشوائية داخل سر k8s" ، ولكن ليس بشكل مباشر مقارنة بـ 'ui_secret: {{randAlpha 8}}'

يوافق. لكن على أي حال ، لا يبدو أن القوالب هي الحل بالنسبة لي.

ستحتاج إلى محرك سير عمل مثل https://github.com/atlassian/smith للتعامل مع تبعيات الخدمة (مع القدرة على تمرير القيم التي سيتم استهلاكها بواسطة consequtive ، والتي تعتمد على helm install s).

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

عند تثبيت المخطط ، '--set'> '-f values.yaml'> القيم. yaml في المخطط
عند ترقية الرسم البياني ، "- اضبط"> "قيم -f.yaml"> القيم المُنشأة. yaml للمخطط المثبت

تم تنفيذ ما اقترحته في BOSH https://bosh.io/docs/variable-types.html. يدعم BOSH تعريف نوع المتغير الصريح ، بينما يدعم القيم yaml في مخطط الدفة yaml العادي. لذلك سيكون من الرائع دعم وظيفة النموذج في القيم. yaml، على سبيل المثال 'ui_secret: {{randAlpha 8}}'.

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

توصيتي بالتعامل مع أي نوع من الأسرار جنبًا إلى جنب مع helm هي إدارتها في مخزن سري (أسرار kube ، و vault ، وما إلى ذلك) والرجوع إليها فقط من المخطط.

تم تنفيذ ما اقترحته في BOSH https://bosh.io/docs/variable-types.html. يدعم BOSH تعريف نوع المتغير الصريح ، بينما يدعم القيم yaml في مخطط الدفة yaml العادي

لقد راجعت توثيق Bosh حول الاستيفاء المتغير. اتضح لي أن Bosh لا يدعم كلاً من (1) تعبئة المتغيرات من مخرجات تطبيقاتك (كائنات k8 التي تم إنشاؤها بواسطة helm / الحارث في حالتنا) ، و (2) إنشاء قيمة ثابتة عبر القالب. شاهد فكرة -v internal_ip=192.168.56.6 في https://bosh.io/docs/cli-int.html.

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

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

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

AFAICS ، ما هو ليس دفة / حراثة يدركها حاليًا. إن القيام بذلك في نطاق الدفة / الحارث سيؤدي إلى تضخيمها إلى حد كبير ، كما أشار eicnix .

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

لذا فإن أفضل رهان لك هو التحقيق في محرك سير عمل آخر مثل atlassian / smith (لم أتقاضى راتبي من قبل مؤلفي الحداد. من فضلك أخبرني إذا كان هناك أي بديل 😉) + ربما يكون هناك رأس قادم CRD.

mumoshu أعتقد أن حالة الاستخدام الخاصة بي موصوفة بشكل مناسب بالرقم # 2506. لا أرى كيف يساعد إرسال مشكلة أخرى.

لا أرى كيف أن قولبة values.yaml لا تتعامل مع حالة الاستخدام الخاصة بي. يدعم Helm المخططات الفرعية ، والتي يتم تنسيقها إما بواسطة requirements.yaml أو تضمين المخطط الفرعي في الدليل charts . يمكن أن يمرر الرسم البياني الأصل القيمة بشيء مثل:

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

بالطبع ، قوالب القيم. yaml ليست الطريقة الوحيدة لتنفيذ السماح للمخطط بتمرير قيم غير معروفة في وقت الحزمة إلى مخطط فرعي. ولكن إذا كان "هيلم" "منتفخًا" ، فإن إضافة أي ميزة إلى حد كبير ستكون "نفخة" هيلم.

ربما يمكننا إضافة عرض قيمة محدودة قبل عملية القوالب. سأسمح فقط بالوصول إلى .Chart و .Release لتجنب المشكلات المعقدة مثل المراجع الدورية بين القيم على سبيل المثال. ولكن هذا سيظل يحل الكثير من حالات الاستخدام حيث يرغب الأشخاص في الإشارة إلى الإصدار أو مثيل الرسم البياني من القيم.

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

على سبيل المثال ، سيكون لدينا مخطط فرعي "النظام الأساسي" الذي يلخص الأشياء الشائعة التي تحتاجها الخدمات المنفذة في مكتبة النظام الأساسي الداخلية الخاصة بنا. قد ترغب في الحصول على قيمة "platform.oauthClient" والتي سيمررها مخطط الخدمة للإشارة إلى ما إذا كانت الخدمة بحاجة إلى التكوين لتكون عميل OAuth أم لا. قد يكون تنفيذ ذلك هو تمرير هذا .Values.oauthClient إلى مخطط فرعي من المخطط الفرعي "النظام الأساسي". في المستقبل ، قد نرغب في تغيير هذا التنفيذ لتلك الميزة في مخطط "النظام الأساسي" إلى شيء آخر.

قد ترغب القيم النموذجية في العيش في مكان آخر غير المستوى الأعلى values.yaml (ربما templates/_values.yaml ) حتى لا تظهر كجزء من واجهة برمجة التطبيقات الخارجية للمخطط الأصلي. يمكن أن يعالج ذلك أيضًا مشكلة المراجع الدورية.

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

لمعلوماتك ، العلاقات العامة الخاصة بي المرتبطة بالفعل (على سبيل المثال ، # 3252) تنفذ هذه الميزة وأعتقد أنه من المحتمل أن يلبي حالات الاستخدام المختلفة هذه. لقد استخدمناها داخليًا لفترة من الوقت ، ويمثل تمرير القيم الأبوية إلى المخططات الفرعية إحدى المشكلات التي نحلها بها.

العلاقات العامة لم تحقق تقدمًا كبيرًا حتى الآن. من الواضح أن أي تعليقات ، سواء على العلاقات العامة نفسها أو من تجربة الميزة في بناء ، مرحب بها للغاية.

تنص وثائق eicnix The Helm على ما يلي:

لكن المخططات ذات المستوى الأدنى لا يمكنها الوصول إلى الأشياء الموجودة في المخططات الرئيسية ، لذلك لن تتمكن MySQL من الوصول إلى خاصية العنوان. ولا ، في هذا الصدد ، لا يمكنه الوصول إلى apache.port.

بحيث لا يبدو ذلك ممكنا.

johngmyers لا يمكن للمخططات الفرعية الوصول إلى القيم الأصلية ولكن يمكن للمخطط الأصلي تمرير القيم إلى المخطط الفرعي. بافتراض أن لديك مخططًا فرعيًا يسمى mychild ، يمكنك تمرير قيمه من القيم الأصلية. yaml بهذه الطريقة:

mychild:
  overridenValue: true

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

هل فريق هيلم على علم بهذه المشكلة / الاقتراح؟ تم إنشاؤه في 25 مايو 2017 ، منذ 10 أشهر. كان هناك الكثير من النقاش هنا ، وتم إنشاء العديد من المشكلات المكررة / المماثلة.
لم يتم تعيين هذه المشكلة لأي شخص حتى الآن.

نشهد تعليقات "سوف تنتفخ دفة القيادة". إذن أي حل لا ينتفخ؟ هل يمكن لفريق Helm تقديم خطة ووقت متوقع للوصول لهذا الاقتراح وتقديم حل بديل / حل معقول على الأقل؟

يبدو أن العلاقات العامة https://github.com/kubernetes/helm/pull/3252 يمكنها دعم القوالب في القيم. إذا كان فريق هيلم يعتقد ذلك ، يرجى الإسراع في دمجه.
شكرا.

يبدو أن حل mparry في https://github.com/kubernetes/helm/pull/3252 يتعامل مع حالة الاستخدام الخاصة بي بأناقة. سيكون من المدهش أن يتم دمجها!

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

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها جديدة /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة الحياة التي لا معنى لها

/ إزالة دورة الحياة التي لا معنى لها

johngmyers هل وجدت حلاً جيدًا لـ https://github.com/helm/helm/issues/2492#issuecomment -370895073؟ أنا أواجه نفس مشكلة التغليف. أرغب حقًا في تجنب كتابة غلاف لـ helm لتقديم القيم القوالب الخاصة بي مسبقًا بشكل متكرر في ملفات القيم. yaml.

ليس لدي حل جيد. لدي حل بديل يستخدم إصدارًا خاصًا من Helm مع تطبيق # 3471 ، مما يسمح لي (بشكل متكرر) بتمرير اسم المخطط الأصلي وإصداره إلى المخططات الفرعية في وقت الحزمة.

هذا بالإضافة إلى دعم الدمج الضعيف يمنعني بشكل أساسي من القيام بأي تغليف معقول. آمل أن يساعد استخدام Helm 3 لـ LUA في هذه المشكلة.

لأسباب فنية وتصميمية مختلفة وراء كيفية عمل محرك عرض نماذج تيلر ، لا نعتزم دعم قيم المعالجة المسبقة. yaml كقالب Go لأي من Helm 2 أو Helm 3. ومع ذلك ، فإننا نشجع المجتمع بشدة على كتابة أغلفة أو Helm الإضافات التي تدعم هذه الميزة لحالة استخدامها! أحد الأمثلة التي سمعناها من المستخدمين مكتمل ، لكننا نرغب في رؤية معالجات مسبقة أخرى يمكنها توفير هذه الوظيفة قبل تشغيل helm install .

لإعادة تكرار تعليق سابق في هذا الموضوع: إضافة دعم لتوسيع متغيرات البيئة في القيم. سيكون yaml مشكلة سهلة المعالجة دون إدخال الكثير من التعقيد على محرك العرض ، ولكن استخدام قوالب كاملة سيكون مهمة كبيرة.

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

نأسف للإزعاج ، ونشكرك على تفهمك!

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

benjigoldberg هل يمكنك توضيح كيف تمكنت من حل هذه المشكلة؟ ماذا تقصد بسير العمل "القياسي"؟ مشكلتنا هي ببساطة القدرة على تعيين نفس كلمة المرور عبر عدد من المخططات الفرعية ، مع الكشف عن قيمة كلمة مرور واحدة فقط في مخطط مظلة أعلى مستوى. للتوضيح ، لدينا مخطط المستوى الأعلى لتطبيقنا ، والذي يتضمن مخططات فرعية لـ prometheus و grafana. نريد أن تكون كلمات المرور الثلاثة متطابقة. في الوقت الحالي ، يتعين علينا كشف الأجزاء الداخلية من المخطط ، وتعيين كلمة المرور ثلاث مرات ، بشكل فردي ، مما يؤدي إلى كسر التغليف بشكل سيء.

nuwang في هذا النوع من السيناريوهات ، عادةً ما نستخدم مخططًا شاملاً من المستوى الأعلى كما وصفته ، وننشئ سرًا في المستوى الأعلى ، ثم نطلب من كل من المخططات الفرعية استخدام هذا السر للوصول إلى بيانات الاعتماد. آمل أن يساعد ذلك - من الممكن أيضًا أنني أساءت فهم وصفك. دعني أعلم!

benjigoldberg ماذا لو لم تتحكم في المخططات الفرعية؟ grafana هو طرف ثالث على سبيل المثال. لا يمكننا تغيير قوالبه بسهولة لاستخدام سر محدد في المخطط الشامل.

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

نعم ، معظم مخططات الجهات الخارجية تصمم الأشياء على ما يرام. ومع ذلك ، إذا كان لدي مخطط مجمّع لتغليف مخططات الطرف الثالث ، فلا يمكنني التطبيع على بعض المتغيرات الشائعة دون وضع tpl في مخططات الطرف الثالث.

dtshepherd يمكنك التحكم في اسم المتغير / السر من ملف قيم المستوى الأعلى ثم دفعه لأسفل إلى المخططات الفرعية ، أليس كذلك؟

في حالة Elasticsearch / Kibana ، يتم اشتقاق اسم الخدمة من اسم الإصدار. لكنها ليست متساوية مع اسم الإصدار. هل يمكن لأي شخص اقتراح كيفية تمرير اسم الخدمة الناتج إلى Kibana فقط باستخدام إعادة تسمية متغير؟

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

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

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

ووجدنا عدد قليل آخر يتبادر إلى ذهني:

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

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

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

قد يكون اقتراحي أعلاه templates/_values.yaml إحدى الطرق لتحقيق ذلك بدون شروط الحافة والتعقيد # 2133. صرح القائمون على الصيانة بأنهم لن يدعموا نمذجة القيم. yaml ، لكن من غير الواضح ما إذا كانوا سينظرون في مثل هذا الاقتراح البديل للقيم النموذجية.

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

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

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

التوافق الوراء
تقدم ملفات قيم القوالب بناء جملة غير YAML في ملف YAML. هذا من المحتمل أن يكسر حلول القوالب الحالية التي تولد القيم. وبالحديث عن الخبرة ، فقد استخدمت ملفات القيم التي تم إنشاؤها حيث كان وجود ملفات غير YAML في الملف سيؤدي إلى تعطيل سير العمل لدينا. نظرًا لأن العديد من الأشخاص لديهم بالفعل أدوات حول قيم Helm ، فإن هذا من شأنه أن يجعل ملف القيم النموذجية فاصلًا للتوافق مع الإصدارات السابقة. سأعترف أننا لم نكن مثاليين في الحفاظ على التوافق مع الإصدارات السابقة ، ولكن في معظم الأحيان قمنا بعمل لائق في الحفاظ عليه ، ومن المؤكد أن ميزة مثل هذه ستؤدي بالتأكيد إلى كسر سير العمل الحالي

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

عفا عليها الزمن من قبل هيلم 3
في Helm 3 كجزء من نظام الأحداث / الخطاف ، سنسمح بتعديل القيم المستند إلى Lua بطريقة أسهل بكثير من الاضطرار إلى إخراجها من القالب. نظرًا لأننا نسير على قدم وساق في تطوير Helm 3 ، فإن إضافة ميزة مع جميع العيوب المذكورة أعلاه ستؤدي إلى مزيد من الاضطراب أكثر من القيمة المضافة. لذلك نحن لا نرفض هذا الأمر تمامًا ، لكننا نطبقه (وإن كان بطريقة مختلفة) بالنسبة إلى Helm 3

نأمل أن يوضح هذا الأمر أكثر للجميع!

نشكرك على الوقت الذي أمضيته في تقديم هذا التوضيح التفصيلي @ thomastaylor312 ، الذي يوضح هذا القرار بشكل أفضل كثيرًا.

أعتقد أن القضية الأساسية هي فصل الواجهة الخارجية للمخطط عن تفاصيل التنفيذ الداخلية. قد يبدو أن ذلك يتطلب آلية بسيطة لفصل ما يعرضه الرسم البياني كملف قيم خارجية ، من كيفية تحويل هذه القيم وتوزيعها إلى مخططات فرعية تابعة لجهات خارجية ، حتى في Helm 3. قد تكون خطافات أحداث Lua هي الحل ، أو ربما سيكون ذلك معقدًا جدًا لما يجب أن يكون سمة فطرية ، لكن من الصعب تقييم ذلك من موقع جهلي. لذا يرجى اعتبار هذا طلب ميزة لـ Helm 3 وشكرًا على كل العمل الشاق الذي يجري في Helm - إنه لمن دواعي سروري استخدامه!

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

شكرا لردود الفعل الرائعةnuwang! سوف نتأكد من أخذ ذلك في الاعتبار مع جميع أعمال Helm 3

هنا حل لهذا.

مجرد كتابة بعض تعبيرات القالب في values.yaml كسلسلة yaml عادية.
مثل.

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

وباستخدام tpl لتقييم sometemplate في ملف القالب.

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

القيم

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

التنمية

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

لقد عملت مع:

القيم

dbName: test_{{ .Release.Namespace }}

النشر

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

أنا أستخدم وحدة تحكم fabric8.io expose ، والتي توفر عنوان URL افتراضيًا للخدمة المكشوفة. الآن أريد إنشاء عنوان URL مخصص بناءً على مساحة الاسم ، شيء مثل
fabric8.io/exposeUrl: https://{{ tpl .Release.Namespace }}.jx.org.co ، شيء ستختاره وحدة التحكم في العرض ، لذلك ليس لدي خيار لاستخدام {{tpl ...}}. هل هناك طريقة يمكن من خلالها إجراء تحليل الاسم في قيم yaml نفسها؟

زوجان من الحلول التي أشار إليها الآخرون في سلاسل فرعية مختلفة:

1. استخدم قيم Helm العالمية لتمرير المتغيرات من الوالد إلى الطفل ( المرجع ).
2. استخدم مثبتات YAML لتحسين الجفاف داخل ملف قيمك. yaml ( المرجع ، شكرًاszwed).

هذه لا تغطي جميع حالات الاستخدام ، ومع ذلك من الجيد أن تكون في حزام الأدوات الخاص بك.

أنا أيضًا أرغب في وضع نموذج في قيمي.yml في الغالب لتكديس التعقيد والتكوين المحدد باستخدام المخططات. لذلك أبدأ بالرسم البياني العام ، وأنشئ مخططًا بيانيًا خاصًا في الأعلى يحتوي على معظم التكوين وترك بعض التفاصيل النهائية ليتم تحديدها عند النشر. روابط YAML ليست كافية: لا يمكنها استبدال قيم YAML الداخلية (مثل سلسلة ملف التكوين متعدد الأسطر) ، وتفتقر إلى منطق تبعية Helm مثل قيم المخطط الفرعي.

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

nicorikken Sry للمقبس الوقح ولكني أقترح تجربة helmfile للقيم النموذجية وإصدارات الدفة القوالب ذات الطبقات و helm-x لتعديل المخططات بدون تفرع ، وحتى الجمع بين helmfile + helm-x.

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

mumoshu شكرا على المكونات. لقد رأيتها مذكورة سابقًا كحل محتمل. سآخذ نظرة على ذلك. ستجلب تكلفة الأدوات الإضافية ، والتي قد نضطر إلى دمجها مع Argo-CD أيضًا (هل هذا ممكن؟). في الوقت الحالي ، قمت بتقسيم الريبو وقمت بتحديد معلمات مساحة الاسم ، وقمت بعمل علاقات عامة إلى الريبو المستقر للمخططات الأولية. دعونا نرى ما يفعله المشرفون عليه.

nicorikken شكرا على الرد!

أعتقد أنني أفهم تكلفة الأدوات الإضافية. لكن من ناحية أخرى ، أنا أسأل نفسي - إذا كانت هناك أداة ضخمة تغطي جميع حالات استخدام الدفة + ملف الدفة + خوذة- x ، فهل سيكون من السهل التعلم / الاستخدام؟

IMHO انها تقريبا مسألة وثائق. إذا كانت الأداة الإضافية تحتوي على وثائق كافية لدمجها مع أداة المنبع وأداة الطرف الثالث (helm و argo cd في هذه الحالة المحددة) ، فهي قابلة للمقارنة مع الحل داخل الشجرة.

هل هذا ممكن؟

نعم :) helmfile template يلعب بشكل جيد مع ميزة "config management plugin" في argo-cd.

بالنسبة لحالة الاستخدام المحددة لتحديد مساحة الاسم ، قمت بعمل علاقات عامة أولية لمخطط جينكينز هيلم https://github.com/helm/charts/pull/15202 هذا يضيف معلمة namespaceOverride . آمل أن يتم اعتماد هذا النمط على نطاق أوسع ، لتمكين نشر مخطط Helm على مستوى المجموعة.
سآخذ بعض الوقت للنظر أكثر في Helmfile. يبدو بالتأكيد أنه يلبي متطلباتنا من خلال تمكين قوالب متقدمة على مستوى الكتلة أعلى المخططات الأولية ، والتكامل مع Argo-CD.

هل يعرف أي شخص كيفية القيام بذلك عند تعيين شيء ما لقاعدة affinity ؟ على سبيل المثال ، في مخطط دخول NGINX عند stable/nginx-ingress ، أريد تعيين قيمة controller.affinity لتكون على النحو التالي:

القيم

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 يا! أين تحدد القالب nginx-ingress.name في نموذج القيم yaml الخاص بك؟

يجب تحديده مسبقًا بـ {{define ... كما هو موضح في https://golang.org/pkg/text/template/#hdr -Actions

أيضًا - {{.Release.Name}} يعمل فقط ضمن سلاسل أقل releases[].values في helmfile.yaml .

يجب أن يعمل هذا:

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

هذا لا يعمل:

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

أعتقد أنه يستحق طلب ميزة مخصصة إذا كنت بحاجة إلى واحد من هؤلاء.

mumoshu لم يتم تعريفه في ملف القيم الخاص بي ، إنه شيء مضمن في مخطط NGINX Helm الموجود في stable/nginx-ingress . هذه وجهة نظري في الواقع ، أنا أحاول استخدام هذا القالب الموجود بالفعل في ذلك الرسم البياني.

للسجل ، أنا لا أستخدم stable/nginx-ingress كمخطط فرعي في الرسم البياني الذي أقوم بتطويره ؛ أنا فقط أستخدمه مباشرة لنشر دخول NGINX.

لم يتم تعريفه في ملف القيم الخاص بي ، إنه شيء مضمن في مخطط NGINX Helm الموجود في مستقر / nginx-ingress. هذه وجهة نظري في الواقع ، أنا أحاول استخدام هذا القالب الموجود بالفعل في ذلك الرسم البياني.

لسوء الحظ ، هذا مستحيل لأن قوالب Helmfile (القيم) تعمل بشكل مستقل عن قوالب Helm (مخطط) ، و nginx-ingress.name هو قالب محدد في مخطط Helm للاستخدام في قوالب المخططات.

ربما تكون الطريقة الوحيدة هي نسخ كتلة {{define "nginx-ingress.name"}} المحددة في مخطط nginx إلى قالب قيم ملف helmfile values.yaml ؟

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

في القيم.

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

وسأستخدم هذا في أسرار يامل:

Secrets_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

:) لحسن الحظ ، يوضح أحدث دليل لشركة Helm كيفية تحقيق ذلك.
https://helm.sh/docs/howto/charts_tips_and_tricks/#using -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 هو تشغيل helm template على ملف القيم .yaml. تعمل بشكل جيد أجهزة الصراف الآلي.

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 يعمل بشكل أساسي على تشغيل هذا البرنامج النصي bash لكل ملف values.yaml .

هناك حالة استخدام حيث قد تحتاج إلى تمرير اسم النشر إلى مخططات التبعية حيث لا يمكنك التحكم فيها.

على سبيل المثال ، أحاول تعيين podAffinity لـ zookeeper. ولدي مخطط رأس تطبيق يحدد zookeeper باعتباره تبعية. في هذه الحالة ، أقوم بتمرير انحراف القرنة إلى حارس الحديقة عبر القيم. لذلك في ملف قيم تطبيقاتي ، يوجد لدي قسم zookeeper.affinity. إذا كانت لدي القدرة على الحصول على اسم الإصدار داخل القيم yaml ، فسأقوم بتعيين هذا على أنه افتراضي وسيتم الانتهاء منه.

لكن الآن في كل عملية نشر يجب أن أتجاوز هذه القيمة ، وهي مشكلة كبيرة.

@ thomastaylor312 وغيرها:

لقد قرأت العديد من المشكلات ذات الصلة حول هذا الموضوع العام ، ويبدو أن فكرة إنشاء قوالب values.yaml غير عملية ، وغير تافهة ، وما إلى ذلك.

هل سيكون من المعقول أن ندعم بدلاً من ذلك بعض الطور الوسيط الإضافي أثناء عمل قوالب / نشر الرسم البياني / إلخ. حيث تتلقى بعض البرامج النصية التعسفية (أي التي يوفرها المستخدم) (مثل Python و BASH و Lua وما إلى ذلك) نسخة من values.input.yaml (المعروف أيضًا باسم values.yaml ) ولها إمكانية الوصول إلى متغيرات مختلفة (على سبيل المثال .Release.* ) ، ويمكن أن يكون البرنامج النصي مسؤولاً عن إنشاء ملف values.output.yaml "نهائي" ديناميكيًا (والذي يتم استخدامه فعليًا بواسطة بقية قوالب الرسم البياني)؟ إذا كان Helm قادرًا على توفير "الخطافات" لهذا الغرض ، فيبدو أنه قد يكون حلًا وسطًا قابلاً للتطبيق ، على سبيل المثال ، "إليك جميع البيانات وخطاف لتشغيل البرنامج النصي الخاص بك لإنشاء values.output.yaml ، استمتع!".

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

أفعل حاليًا شيئًا كهذا في الوقت الحالي ، ولكنه يتطلب مني تقديم برنامج نصي "قاذفة" لمخططاتي ، لذلك لا يمكن للمستهلكين في المراحل النهائية "تثبيت" مخططاتي ببساطة (حالة استخدام مماثلة إلى حد ما لـ helmfile ) . نشأ هذا من الحاجة إلى إنشاء نماذج للقيم لمخططات / حاويات الجهات الخارجية (التي لا يمكنني تعديلها لأسباب فنية وقانونية). في هذه المخططات ، لدي قيم مشفرة تعادل .Release.Namespace تظهر حرفيًا في كل مكان (داخل سلاسل URI / URL لـ FQDN داخل المجموعة لخدمات K8S ، ومصفوفات أسماء المضيف ، و envvars ، وما إلى ذلك). في كل مرة أحتاج فيها إلى نشر مخطط المستوى الأعلى على مساحة اسم مختلفة ، إذا لم يكن البرنامج النصي المساعد لدي ، فسيتعين علي تعديل ما يقرب من 30 إدخالًا في values.yaml . إذا كانت هناك طريقة ما للتوحيد القياسي على هذا (حتى لو لم يكن من خلال التنفيذ الذي وصفته أعلاه) ، فسيكون ذلك مفيدًا.

IAXES هل من المحتمل أن تساعد أشياء ما بعد التصيير الجديدة في حل هذه المشكلة؟

@ thomastaylor312 في حالة الاستخدام الخاصة بي ، نعم بالتأكيد. في حالات الاستخدام التي وصفها آخرون (أي أنها غير تافهة وتتطلب درجة معينة من التوليد الديناميكي لملف values.yaml ، بالإضافة إلى الوصول إلى متغيرات وقت النشر مثل .Release.Namespace ، إلخ. .) ، أظن بشدة أنه يمكن أن يحل هذه المشكلات أيضًا (سيتطلب بعض التعليقات الإضافية من الآخرين الذين يريدون / يحتاجون إلى الميزة الأصلية الموضحة في الجزء العلوي من هذا الموضوع / المشكلة).

على الرغم من أنني لست على دراية بقاعدة رمز Helm ، إلا أنه يمكنني تقديم دعم التصميم / الاختبار أو تقديمه (أو الاستغناء عن هذا كإثبات للمفهوم إذا كان بإمكاني اختبار الاتصال مع المتعاونين / المشرفين للحصول على المشورة بشأن مكان الحقن مقتطفات الشفرة الخاصة بي لإنشاء نظام "الخطاف").

إذا كان هذا أمرًا يستحق الاستكشاف ، فقد يكون من الجيد أيضًا إرسال المشرفين / المالكين إلى + CC (استشارة helmfile آراء / تعليقات / إلخ) ، حيث قد يكون من الممكن ربط حل حالي لـ إثبات المفهوم. إذا كان بإمكان المرء إعداد هذه الخطافات ولديك أي خطوة حل تعسفي لـ "ملء الفراغات" ، ولا يزال يتعين على المستهلك / المستخدم النهائي تنفيذ helm install (بالإضافة إلى تثبيت apt / yum / apk بعض التبعيات) ، سيكون هذا رائعا!

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

IAXES إذا فهمت بشكل صحيح أنك تقترح ، فقم بتوفير روابط للتطبيقات الخارجية ثم استخدام إخراجها كإحصائيات.

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

مع الأخذ في الاعتبار الدفة بما في ذلك محرك القالب الذي هو أكثر من قادر بما يكفي للقيام بذلك ، فأنا لست سعيدًا حقًا بهذا النهج. أولاً ، يتطلب ذلك إعداد تطبيقات خارجية ودمجها في العمليات التي من المحتمل أن تكون قيد التشغيل بالفعل ، مثل CI / CD ، والثاني وهو الأهم يتطلب قالبًا خارج العملية ، وهو غير محدد جيدًا. كما ذكرت قبل هذا التعريف ، فإن التوحيد موجود بالفعل مع الدفة. فلماذا لا تستخدم هذا في الدفة وتوفر الوسائل للميزة المطلوبة بالفعل؟

أو يمكن استخدام تنفيذ البرمجة النصية لوا التي تمت مناقشتها بالفعل وتوثيقها لهذا الغرض. بالطبع لا يتوفر أيضًا.

حاليًا يستخدم نهجي استبدال قيمة بيئة ملف قيم helmsman. إنه محدود ، لكن يمكن استخدامه مع بعض القفزات.

تجعل هذه المشكلة من الصعب استخدام عمليات النشر باللونين الأزرق والأخضر مع مخطط الدفة الرئيسي لجميع تطبيقاتك ، على الأقل إذا كانت أي من القيم الخاصة بك هي عناوين URL خاصة بالبيئة أو اتصالات قواعد البيانات. في الوقت الحالي سأحاول حل @ leox-phq.

أتساءل أيضًا عما إذا كان إنشاء ملف templates/values.yaml بدلاً من ملف values.yaml يمكن استخدامه كمصطلح لإخبار Helm بإجراء بدائل للقيمة ... لست متأكدًا مما إذا كان هذا سيساعد في معالجة بعض مشاكل تنفيذ هذا في الأصل في حلم التي تم ذكرها ...

تحديث: يمكن تحسين الحل البديل لـ @ leox-phq لتجنب الحاجة إلى الاستبدال باستخدام sed باستخدام الخيار --show-only وهو helm template :

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

أنا أبحث عن طريقة لاستخدام ملفات yaml في قيم Chart.yaml appVersion . لست متأكدًا مما إذا كان هناك حل بالفعل ، أم أن هذه المشكلة مطلوبة.

nodesocket إنه موجود بالفعل في .Chart ! https://docs.helm.sh/docs/chart_template_guide/builtin_objects/

@ thomastaylor312 اعتقدت أنه يمكنك فقط استخدام .Chart.AppVersion داخل قوالب ليست في ملفات قيم. yaml؟

آه آسف ، فاتني هذا الجزء. نعم ، لا يوجد قوالب لملفات القيم للأسباب المذكورة هنا.

بعد القراءة عن القوالب في values.yaml وتجربة حلول مختلفة ، يبدو أن هذه هي أنظف الحلول في الوقت الحالي (من حيث كونها أكثر قابلية للقراءة من خلال عدم الاضطرار إلى البحث في أماكن كثيرة جدًا):

• انشر مخططات Helm من خلال Terraform ، وقم بتوفير ملف خارجي values.yaml.tmpl ، واستخدم templatefile("values.yaml.tmpl",..) لعرض متغيرات Terraform.
• انشر مخططات Helm من خلال Helmfile ، وقم بتوفير جميع القيم في السطر ، واستخدم {{ requiredEnv "..." }} لعرض متغيرات البيئة.

هناك أيضًا # 6876 وهو نهج أحدث لهذه المشكلة ، وهو حل المشكلات التي أثارتها https://github.com/helm/helm/issues/2492#issuecomment -413635332. ومع ذلك ، فهي كبيرة وتستغرق وقتًا طويلاً لتتم مراجعتها.