Helm: توفير وسيلة لإعداد .Chart.AppVersion أثناء التثبيت أو الترقية دون تحرير Chart.yaml

للتوضيح ، تم إغلاق # 3555 بواسطة OP (راجع https://github.com/helm/helm/issues/3555#issuecomment-633187773) بالتعليق التالي:

"يبدو أن الكثير من الأشخاص هنا يطلبون طريقة لتجاوز حقل" appVersion ". الهدف / الطلب الأصلي في هذه المشكلة هو السماح بـ" إصدار التطبيق كبديل لـ "الإصدار ، بحيث يمكن للمستخدم تشغيله" helm fetch —app-version = v0.15.0 'و Helm سيعملان على تحديد أحدث إصدار من المخطط v0.15.0 باعتباره appVersion وجلب ذلك.

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

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

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

أعتقد أيضًا أن هذا النوع من الوظائف يمكن ، وربما يكون الأفضل ، أن يتم تنفيذه كأداة خارجية أو غلاف حوله
Helm ، خاصة عند الأخذ في الاعتبار تغييرات OCI التي أعتقد أنها ستجعل تنفيذ هذا الأمر أكثر صعوبة ".

إنه قبيح ولكنه يعمل ، لكنني سأحب علمًا مدمجًا في دفة القيادة

sed -i "s/^version:.*$/version: $(git describe)/" chart/Chart.yaml
sed -i "s/^appVersion:.*$/appVersion: $(git describe)/" chart/Chart.yaml
helm upgrade app ./chart

أتمنى أن يكون مثل ....

helm upgrade --version "$(git describe)" --app-version "$(git describe)" app ./chart

loa اقتراحك لا يتبع ما يلي من العنوان (وهو

بدون تحرير Chart.yaml

timothyclarke أردت فقط توضيح حالة الاستخدام.

حاليًا بدون إمكانية تغيير appVersion عند الترقية ، تكون نتيجة helm history هي:

REVISION    UPDATED                     STATUS      CHART           APP VERSION DESCRIPTION
1           Mon Jun  8 11:39:51 2020    superseded  spring-1.0.0    1.0.0       Install complete
2           Mon Jun  8 12:19:21 2020    superseded  spring-1.0.0    1.0.0       Upgrade complete
3           Mon Jun  8 12:20:51 2020    deployed    spring-1.0.0    1.0.0       Upgrade complete

تشغيل مثالي

helm upgrade --wait --app-version "$MY_AWESOME_VERSION" app ./chart

ينتج Wold عن helm history سهل الاستخدام ، مثل الموجود أدناه. هذا يدل على أن الرسم البياني لم يتغير ولكن التطبيق كان له إصدارات جديدة.

REVISION    UPDATED                     STATUS      CHART           APP VERSION DESCRIPTION
1           Mon Jun  8 11:39:51 2020    superseded  spring-1.0.0    1.0.1       Install complete
2           Mon Jun  8 12:19:21 2020    superseded  spring-1.0.0    1.0.2       Upgrade complete
3           Mon Jun  8 12:20:51 2020    deployed    spring-1.0.0    1.0.3       Upgrade complete

هل تتناسب حافظة الاستخدام هذه مع عملية الدفة؟

من الناحية المثالية ، هل سيكون إصدار التطبيق المقدم عبر سطر الأوامر متاحًا أيضًا في القوالب ( $.AppVersion )؟

سيسمح ذلك بإضافته إلى البيانات الوصفية لتكوين kubernetes.

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

1. إصدار المخطط: يمثل _source_ للقالب ؛
   
   
   
   • إذا تغير مصدر النموذج ، يجب تغيير إصدار المخطط ؛ مصدر النموذج يعني مجلد القوالب ، و Chart.yaml ، والقيم الافتراضية. yaml ، و helmignore ، والملاحظات ، إلخ.
   
   
   • لا أقوم بتخزين مخطط الدفة في إعادة شراء المخططات لأن المخطط متاح من git في أي وقت ويمكن تثبيته عبر تثبيت helm
   
   
2. إصدار التثبيت: قيمة فريدة تستند إلى مجموعة جميع القيم المستخدمة عند التثبيت ، أي بعد دمج جميع ملفات القيم (بما في ذلك الملفات السرية التي تم فك تشفيرها) والقيم الافتراضية للمجموعة والقيم الافتراضية. أحدد ذلك عبر MD5 أو SHA256 بناءً على مجموعة القيم النهائية.

نظرًا لأن helm ليس لديه مفهوم إصدار التثبيت ، فأنا أستخدم إصدار التطبيق لعقد md5.

هذا يجعل من تفسير ما تم تثبيته:

REVISION    UPDATED                     STATUS      CHART           APP VERSION      DESCRIPTION
1           Mon Jun  8 11:39:51 2020    superseded  spring-1.0.0    3efe0e3...       Install complete
2           Mon Jun  8 12:19:21 2020    superseded  spring-1.0.0    ie21b02...       Upgrade complete
3           Mon Jun  8 12:20:51 2020    superseded  spring-1.0.0    3efe0e3...       Upgrade complete
4           Mon Jun  8 12:20:51 2020    deployed    spring-1.1.0    123abcd...       Upgrade complete

من الواضح الآن أن المراجعين 1 و 3 هما نفس التثبيت بالضبط: نفس مصدر الرسم البياني ونفس شجرة القيم النهائية.

إذا كان أي شخص مهتمًا بتجربة ذلك ، فإن https://github.com/schollii/sandals/blob/master/helm.py يوفر وظيفتين مفيدتين لهذا الغرض. أحصل حاليًا على التجزئة عبر التشغيل الجاف للحصول على القيم المدمجة ، ولا بد لي من نسخ الرسم البياني إلى مجلد مؤقت لتعديل إصدار التطبيق في Chart.yaml (أو استخدم حل التغليف ، لأنه يدعم إصدار app-version ). لذا فإن --app-version للتثبيت سيكون رائعًا. أود أيضًا تنفيذ شيء مثل --app-version-is-md5 مما يجعل التشغيل الجاف غير ضروري ، لكن هذا سيكون في مشكلة أخرى (# 8453).

أستخدم هذا قبل كل تثبيت عندما لا أستخدم علامة git yq w -i k8s/$CI_PROJECT_NAME/Chart.yaml appVersion "$CI_COMMIT_SHORT_SHA"

عندما أستخدم علامة ، أقوم بترقية المراجعة في عملية ci التي أستخدمها قبل كل تثبيت yq w -i k8s/$CI_PROJECT_NAME/Chart.yaml appVersion "$CI_COMMIT_TAG"
ثم قم بإلزام Chart.yaml المحدث بالتحكم في الإصدار.

باستخدام gitlab ci

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

woodcockjosh ، لست متأكدًا من أن هذه المشكلة تتعلق بإصدار المخطط ، ولكن المزيد من إصدار التطبيق القابل للقراءة البشرية (appVersion) الذي تم نشره باستخدام المخطط.

أود أن أقول إن حالة الاستخدام الأساسية للميزة هي منح مصممي المخططات ومسؤولي الخادم والمطورين القدرة على:

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

من خلال تغطية حالتي الاستخدام المذكورتين أعلاه ، المنظمة البحرية الدولية (IMO) ، فإنها ستسمح للدفة بالبقاء غير عاقدة الرأي حول كيفية تنفيذ واستخدام مخططات الدفة.

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

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

rcampbel نعم بالطبع نريد أن نرى إصدار التطبيق المثبت. لكن ما أقوله هو أن الظروف التي ترغب في ظلها في الحصول على إصدار مختلف لـ appVersion عن الإصدار الموجود في Chart.yaml هو ما إذا كان هذا المخطط ملكًا لك وأنت تقوم بنشر إصدار مستوى التطوير من تطبيق. إذا لم يكن إصدار مستوى التطوير ، فيمكنك الاحتفاظ برقم إصدار التطبيق داخل Chart.yaml وجعل المستخدمين النهائيين للمخطط يستخدمون إصدار التطبيق هذا كإصدار افتراضي للتطبيق.

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

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

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

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

مما يمكنني قوله ، فإن هيلم ليس لديه رأي بالفعل في هذا الأمر ، نظرًا لأنه يمتلك الوسائل للقيام بذلك بالضبط عند الاتصال بـ helm upgrade

يمكن أن تكون وسيطة المخطط إما: مرجع مخطط ('example / mariadb') أو مسار إلى دليل مخطط أو مخطط معبأ أو عنوان URL مؤهل بالكامل. ~ https://helm.sh/docs/helm/helm_upgrade/

woodcockjosh هناك العديد من حالات الاستخدام وكما تنص rcampbel على بطرقهم الخاصة.
إذا اتبعت منطق "يجب أن يتم نشره في الرسم البياني" (إلى أقصى حد) ، فلماذا يكون هناك علامة --set أو --values ، -f ، ولهذا السبب ملف values.yaml على الإطلاق؟ كل ما يتم توفيره بواسطة العلامات عبارة عن تجاوزات لوقت النشر يجب أن تكون في المخطط المنشور. أعلم أنه من السيئ وضع الأسرار في مخطط ، ولكن إذا كان هذا هو السبب الوحيد ، فيجب أن تكون الوسيطة --secrets بدلاً من --values .

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

نظرًا لأن .Chart.appVersion لا يعمل بالنسبة لنا ، فقد عدنا إلى .Chart.appVersion الثابت ونستخدم .Values.image.tag (هذه ليست دعوة لإعادة فتح هذا النقاش)

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

بالنسبة لمستخدمي حزمة الرسم البياني ، من الأسهل رفع image.tag ، فهذا يعني تعديل القيم فقط ، وقد يعيش المخطط في مكان آخر. لكن باستخدام image.tag لن تحصل على معلومات حول إصدار الحزمة عند القيام بـ helm history <release>

لقد لاحظت أيضًا أن helm package <chart> سينشئ ملف tar مع Chart.version . إذا كنت ترغب فقط في توزيع إصدار جديد من تطبيقك ، وتم استخدام appVersion ، فمن المتوقع أن تصطدم بـ version أيضًا ، وإلا فستستبدل الملف السابق. إذا كان appVersion و version مختلفين ، فسيكون من الصعب حساب نتوء semver الصحيح باستخدام الأدوات التلقائية لـ version (لنفترض أن appVersion تم ارتطامه بناءً على رسائل الالتزام ). كيف تتعاملون معها؟

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

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

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

أفضل عدم استخدام "sed" كما هو مذكور في 8194
حتى يتم حل هذا (أو لا) إليك كيفية حل هذا في CI / CD (GitLab):

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

أيضًا ليست هناك حاجة للتحميل إلى مستودع إدارة ، ولكن من الممكن استخدام عناصر CI الناتجة (chart.tgz)

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

deploy:
  image: alpine/helm:3.2.4
  stage: deploy
  environment:
    name: ${ENV}
  script:
    - helm package --app-version=${CI_COMMIT_TAG} --version=${CI_COMMIT_TAG} ${NAMESPACE}
    -  | 
       helm upgrade -i --wait ${CI_PROJECT_NAME} ./${NAMESPACE}-${CI_COMMIT_TAG}.tgz \
       --set image.repository="${CI_REGISTRY_IMAGE}" \
       --set image.tag="${CI_COMMIT_TAG}" 
    - helm history ${CI_PROJECT_NAME} -n ${NAMESPACE}
  tags:
    - kubernetes
  only:
    - tags

في الإخراج لدي الآن الإصدارات المتاحة.

 $ helm history ${CI_PROJECT_NAME} -n ${NAMESPACE}
 REVISION   UPDATED                     STATUS      CHART       APP VERSION DESCRIPTION                                                                                                         
 45         Sun Aug  9 15:40:42 2020    superseded  prd-0.1.0   1.16.0      Upgrade complete                                                     
 46         Mon Aug 10 11:38:56 2020    superseded  prd-v0.2.25 v0.2.25     Upgrade complete                                                     
 47         Mon Aug 10 11:55:41 2020    deployed    prd-v0.2.26 v0.2.26     Upgrade complete                                                     
 Job succeeded

haimari
شكرًا على المقتطف ، لأي شخص يبحث عن مثال آخر سابقًا في هذا المداس https://github.com/helm/helm/issues/8194#issuecomment -635879040 الذي يحقق نفس النتيجة.

ومع ذلك ، فإن هذه المشكلة المطروحة هي أن إعادة تغليف الرسم البياني أمر غير مرغوب فيه وأن المشرفين على القيادة يفرضون هذا الرأي وطريقة العمل. هذا الطلب هو أن تكون الدفة أقل إبداءً للرأي والسماح باستخدام الدفة بطريقة تناسب الأجزاء الأخرى من المجتمع بشكل أفضل.
استكشفت هذه المشكلة و https://github.com/helm/helm/issues/3555 الاختلافات بين .Chart.version و .Chart.appVersion ، وتحديداً كيف ترتبط معظم الرسوم البيانية العامة appVersion بـ علامة الحاوية التي أجبرت إصدار المخطط على التغيير لمجرد وجود إصدار جديد من التطبيق تم إصداره. في حين أن هذا قد يكون افتراضًا جيدًا لمعظم الرسوم البيانية العامة ، إلا أن الافتراض غير صالح لعدد كبير من الرسوم البيانية الخاصة. ومن هنا جاء هذا الطلب إلى المشرفين على القيادة بالتوقف عن فرض هذا النهج على المجتمع.

ملاحظة يتضمن مقتطف الشفرة إصدار مخطط لكل إصدار / لكل بيئة والذي من شأنه أن يحل محل الحاجة إلى إعداد image.repository و image.tag . أتوقع خطوة بعد إعادة التعبئة لنشر الرسم البياني إلى مستودع إدارة في حال احتجت إلى إعادة النشر ، راجع https://github.com/helm/helm/issues/8194#issuecomment -658715462 أعلاه الذي يستكشف هذا الأرنب الفجوة

haimari
شكرًا على المقتطف ، لأي شخص يبحث هناك مثال آخر سابقًا في هذا المداس # 8194 (تعليق) يحقق نفس النتيجة.

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

ملاحظة يتضمن مقتطف الشفرة إصدار مخطط لكل إصدار / لكل بيئة والذي من شأنه أن يحل محل الحاجة إلى إعداد image.repository و image.tag . أتوقع خطوة بعد إعادة التعبئة لنشر الرسم البياني إلى إعادة توزيع الدفة في حال احتجت إلى إعادة النشر ، انظر # 8194 (تعليق) أعلاه والذي يستكشف حفرة الأرنب تلك

timothyclarke شكرا لك على المعلومات.

1. هذه ليست أفضل ممارسة ولكنها حل بديل لـ _ "توفير وسيلة لإعداد .Chart.AppVersion أثناء التثبيت أو الترقية دون تحرير Chart.yaml" _
2. ليست هناك حاجة لدفع الرسم البياني إلى مستودع ، هذا يعمل مع مجموعات k8s المتعددة مباشرة من Gitlab.
3. يوفر كل ما أحتاجه من أجل الحصول على إصدارات:

تم تعيين image.repository & image.tag على أي حال بنفس الطريقة تمامًا في خط الأنابيب ،
لذلك حتى بدون خط التغليف ، هذه هي الطريقة لاستخدام helm من gitlab.

يحتوي المتغير CI_COMMIT_TAG على علامة الإصدار الحالي لخط الأنابيب الذي يعمل.
لذلك يمكننا دائمًا الرجوع إلى الإصدار السابق مباشرةً من خط أنابيب CI بنقرة واحدة.

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

يعد عدم وجود خيار تعيين appVersion (وبالتالي تعيينه دائمًا على نفس القيمة) أثناء التثبيت نقصًا كبيرًا في عملية النشر لدينا. إنه أمر مزعج حقًا أن مستخدمينا لا يمكنهم رؤية إصدارات التطبيق من خلال إجراء "قائمة الدفة"

إن امتلاك القدرة على استخدام شيء مثل "helm install ... --app-version v1.2.3" سيضيف الكثير من القيمة لاستخدام Helm في حالتنا.

اقتراحي هو إهمال appVersion وإدراج chart version و container tag عند تنفيذ helm list أو helm history <name> .
لا ينبغي أن تحاول Helm تقديم إصدار التطبيق الفعلي داخل الحاوية ، بل يجب أن تقدم ما هو موجود ، والعلامة وإصدار المخطط ، وإليك بعض الأمثلة:

| مخطط | علامة حاوية |
| ----- | ----- |
| 0.1.0 | 0.3.0 |
| 0.1.0 | 0.4.0 |

في المثال أعلاه يمكننا أن نستنتج أن المخطط يُعاد استخدامه لعلامات مختلفة

| مخطط | علامة حاوية |
| ----- | ----- |
| 0.3.0 | 0.3.0 |
| 0.4.0 | 0.4.0 |

في المثال أعلاه يمكننا أن نستنتج أن الرسم البياني يشترك في نفس إصدار العلامة.

يبدو أن الجانب السلبي الرئيسي لـ appVersion هو أنه يتطلب إعادة نشر الحزمة ، حتى لو لم يتغير الرسم البياني ، لكن الكود الموجود داخل الحاوية قد تغير. في غضون ذلك ، يمكن تقديم علامة الحاوية من خلال values.yaml ولا تحتاج إلى إعادة نشرها.

البدائل

أبسط ما أعتقد أنه سيكون سرد علامة الحاوية عند القيام بـ helm list أو helm history ، لكن سيكون من الغريب أن يكون لديك appVersion يتسكع. هذا على الأقل ، سيعطي بعض المعلومات الإضافية ، ويمكن للأشخاص تجاهل appVersion .

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

أفكار؟

Woile ماذا لو كان التطبيق الخاص بك يحتوي على أكثر من حاوية واحدة؟

Woile ماذا لو كان التطبيق الخاص بك يحتوي على أكثر من حاوية واحدة؟

أنت محق ، بالنظر إلى حالة الاستخدام هذه أيضًا (آسف لأنني كنت أفكر في حالات الاستخدام الخاصة بي) ، أعتقد أن نقل appVersion إلى values.yaml سيحسن الموقف.

• يمكن أن يظل helm list و helm history هو
• يمكن أن يكون لديك أكثر من حاوية واحدة
• لا تحتاج إلى إعادة النشر في كل مرة ، ولكن يمكنك إذا أردت الاحتفاظ بمزامنة Chart و appVersion .

ماذا ينقصني؟

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

تضمين التغريدة
بلدي 0.02 دولار. مفهوم appVersion مفهوم جيد من وجهة نظر helm ls . التنفيذ هو المشكلة التي أود أن أراها مصححة. يجب أن يكون وجود العديد من العلامات / الإصدارات في appVersion أمرًا جيدًا ، على سبيل المثال appVersion: nginx-1.16.0-php-7.5

ألاحظ أن helm 3.2.4 به {{ .Values.image.tag | default .Chart.AppVersion }} لذلك يسمح بهذا النوع من قطع الاتصال

ستكون القدرة على تحديد appVersion أثناء التثبيت / الترقية هي الطريقة الأكثر تفضيلاً. ليس من المنطقي أن تصطدم بإصدار المخطط في كل مرة يتغير فيها appVersion لأن المخطط نفسه لا يتغير. لا يكون التقدم الخطي للإصدار دائمًا قابلاً للتطبيق دائمًا - خاصة بالنسبة لتطبيقات الحاويات المتعددة التي يتم نشرها في بيئات مختلفة مع مجموعات مختلفة من إصدارات الحاوية. اقتراح استخدام نفس appVersion و chartVersion سيء أيضًا لأن ذلك يفرض على appVersion أن يكون متوافقًا مع semVer. لا يعتبر semVer الكأس المقدسة لتعيين الإصدار ويجب أن يكون appVersion مجانيًا لاستخدام أي نظام إصدار يكون أكثر ملاءمة للتطبيق.

bacongobbler هل يعني هذا التعليق أن الدفة تخطط لتنفيذ مثل هذا العلم؟

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

• الهدف من helm (المخطط) هو تجميع الموارد وتثبيتها في مجموعة kubernetes (لتطبيق ما).
• يمكن توفير إصدار التطبيق فقط في مرحلة الحزمة ، لذلك تصبح هذه المعلومات جزءًا من المخطط.
• يتم تخزين المخطط في مستودع الدفة (مثل قطعة أثرية جافا أو بيثون) يصبح غير قابل للتغيير. لذلك لا ينبغي أبدًا تجاوز إصدار التطبيق.
• على الجانب الآخر أثناء مرحلة التثبيت أو الترقية ، تسمح القيم بتجاوز أي قيم من المخطط (لتخصيصات البيئة) ولكن لا يمكن لتطبيق appVersion.
• كما نرى في العديد من حالات الاستخدام ، فإن الإصدار الحقيقي من التطبيق هو نسخة الصورة التي يوفرها image.tag أثناء مرحلة التثبيت أو الترقية.

استنتاجي

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

خياري الحالي

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

سؤال / فكرة

لا أعرف سبب تقديم إصدار التطبيق (ربما لتغطية الاستخدام السيئ للمخطط المشترك).
أعتقد أنه قد يكون من الجيد إزالته وإدخال القدرة على تعيين علامة الصورة في مرحلة الحزمة دون استخدام حل بديل مثل sed أو yq.

ربما منشور طويل جدًا ولكني أحتاج إلى بعض التعليقات

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

في الحالة المذكورة أعلاه ، أين تقوم بتخزين الأسرار أو المعلومات الحساسة المماثلة؟ في كل مكان عملت فيه ، تم إطعامهم عبر ملف --values

بالنسبة لبعض السياق ، تشتمل عمليات النشر الخاصة بي على 3 عناصر تم إصدارها بشكل مستقل

• جدول
• طلب
• (البيئة) تكوين قيم

إذا قمت بتغيير أحد هؤلاء ، فلن أجبر على إعادة بناء أي من الآخرين. عادةً ما أستخدم بيئات متعددة حتى يمكن اختبار التطبيقات قبل أن تصبح حية. على هذا النحو ، قد يكون النشر مثل chart-v1.0 application_build-50 config_non-prod-v1.3 مع تشفير ملفات env config المخزنة في gpg.
تقوم منصة My CI بإدارة إنشاء التطبيق ونشره وترقيته مع تدفق البناء من المصدر إلى الاختبار إلى الإنتاج. إذا احتجنا إلى إعادة نشر إصدار تاريخي من التطبيق ، فإننا نعيد تشغيل هذه الوظائف.

السؤال: لماذا يجب أن نضطر إلى استخدام مستودع الرسم البياني لتخزين الحالة التي تتعامل معها منصة CI الخاصة بي خارج الصندوق؟ يجب ألا نقوم أبدًا بتثبيت أي من هذا يدويًا

timothyclarke فقط تأكد من استخدام المكون الإضافي

timothyclarke مرحبًا ، شكرًا على هذه التعليقات الأولى ؛)

• ميزة المستودع (مثل ، pypi ، وسجلات Maven المركزية ، وسجلات Docker من أجل التنمية) هي أنه يمكن مشاركة الأداة المُنشأة ونشرها (بالنسبة للدفة ، فهي tgz) مع ضمان أنه غير قابل للتغيير.
• بالنسبة للقيم حسب البيئة (إنه موضوع آخر) ، يمكن تخزينها في المكان الذي تريده (scm repo ، حل مخصص مثل hashicorp للأسرار ، illumio لـ netpol ، إلخ ...).

يوفر المخطط القيم الافتراضية. yaml (غير قابلة للتغيير لكل إصدار مخطط) يمكن استخدامها (أو تجاوزها) بواسطة مستهلكي المخطط.
بالنسبة إلى Chart.yaml ، فهو أيضًا جزء ثابت من المخطط ... ويتم تضمين app-version .

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

تضمين التغريدة

يوفر المخطط القيم الافتراضية. yaml (غير قابلة للتغيير لكل إصدار مخطط) يمكن استخدامها (أو تجاوزها) بواسطة مستهلكي المخطط.
بالنسبة إلى Chart.yaml ، فهو أيضًا جزء غير قابل للتغيير من المخطط ... ويتم تضمين إصدار التطبيق فيه.

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

أعتقد أن هذا يتعارض أيضًا مع ما هو مطلوب ، "توفير وسيلة لإعداد .Chart.AppVersion أثناء التثبيت أو الترقية بدون تحرير Chart.yaml" أعتقد أن ما قاله timothyclarke سابقًا في هذه الدردشة يلخص الأشياء https: / /github.com/helm/helm/issues/8194#issuecomment -671331311

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

نفس المشكلة هنا!
النظر في استخدام العلامة --description كحل بديل لتوفير طريقة ما لإظهار إصدار التطبيق في helm list 🤔

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

ربما تكون المشكلة الرئيسية أن النوع في Chart.yaml ليس دقيقًا بدرجة كافية؟ لا توجد وسيلة للتمييز بين مخطط مظلة أو مشترك أو تطبيق

grazius هذا
في حين أنه قد يكون قابلاً للتطبيق على العديد من المشاريع مفتوحة المصدر ، إلا أنه لا ينطبق على العديد من إصدارات المصادر المغلقة. يرجى إعادة مراجعة هذا الموضوع بما في ذلك جميع البيانات المختلفة وحالات الاستخدام التي تم إجراؤها لأن هذا الطلب ليس طلبًا لإزالة .Chart.AppVersion من مواصفات الرسم البياني. إنه ليس طلبًا لإخفاء APP VERSION من ناتج helm ls .
هذا الخيط هو طلب لجعل Chart.AppVersion قابلًا للتكوين في وقت استخدام الرسم البياني (دون الحاجة إلى إعادة إنشاء المخطط أو تغييره بطريقة أخرى) بحيث يكون الحقل APP VERSION helm ls ليس مضللا.

كما هو الحال ، سأجادل حاليًا بأن APP VERSION هو حقل غير ضروري في helm ls ويجب ألا يكون مرئيًا لأوامر وقت التشغيل نظرًا لمدى ارتباط .Chart.AppVersion بـ .Chart.Version . helm inspect chart --version <.Chart.Version> <.Chart.Name> نفس المعلومات.
سأقوم أيضًا بتوسيع ذلك ليشمل استخدام .Chart.AppVersion لاستخدامه كعلامة الحاوية لأنها كلها أشياء مختلفة قليلاً يمكن إصدارها بشكل مستقل لأسباب وجيهة ، ولكن يتم دمجها حاليًا في شيء واحد.
لقد حاولت الاحتفاظ بآرائي حول هذا الارتباط خارج هذا الطلب حيث يمكن أن يكون للمشاريع أسباب وجيهة تمامًا لمثل هذا الارتباط. من خلال عدم فرض نفس العملية على كل من يستخدم الدفة ، فإننا نجعل الدفة أداة أفضل وأكثر شمولاً.
لا أعتقد أن هذه التغييرات المطلوبة تقلل من دفة القيادة أو تفرض استخدامها على الآخرين.

bacongobbler هل يمكنك التعليق على هذا؟ إنها ميزة مطلوبة للغاية

إنها ميزة مطلوبة للغاية

مرحبًا ، jasondamour - شكرًا على اهتمامك! خياران جيدان: إنشاء ملحق helm ، وكتابة HIP .

مرحبًا ، ربما يكون الحل الأفضل هو توفير وسيطة إصدار تطبيق-إصدار لأمر التثبيت / الترقية التي إذا كانت موجودة تتجاوز عرض إصدار التطبيق عندما نقوم بعمل قائمة قيادة.؟