Helm: الوصول إلى قيم المخطط الفرعي بشرطة في الاسم

هذا سؤال وجيه. لم أواجه مشكلة في القيام بذلك ، لكنه عدم الاتساق. technosophos هل يجب أن نغير أحدهما ليطابق الآخر؟

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

الكتلة التالية تعطيني خطأ.

{{ if .Values.gitlab-runner.enabled }}

خطأ: UPGRADE FAILED: خطأ في التحليل في "gitlab / Templates / publish.yaml": template: gitlab / template / publish. yaml: 217 : شخصية سيئة U + 002D "-"

استخدم الدالة index template للوصول إلى قيمة بعلامة "-" في الاسم: {{ index .Values "gitlab-runner" }} .

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

شكرًا ، إنها تعمل بهذه الطريقة.

prydonius هل تتذكر سبب بشرطة ؟ كنت أبحث في الوثائق القديمة وكانت هذه سابقة وضعناها منذ البداية. أعتقد أنه ربما ليس تغييرها فكرة جيدة.

أحاول فهم كيفية عمل الفهرس.
كيف يمكنني الوصول إلى servicename من:

mysub-chart:
  servicename: mysubchart-service

؟
الحل الذي تم العثور عليه: {{ index .Values "mysub-chart" "servicename" }}

كيف يمكنك استخدام أسماء الشرطة في بنية التحكم ، مثل كتلة with أو range block؟

{{- range $key, $value := .Values.my-service-name.deployment.annotations }}

@ spearsem أعتقد أن التعليق أعلاه قد حصل على الحل الصحيح لهذه المشكلة. وأعتقد أن هذا يجب أن تعمل:

{{- range $key, $value := index .Values "my-service-name" "deployment" "annotations" }}

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

{{ $annotations := index .Values "my-service-name" "deployment" "annotations" }}
{{- range $key, $value := $annotations }}

bacongobbler هل يعمل هذا أيضًا مقابل with ؟ لست على دراية بتطبيق with لمعرفة ما إذا كان بإمكانه الاستفادة من نتيجة تقييم وظيفة أخرى كـ "السياق".

يبدو أن النص / القالب يقول أنه يجب أن يعمل مع أي بنية ، لذلك أفترض نعم.

إذا كانت قيمة خط الأنابيب فارغة ، فلن يتم إنشاء أي إخراج ؛ خلاف ذلك ، يتم تعيين النقطة على قيمة خط الأنابيب ويتم تنفيذ T1.

لا يبدو أن الطريقة المتغيرة تعمل بالنسبة لي. . حدث الخطأ في سطر لاحقًا.

يتطلب اصطلاح تسمية منفذ Istio أيضًا شرطات (راجع متطلبات مواصفات Pod ).

هل هناك أي حل بديل لوضع vars في CLI؟

helm install --set one-two.three=10 releasename ./chartname

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

أواجه هذه المشكلة أيضًا.

أعتقد أنه سيكون من الجيد أن تقوم Helm بتمرير القيم من الرسم البياني الرئيسي إلى subchart-name باستخدام اسم camelcase-ify بدلاً من ذلك ، على سبيل المثال subchartName . سيجعل اصطلاح اسم المخطط واصطلاح اسم المتغيرات متوافقين مع بعضهما البعض ، بالإضافة إلى تخطي مشكلات بناء الجملة من الأعلى.

هذا لا يعمل إطلاقا في القوالب ، مثال الكود هذا:
{{فهرس. قيم "المفتاح الأول" "secondkey"}}
يعمل في NOTES.txt ولكن في _helpers.tpl عند إصدار أمر ترقية:
_المساعدون. tpl: 24 : 3: تنفيذ "test.template" في

العميل: & version.Version {SemVer: "v2.6.2"، GitCommit: "be3ae4ea91b2960be98c07e8f73754e67e87963c"، GitTreeState: "clean"}
الخادم: & version.Version {SemVer: "v2.7.0"، GitCommit: "08c1144f5eb3e3b636d9775617287cc26e53dba4"، GitTreeState: "نظيف"}

نفس الشيء مع كلا الإصدارين متشابهين:
العميل: & version.Version {SemVer: "v2.6.2"، GitCommit: "be3ae4ea91b2960be98c07e8f73754e67e87963c"، GitTreeState: "clean"}
الخادم: & version.Version {SemVer: "v2.6.2"، GitCommit: "be3ae4ea91b2960be98c07e8f73754e67e87963c"، GitTreeState: "clean"}

kubectl هو:
إصدار العميل: version.Info {Major: "1"، Minor: "9"، GitVersion: "v1.9.2"، GitCommit: "5fa2db2bd46ac79e5e00a4e6ed24191080aa463b"، GitTreeState: "clean"، BuildDate: "2018-01-18T10: 09: 24Z "، GoVersion:" go1.9.2 "، المترجم:" gc "، النظام الأساسي:" darwin / amd64 "}
إصدار الخادم: version.Info {Major: "1"، Minor: "8"، GitVersion: "v1.8.4"، GitCommit: "9befc2b8928a9426501d3bf62f72849d5cbcd5a3"، GitTreeState: "clean"، BuildDate: "17-11-20T05: 43Z "، GoVersion:" go1.8.3 "، المترجم:" gc "، النظام الأساسي:" linux / amd64 "}

svidrascu ، تحقق من أن لديك القيم المحددة في ملف Chart.yaml لذلك المخطط الفرعي المحدد. يبدو أن محرك القوالب لا يمكنه العثور على المتغير الخاص بك

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

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

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

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

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

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

مغلق عبر https://github.com/helm/helm/pull/4379

لمعلوماتك ، تم إجراء تعديل على # 4379 في # 4400.

هذا هراء للغاية - لا توجد شرطات ولا شرطات سفلية ولا أحرف كبيرة. كيف ينبغي للمرء تحديد اسم مخطط مركب لمكونين متماثلين (أو أكثر)؟ تغيير . إلى " " أمر مروع:

ksemaev يرجى الاطلاع على # 4400. كما ذكرنا سابقًا ، ما زلنا نريد من المستخدمين استخدام الشرطات في أسماء الحزم الخاصة بهم ، ولكن يجب أن يكونوا على دراية بـ "مسكتاتشي" حول قيود معينة مع نظام القوالب.

عفوًا ، اصبع دهنًا زر الإغلاق: يضحك:

هل هناك أي حل بديل لوضع vars في CLI؟

helm install --set one-two.three=10 releasename ./chartname

إذا كان أي شخص يتساءل ، يبدو أن هذا يعمل اعتبارًا من الدفة والحارث v2.14.2 .

$ helm install --set one-two.three=10 --name foo stable/mariadb
$ helm get values foo
# one-two:
#  three: 10

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

لأشخاص آخرين ، إذا كنت بحاجة
{{-if and value1 value2 }} ستحتاج إلى القيام بذلك بعد ذلك:

{{- if .Values.loki.enabled }}
{{- if index .Values "prometheus-operator" "grafana" "enabled" }}
{{- if index .Values "prometheus-operator" "grafana" "sidecar" "datasources" "enabled" }}

لدي سؤال مختلف طفيف. لنأخذ مثالاً عشوائيًا -
{{- إذا كان الفهرس .Values ​​"prometheus-worker" "grafana" "sidecar" "datasources" "ممكّن"}}

سؤالي هو إذا كنا لا نعرف "/ prometheus-worker" كيف أشير إلى هذا المفتاح باستخدام الفهرس. في الأساس ، أود الحصول على المفتاح الأول من .Values ​​(المفتاح ديناميكي ، فهو ليس ثابتًا في حالتي ، وبالتالي كيفية إحالة هذه الخريطة عن طريق المفتاح في الفهرس. هل يمكن لأي شخص أن يخبرني.

لقد استخدمت / "nithin-kumar" / لهذه المشكلة ، إنها مشكلة "-" ، جربت أحرف الهروب

أي شخص لديه حل عند استخدام toYaml؟
فشل مع
<toYaml>: wrong number of args for toYaml: want 1 got 5
مع ou بدون استخدام الوظيفة index .

أي إصلاح لـ U + 002D "-"

@ تعديل / صيانة

هل هناك تحديث لهذا؟

أي نوع من التحديث؟

مرحبًا ، تم فتح هذه المشكلة منذ فترة ، ولكن المشكلة لا تزال تحدث.

تنص إرشادات مخطط Helm على أنه يجب تسمية المخطط بشرطة (https://helm.sh/docs/chart_best_practices/conventions/)
لكن القوالب تعطينا وقتًا عصيبًا إذا حاولنا وضع شرطات في values.yaml لعكس أسماء المخططات ، إذا حاولنا استخدام قيم الشرطات مثل هذا:

{{ .Values.my-chart.name }}

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

{{ index .Values "my-chart" "name" }}

بالإضافة إلى ذلك ، المفاتيح في values.yaml يجب أن تكون CamelCased (https://helm.sh/docs/chart_best_practices/values/).

لا أعتقد أن تسمية المفاتيح يجب أن تؤثر على قالب هيلم.

هل من المخطط تطبيع ذلك؟

bacongobbler ، مثل ما إذا كان سيتم "إصلاحه" ، أي أننا سنتمكن من استخدام الشرطات دون اللجوء إلى الاختراقات والحيل ، أو ما إذا كان هذا نهائيًا "لن يتم إصلاحه أو التعود عليه أو التفرع منه أو العثور عليه شيء آخر"

إنه تقييد للغة قالب Go. إذا كنت ترغب في إجراء تغيير ، فيجب عليك تقديمه في المنبع في مشروع Go: https://github.com/golang/go

إذا / عندما قاموا بإصلاحه ، فسنحصل على دعم له.

بطريقة Google النموذجية ("عادةً ما يكون المستخدمون مخطئين") ، تم إعطاء عبارة نهائية "لن يتم إصلاحها أو التعود عليها أو شوكة أو العثور على شيء آخر" https://github.com/golang/go/issues/ 23710. أعتقد أن الأسباب المقدمة (التي تتحدث على وجه التحديد عن حالة الاستخدام helm ) صحيحة تمامًا ولكن المؤلفين go لا يهتمون حقًا.

https://github.com/golang/go/issues/23710#issuecomment -363488583 يذكر حلين - تثبيط استخدام الشرطات (النهج الحالي) أو "إعادة كتابة خطوط أنابيب نموذج [helm] لاستخدام وظيفة الفهرس تلقائيًا". بينما أقر بأنه قد يكون مهمة كبيرة ، ألن يكون من الممكن أن يكون لديك معالج مسبق للقالب يمكنه فعل هذا بالضبط؟ ربما هناك خطاف أو شيء يمكن كتابته للمعالجة المسبقة فقط هذا؟ بينما من الواضح أن العمل حول هذا ممكن ، إلا أنه يبدو طفوليًا قليلاً من المؤلفين go ويستحق الإصلاح مقابل helm .

بينما أعترف أنه قد يكون مهمة كبيرة

بنغو.

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

إذا كنت مهتمًا بالمساهمة ، فلا تتردد في إلقاء نظرة!

بالنسبة لي ، توضيح الموقف هو خطوة أولى رائعة. لدينا ما يلي:

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

إذا اعتقد الجميع أن هذا دقيق وعادل ، سأتوقف عن إزعاج الجميع! :-)

أود أن أضيف أن أي شخص يريد النظر إلى هذا يجب أن يفكر في كتابة HIP - راجع https://github.com/helm/community/blob/master/hips/hip-0001.md

وإلا نعم

"إعادة كتابة خطوط أنابيب قالب [الدفة] لاستخدام وظيفة الفهرس تلقائيًا". بينما أقر بأنه قد يكون مهمة كبيرة ، ألن يكون من الممكن أن يكون لديك معالج مسبق للقالب يمكنه فعل هذا بالضبط؟

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

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

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

نظرًا لأن helm يستخدم لغة النمذجة go ، فلن تتمكن من استخدام مفاتيح الشرطات - مباشرة في القوالب باستخدام آلية المرجع العادي {{ .Values.mybasekey.my-key }} (هذا غير صالح). هذا هو تقييد go النموذجيه لغة، وشيء go ورفض الكتاب إلى الدعم. إذا كنت تريد حقًا استخدام الشرطات في المفاتيح ، فيمكنك التغلب على هذا التقييد باستخدام وظيفة index ، مثل {{ index .Values.mybasekey "my-key" ]} . نظرًا لأن هذا الحل البديل سهل نسبيًا ، فلا توجد حاليًا خطط لدعم استخدام الشرطات في أسماء المفاتيح بدون index في helm . ستكون أسماء المخططات الفرعية أيضًا مفاتيح في القوالب ، لذلك إذا كنت تستخدم مخططًا فرعيًا مع شرطة في الاسم وتريد تجاوز قيمة ، فستحتاج إلى توفير اسم مستعار لاسم المخطط أو استخدام الحل البديل المذكور هنا ( {{ index .Values "my-chart" "name" }} ).

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

لست متأكدًا من المكان الذي يجب أن يذهب إليه مثل هذا التفسير ، إذا كان دقيقًا.

+1 أوافق على أننا بحاجة إلى قول هذا في الوثائق في مكان ما ، على الأقل.

إنه أمر محير بالتأكيد ، لكنني لا أرى طريقًا لتسهيل ذلك في هيلم. أي مساعد قالب نضيفه سيعمل مثل وظيفة بنفس الطريقة التي تعمل بها index (مثل مجموعة وظائف Helm toYaml ، toJson ). الطريقة الوحيدة التي يمكنني من خلالها توفير وصول مباشر أكثر هي إزالة الشرطات في المفاتيح ، ولكن كما ذكرت ، فهي صالحة YAML / JSON ومن المحتمل أن يكون ذلك أكثر إرباكًا. في النهاية ، لا يدعمه محلل قالب Go وليس هناك الكثير مما يمكننا القيام به حيال ذلك دون تفويته.

هذا مثال عملي لـ toYaml :
{{- toYaml Values.jobs.update-es.resources | nindent 12 }} = خطأ

{{- toYaml (index .Values "jobs" "update-es" "resources") | nindent 12 }}