لقد لاحظت للتو أن شيئًا مثل helm install --set tag=20161216
ينتهي بالتدوين العلمي في القالب وذلك لأن {{ typeOf .Value.tag }}
ينتج float64
.
هذا صحيح حتى بالنسبة للأعداد الصحيحة الصغيرة مثل helm install --set tag=1
-> float64
.
هذا يحدث مع helm 2.1.0
هل تعمل بشكل مختلف إذا قمت بعمل --set tag=\"1\"
؟
بفضل chancez ، نعرف المشكلة بالضبط: أثناء التحويلات من وإلى JSON التي تم إجراؤها بواسطة ghodss/yaml
، يتم تحويل الأعداد الصحيحة إلى float64s لتمثيل النوع الرقمي لجافا سكريبت. هذا يتسبب في تمثيل جميع الأعداد الصحيحة فوق قيمة معينة في التدوين العلمي.
لقد تعرضت للعض من نفس المشكلة. طريقة تجاوز الحدبة (أو الحشرة) هي القيام بذلك:
--set bignumber=\\"a185576882739235744\\"
الحل الآخر الذي استخدمناه هو القيام بأشياء مثل هذه:
--set port=":1234567"
ثم في النموذج:
{{ .Values.port | replace ":" "" }}
ياك! 😷
هذا أمر مؤلم ، ولا يبدو أن حل ipedrazas يعمل بالنسبة لي ، أو أي مزيج آخر من الاقتباس / الهروب الذي جربته.
لست مستعدًا تمامًا بعد لابتلاع كبريائي ومحاولة
في الوقت الحالي ، أقوم بالتغلب على هذا من خلال توسيع برنامج النشر الخاص بي لكتابة البيانات كـ yaml إلى ملف مؤقت واستخدام ذلك كوسيطة -f
.
أواجه نفس المشكلة من وقت لآخر لعلامة الصورة.
سأحاول استخدام أحد هذه الحلول. آمل أن يتم إصلاحه قريبًا :)
في حالتي ، أرى هذا أدناه على --set image.tag=5997578
:
$ kubetctl describe po msj-treasure-map-msj-treasure-map-192172122-dnb80
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 1m default-scheduler Successfully assigned msj-treasure-map-msj-treasure-map-192172122-dnb80 to ip-10-253-13-113.ec2.internal
Warning InspectFailed 15s (x9 over 1m) kubelet, ip-10-253-13-113.ec2.internal Failed to apply default image tag "596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-uwsgi:5.997578e+06": couldn't parse image reference "596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-uwsgi:5.997578e+06": invalid reference format
Warning InspectFailed 15s (x9 over 1m) kubelet, ip-10-253-13-113.ec2.internal Failed to apply default image tag "596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-nginx:5.997578e+06": couldn't parse image reference "596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-nginx:5.997578e+06": invalid reference format
Warning FailedSync 15s (x9 over 1m) kubelet, ip-10-253-13-113.ec2.internal Error syncing pod, skipping: [failed to "StartContainer" for "msj-treasure-map-uwsgi" with InvalidImageName: "Failed to apply default image tag \"596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-uwsgi:5.997578e+06\": couldn't parse image reference \"596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-uwsgi:5.997578e+06\": invalid reference format"
, failed to "StartContainer" for "msj-treasure-map-nginx" with InvalidImageName: "Failed to apply default image tag \"596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-nginx:5.997578e+06\": couldn't parse image reference \"596297932419.dkr.ecr.us-east-1.amazonaws.com/msj-trmap-nginx:5.997578e+06\": invalid reference format"
$ helm version
Client: &version.Version{SemVer:"v2.5.1", GitCommit:"7cf31e8d9a026287041bae077b09165be247ae66", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.5.1", GitCommit:"7cf31e8d9a026287041bae077b09165be247ae66", GitTreeState:"clean"}
كما أنني أواجه نفس المشكلة على دفة 2.6.2.
Client: &version.Version{SemVer:"v2.6.2", GitCommit:"be3ae4ea91b2960be98c07e8f73754e67e87963c", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.6.2", GitCommit:"be3ae4ea91b2960be98c07e8f73754e67e87963c", GitTreeState:"clean"}
يؤدي تجريد YAML إلى JSON إلى إزالة الكثير من المعلومات ، ومعظمها متعلق بالنوع. يعني أنه لا يمكنك كتابة قيم التحقق قبل النشر.
أعتقد أنه يمكن حل هذا بالانتقال إلى مكتبة yaml مختلفة. ربما هذا: https://github.com/go-yaml
بينما كنت أعاني من هذه المشكلة اليوم ، اكتشفت أن الفلتر toString
يمكن أن يساعد في هذا:
dockerPort: {{ .Values.dockerPort | toString }}
ثم تمكنت من تمرير المنفذ في سطر الأوامر ( --set dockerPort=2376
) وتم تفسيره بشكل صحيح.
لقد رأينا هذا للتو في 2.7.2 ومعظم الحلول لا تعمل حقًا بالنسبة لنا باستثناء كتابة جميع خيارات --set
إلى ملف محلي وتمرير ذلك عبر helm -f locals.yml
.
لقد رأيت هذا أيضًا في 2.7.2 (وقدمت # 3246 نتيجة لذلك) ، لذا +1 في هذه المشكلة. كما هو الحال في https://github.com/kubernetes/helm/issues/3001 ، كنت أستخدم أيضًا git SHAs لعلامات صورة عامل الإرساء. الحل البديل الآن ، FWIW ، هو إضافة علامات الصورة بـ -gitsha
+1 بالنسبة لي أيضًا.
$ helm version ⏎
Client: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
$ git rev-parse --short HEAD
6180689
$ helm upgrade foobar \
-i charts/foobar \
--set image.tag=$(git rev-parse --short HEAD) \
--reuse-values
بعد النشر ، أحصل على هذا:
Failed to apply default image tag "gcr.io/foobar/foobar:6.180689e+06": couldn't parse image reference "gcr.io/foobar/foobar:6.180689e+06": invalid reference format
Error syncing pod
أحصل أيضًا على InvalidImageName
عند تشغيل kubectl get pods
.
لا يبدو أن إلحاق | toString
يحدث فرقًا بالنسبة لي.
هل يمكنك فقط القيام بما يلي:
{{ .Values.tag | int64 }}
لا شك أنlaverite في الرسوم البيانية ، ولكن هذا يستخدم المحلل اللغوي set. توجد هذه المشكلة فقط للمحلل اللغوي - set. القيم التي تم تمريرها عبر القيم. yaml يتم تحليلها بشكل صحيح. :)
يبدو أن هذا مرتبط بالرقم 3155
نعم ، صدق ذلك
نفس المشكلة هنا مع helm 2.8.0.
bacongobbler أو technosophos لدي إصلاح لهذه المشكلة على رقم 3599 ، هناك بالفعل موافقة واحدة ، فقط بحاجة إلى أخرى. شكرا!
تم حلها عبر # 3599
شكرا على ping @ arturo-c :)
رؤية هذا الخطأ أيضًا مع Helm 2.9.1
أتساءل لماذا لا يصطاد helm lint
هذا؟ انظر # 4099
لدي فضول لماذا تم حل هذا عن طريق إضافة --set-string
، بدلاً من إصلاح ما يبدو لي أنه خطأ واضح في --set
.
هل من المحتمل أن ينوي أي شخص أن يتم إجبار الأرقام على التدوين العلمي في ملفات yaml الخاصة بهم؟
كلمتين: التوافق مع الإصدارات السابقة :)
يمكننا تغيير كيفية قيام المحلل اللغوي --set
بفرض القيم الصحيحة في Helm 3 ، ولكن بشكل عام اخترنا منع تغيير السلوك المتوقع للوظائف الأساسية مثل --set
نظرًا لوجود العديد من المستخدمين الذين يقومون بتشغيل Helm في الانتاج. لا يمكننا أيضًا إجبار جميع القيم في --set
على السلاسل لأن ذلك سيؤدي إلى كسر السلوك الحالي مثل السلوك المتوقع حول --set-string
كإجراء عملي حل في الوقت الحاضر.
التوافق الوراء؟ من الميزات التي هي مجرد "WTF" ومن المحتمل ألا يريدها الكثيرون أو يستخدمونها؟ في أداة تخضع لتطوير كبير ولا يتم تبنيها على نطاق واسع؟ أقترح إعادة التفكير في ذلك وإصلاحه قبل فوات الأوان.
technosophos شكرا.
مثال:
kind: Secret
data:
some_db_port: {{ .Values.dbInfo.db_port | replace ":" "" | b64enc }}
إنه عمل بالنسبة لي.
OndraZizka شكرًا لك على التعليقات (المتحمسة جدًا). نحن بالتأكيد نتطلع إلى معالجة بعض هذه المشكلات السلوكية المتزعزعة التي يمتلكها المحلل اللغوي --set
لـ Helm 3 ، على الأرجح عن طريق استبدالها بشيء مشابه للمحلل اللغوي الجديد --set-string
.
أوافق تمامًا على أن سلوك --set
غريب جدًا في هذه الحالة (وحتى خاطئ تمامًا) ، لكن لا يمكننا أن نتوقع استبدال مكتبة تحليل كاملة بأخرى وأن نكون على ثقة من أنه لن يكون هناك أي إكراه آخر البق في النظام الجديد. يُعتبر تبديل مكتبات الإكراه تغييرًا غير متوافق مع الإصدارات السابقة.
في الوقت الحالي ، تعد ميزة --set-string
ميزة رائعة وأنا أوصي بها بشدة لأي شخص آخر يواجه هذا الخطأ ليرجى استخدام --set-string
قدر الإمكان عندما لا تعتمد على نوع الإكراه. بهذه الطريقة ، يتم فرض القيم كسلسلة وليس كعائمة.
لسوء الحظ ، عندما يقوم Ansible بتنسيق dict إلى yaml (وهي قيمي.yaml) ، فإنه لا يضيف أي اقتباسات ، وهي مشكلة كبيرة بالنسبة لي. لا أصدق أنني مضطر لاستخدام هذا الاختراق الدموي: replace ":" ""
إذا كنت بحاجة إلى عمل حول يعمل بدون إضافة بادئة إلى العلامة بـ :
وإزالتها لاحقًا ، يمكنك استخدام هذا (tl ؛ dr: عندما تكون العلامة رقمًا ، استخدم printf لطباعتها ، وإلا اطبع سلسلة لديك)
{{- $tag := .Values.image.tag }}
{{- $type := printf "%T" $tag }}
image: "{{ .Values.image.repository }}:{{if eq $type "float64"}}{{ printf "%.0f" $tag }}{{ else }}{{ $tag }}{{ end }}"
يحدث الخطأ أيضًا مع helm ... -f myval.yaml
لمعلوماتك ، تم إصلاح هذا في https://github.com/helm/helm/pull/6010.
bacongobbler ما زال يحدث لي مع إصدار الدفة v2.14.3
هل يمكنك فتح عدد جديد؟ شكرا.
إعادة الفتح بسبب الحاجة للعودة # 6010 في # 6749.
أي وقت مقدر للوصول عندما يكون الإصلاح متاحًا؟
انظر # 6888.
sagarkal للتأكد من أننا على نفس الصفحة: الإصلاح المذكور أعلاه يهدف فقط إلى الوصول إلى Helm v3 ، وليس v2 (أعلن هذا كمساهم عشوائي ، والقرار الفعلي متروك دائمًا للفريق). التغيير ضخم نسبيًا ولا ينبغي اعتباره آمنًا بنسبة 100٪ ليتم دمجه في فرع 2.x ، وهو التصحيح فقط الآن. في غضون ذلك ، إذا كانت لديك فرصة ، فسيكون من الرائع أن تتمكن من اختبار فرع العلاقات العامة مقابل حالة الاستخدام الخاصة بك وإعلامنا إذا كانت الأشياء تعمل كما هو متوقع. هذا سيساعد كثيرا!
استخدام --set-string image.tag=6599236
نجح معي في استخدام قالب عادي مثل هذا
...
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
env:
...
يعمل في هذا مع قيمة عددية كبيرة محددة في ملف قيم الرسم البياني. يتم تحويله ضمنيًا إلى عدد عشري مع تدوين علمي. مجرد تحويل القيمة إلى int
أصلح هذا ، ويبدو أنظف بكثير من بعض الحلول الأخرى التي رأيتها:
# values.yaml
tomcat:
maxPostSize: 2097152
# Cast to int when used
{{ .Values.tomcat.maxPostSize | int }}
تم اختبار هذا مع Helm v3.1.1.
من الجيد معرفة! هذا بالتأكيد حل سهل مقارنة بالعديد من الأشياء التي رأيتها. شكرا!
Rathgore يعتبر Casting إلى int مثاليًا عند التعامل مع ints طوال الوقت ولكن في حالتي ، يجب التعامل مع قيمة الإدخال كسلسلة ولكنها تأتي في شكل أرقام (أحيانًا). على سبيل المثال ، يكون تطبيق جيثب ذو 7 أطوال مختصرة ، وأحيانًا يكون عبارة عن سلسلة وأحيانًا يكون مجرد سلسلة من الأرقام. في هذه الحالة ، يتم تمرير القيمة باستخدام الخيار --set-string
كل مرة.
@ m0rganic لم أختبر هذا ، ولكن يمكنك محاولة استخدام toString
بدلاً من int
أو تعيين النوع صراحةً باستخدام !!str
. هذا ليس ضروريًا إذا كنت تستخدم --set-string
فقط ولكننا نحتاج إلى هذا السلوك للقيم المحددة في الرسم البياني أيضًا.
@ m0rganic لم أختبر هذا ، ولكن يمكنك محاولة استخدام
toString
بدلاً منint
أو تعيين النوع صراحةً باستخدام!!str
. هذا ليس ضروريًا إذا كنت تستخدم--set-string
فقط ولكننا نحتاج إلى هذا السلوك للقيم المحددة في الرسم البياني أيضًا.
toString
لا يعمل ، وفي بعض الحالات ، لا يمكنني استخدام !!str
.
هل هناك خطة لإصلاح هذا السلوك؟ ظلت هذه القضية مفتوحة منذ فترة طويلة ...
انظر # 6888. بخلاف ذلك لا. لقد وثقنا العديد من الأنماط لاستخدامها. لكننا لم نعثر على حل يحل مشكلات أكثر مما تسببه. لا تتردد في تجربة يدك في العلاقات العامة.
شكرا على الاستجابة السريعة! لست متأكدًا من أن أيًا من الحلول المقترحة يحل حالة الاستخدام الخاصة بي ، لكنني سأحاول مرة أخرى.
هل تعمل بشكل مختلف إذا قمت بعمل
--set tag=\"1\"
؟
في حالتي ، استخدمت ""
في قيم int و float و bool وقد نجحت ، شكرًا
بناءً على هذا التعليق ، قد يبدو أن هذه لم تعد مشكلة بالنسبة إلى Helm 3 ، فقط لـ Helm 2. أحب أن أسمع من لا يزال يواجه هذه المشكلة وكيف وما هي إصدارات Helm.
بالنسبة لمستخدمي Helm 2 ، نحن نقبل فقط تصحيحات الأمان في هذه المرحلة ، لذلك لن نتطلع إلى إصلاح هذا الخطأ لـ Helm 2. ومع ذلك ، إذا كان هذا لا يزال مناسبًا لـ Helm 3 ، فسأكون ممتنًا لمزيد من المعلومات من المجتمع حول هذا الخطأ بالذات.
بالنسبة إلى helm 2 ، يمكنك الإرسال إلى ما تريد بين () كمثال أدناه
{{- range $i := until (int .Values.deployment.numberofracks) }}
- name: rack{{$i}}
{{- end}}
سأفترض أن هذا قد تم إصلاحه لـ Helm 3 ، حيث مرت 3 أسابيع منذ آخر مرة نشرت فيها أنه يبدو أنه قد تم إصلاحه. إذا كان لا يزال هناك آخرون يواجهون هذه المشكلة مع Helm 3 ، فلا تتردد في مناقشة هذا الأمر ويمكننا إعادة فتح هذه المشكلة. شكرا!
وما زالت هذه المسألة؛ أنا على 3.3.0
وما زلت أعاني من ذلك.
هل يمكنك تقديم مظاهرة من فضلك؟
سعيد بذلك ، لكنني لست متأكدًا تمامًا من كيفية القيام بذلك ؛ لدي مخطط في values.yaml
حقل يبدو كالتالي:
customEnv:
SOME_ENV_VAR: 10000000
ثم في templates/deployment.yaml
، لدي هذا:
...
containers:
- name: someContainer
env:
{{- range $key, $value := .Values.customEnv }}
- name: {{ $key | quote }}
value: {{ $value | quote }}
{{- end }}
...
عندما أقوم بتشغيل helm template
، أحصل على هذه القيمة في الإخراج المعروض:
...
containers:
- name: someContainer
env:
- name: "SOME_ENV"
value: "1e+07"
...
ثم يفشل تطبيقي الذي تم نشره عندما يحاول تحليل قيمة SOME_ENV
كرقم.
تمام. تمكنت من إعادة إنتاج نفس المشكلة باتباع تعليماتك مع Helm 3.3.1. شكرا لك. إعادة الفتح.
أواجه نفس المشكلة لزاوية مختلفة قليلاً. appVersion
هو 8482e77
، إذا أشرت إلى appVersion
أي مكان يتم عرضه كـ +Inf
. هذا هو متعة لتصحيح راجع للشغل.
يحرر:
تغيير appVersion من appVersion: 8482e77
إلى appVersion: "8482e77"
إصلاح مشكلتي
هذا متوقع. غير مقتبس ، يوزع YAML هذه القيمة كتدوين علمي (مثل 8482e77
يعني “8482 * 10 ^ 77”). إذا كنت تريد معاملة قيمة كسلسلة ، فلفها بين علامتي اقتباس.
لدي هذه المشكلة مع علامة الصورة contianer. تمت معالجة المشكلة بإنشاء المساعد أدناه:
+{{/* Generate Image Name */}}
+{{- define "helpers.image" }}
+{{- $tag := printf "%f" .Values.app.image.tag -}}
+{{- if regexMatch "^[0-9]+\\.[0-9]+$" $tag }}
+{{ .Values.image.repository }}:{{ .Values.image.tag | int }}
+{{- else }}
+{{ .Values.image.repository }}:{{ .Values.image.tag }}
+{{- end }}
+{{- end }}
وبعد ذلك ، في بيان النشر:
containers:
- name: {{ template "helpers.fullname" . }}
image: {{ template "helpers.image" . }}
هل تم حل هذه المشكلة؟ إذا لم يكن كذلك ، فأنا أود إصلاح هذا.
رقم انظر أعلاه . يرجى التأكد من قراءة الموضوع واختباره بنفسك. :)
تم وضع علامة على هذه المشكلة على أنها قديمة لأنها كانت مفتوحة لمدة 90 يومًا بدون أي نشاط. سيتم إغلاق هذا الموضوع تلقائيًا في غضون 30 يومًا إذا لم يحدث أي نشاط آخر.
نتوء ، لا تزال مشكلة
أستخدم هذا الحل البديل عندما أواجه هذه المشكلة في معرّفات الالتزام ربما الرقمية:
{{- define "numericSafe" -}}
{{- if . | toString | contains "e+" -}}
{{ . | toString | replace "." "" | regexFind "^\\d+" }}
{{- else -}}
{{ . }}
{{- end -}}
{{- end -}}
ثم استخدم مع
{{ include "numericSafe" .Values.git.commitID }}
إنه يحل المشكلات إذا لم تحتوي سلسلتك الأصلية مطلقًا على نقطة و e+
، على الرغم من أنني لا أعرف ما إذا كانت سلسلة رقمية طويلة جدًا سيتم حذف أي شيء.
urakagi للأسف ، هذا لا يعمل إذا كانت 1800000
هل هناك إصلاح مخطط لهذه المشكلة؟
أي تحديثات؟
bacongobbler ، فإن repro من edobry هي في الواقع مشكلة مختلفة. كان هذا في الأصل حول القيم التي يتم تمريرها باستخدام --set
، والذي تم إصلاحه الآن وتمت إضافة الخيار --set-string
.
إن repro عبارة عن رقم داخل القيم ، يتم تغيير yaml إلى تدوين علمي. يمكن إصلاح repro باقتباس الرقم في values.yaml
، إذا كان يجب معاملته كسلسلة. إذا تم استخدامه كرقم ، فلا ينبغي أن تكون الرموز مشكلة.
نظرت في الكود وأعتقد أنني سأكون قادرًا على تغيير السلوك لإخراج الأرقام في التدوين القياسي بدلاً من 20 رقمًا عشريًا. بعد ذلك يبدو أن هناك حدًا معينًا للتنفيذ في المحلل اللغوي yaml الأساسي الذي يقوم بتقريب أعداد كبيرة جدًا و / أو تحويلها إلى تدوين علمي.
لقد حاولت أيضًا العثور على مشكلة أخرى من شأنها التعامل مع المشكلة كما هو موضح في reproedobry ووجدت # 9162 حيث يبدو أن الحل هو أن هذا هو المقصود حيث يقوم المحلل اللغوي بتحليل القيم كما يراها مناسبة وداخل حدود مواصفات yaml.
لذلك عندما يستخدم شخص ما ، على سبيل المثال ، علامات رقمية ، والتي لا تحتوي على أي قيم عددية (لم يتم تحديد أي حساب عليها) ، يجب أن يتم اقتباسها في values.yaml
ليتم التعامل معها كسلاسل ويجب أن يؤدي ذلك إلى حل المشكلة:
# values.yaml
foo: "10000000"
# template
foo: {{ .Values.foo | quote }}
md5-aba98a385ca8fe457cb1f98967ed3bf1
# Source: foo/templates/x.yaml
foo: "10000000"
md5-265ed31678f08bdbd76c259b974f5398
# Source: foo/templates/x.yaml
foo: "1e+07"
md5-3df6a1bc5fe8f474ded5c2033aaf11a3
# Source: foo/templates/x.yaml
foo: "10000000"
لذلك أعتقد أنه يمكن إغلاق هذا ويمكن فتح قضية جديدة إذا اعتقد شخص ما أن تحليل الأرقام غير المسعرة يجب أن يتبع بعض القواعد الأخرى غير المتبعة بالفعل.
التعليق الأكثر فائدة
التوافق الوراء؟ من الميزات التي هي مجرد "WTF" ومن المحتمل ألا يريدها الكثيرون أو يستخدمونها؟ في أداة تخضع لتطوير كبير ولا يتم تبنيها على نطاق واسع؟ أقترح إعادة التفكير في ذلك وإصلاحه قبل فوات الأوان.