Helm: لا يقوم "helm Upgrade --install" بإجراء تثبيت / ترقية إذا فشل التثبيت الأول على الإطلاق

كان هذا مقصودًا من خلال تصميم https://github.com/kubernetes/helm/pull/3097. في الأساس ، تسبب الاختلاف ضد النشر الفاشل في حدوث سلوك غير مرغوب فيه ، وعلى الأخص هذه القائمة الطويلة من الأخطاء:

• https://github.com/kubernetes/helm/issues/2257
• https://github.com/kubernetes/helm/issues/2341
• https://github.com/kubernetes/helm/issues/2346
• https://github.com/kubernetes/helm/issues/2437
• https://github.com/kubernetes/helm/issues/3068

إذا انتهى إصدارك الأولي بحالة فاشلة ، نوصي بإزالة الإصدار عن طريق helm delete --purge foo والمحاولة مرة أخرى. بعد الإصدار الأولي الناجح ، سيتم تجاهل أي إصدارات لاحقة فاشلة ، وستقوم الدفة بمقارنة آخر إصدار ناجح معروف.

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

يبدو الإصلاح المقترح غير مقبول تمامًا في نظام آلي. أنا بالتأكيد لا أريد أن يعرف كل شيء يستدعي الدفة "إذا فشل الإصدار الأول ، احذفه وأعد المحاولة". على سبيل المثال ، لا تدرك معظم الأدوات الخاصة بي ما إذا كان تثبيتًا أم ترقية أم لا ، أم أنها المرة الأولى أم المائة ، فغالبًا ما يتم تشغيلها فقط helm upgrade --install .

أود أيضًا أن أوضح أنني علقت على العلاقات العامة الأصلية https://github.com/kubernetes/helm/pull/3097#discussion_r151808599 تسأل على وجه التحديد عن هذه الحالة.

كان السلوك القديم أفضل بالنسبة لهذه الحالة.
أتفق مع @ chancez. هذا يجعل upgrade --install غير معتاد على الحدوث الشائع.

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

ما هي حالات الحافة الأخرى التي نشعر بالقلق بشأنها؟
يبدو أن # 3097 يعتني كثيرًا 👍

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

قد يكون هذا مماثلاً لعلامة --replace لـ helm install . لاحظ أن --replace هو أحد علامتين فقط من helm install مفقودة في helm upgrade ، والآخر هو --name-template .

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

مرحبا،
لقد قمت بإنشاء علاقات عامة https://github.com/kubernetes/helm/pull/3437 والتي من شأنها إصلاح هذه المشكلة

لست متأكدًا من سبب حاجتنا للأوامر install و upgrade ، فأنا أستخدم الأمر upgrade --install ويبدو أن الكثير من الناس يفعلون الشيء نفسه. أنا فقط بحاجة إلى أمر واحد يقوم بعمل upgrade --install ولا يتنقل عبر تشغيل فاشل. هل يمكننا فقط إعادة تسمية upgrade --install إلى deploy ، وجعله غير فعال حقًا ، والتخلي عن الاثنين الآخرين؟

(أعاني من متغير جديد هذا السلوك المشكل في 2.8.0. منذ الترقية من 2.7.2 الآن إذا كان لدي تثبيت فاشل ، ثم delete --purge ، ثم upgrade --install ذلك ، لا يزال بإمكاني الحصول على الخطأ Error: UPGRADE FAILED: "xyz" has no deployed releases . يبدو أن --purge ليس ساريًا بالكامل في 2.8.0 وأن الحارث لديه حالة توقف لا تظهر في list --all . ثم إلى install لإعادة الحراثة إلى حالة حيث يمكنني أن أفعل المعتاد upgrade --install مرة أخرى.)

أتفق مع whereisaaron ، سأكون لطيفًا مع الأمر deploy الذي يعمل أكثر مثل kubectl apply . يجعل أتمتة Helm أسهل بكثير أيضًا ، نظرًا لأنك لست مضطرًا للتحقق من الإصدارات الموجودة في بعض البرامج النصية الجنونية :)

ربما يكون الحل هو تشغيل الدفة تلقائيًا helm delete --purge ؟
شيء مثل:
1) ينفذ المستخدم helm upgrade --install
2) فشل الإصدار الأول
3) يقوم المستخدم ببعض التغييرات على الرسم البياني وينفذ مرة أخرى helm upgrade --install
4) يحاول Helm تشغيل الأمر
5) فشل وهناك إطلاق سراح سابق واحد على وجه التحديد في حالة فشل
6) ينفذ Helm بصمت helm delete --purge
6) بعد التطهير ، يعيد Helm تلقائيًا محاولة helm upgrade --install ويظهر الناتج من ذلك

ربما يمكن تشغيل هذا السلوك من خلال علامة --force التي لديها بالفعل سلوك مشابه لسيناريوهات أخرى

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

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

rchernobelskiy يحدث لي أيضًا. بالضبط كما تصف.

واجهت هذه المشكلة ربما مرة واحدة يوميًا عند نشر تطبيقات جديدة.
انها الألم!

gmanolache ما زلنا على الدفة 2.7.0 لهذا السبب.
لم يتضح لي ما إذا كانت الترقية لاستخدام علامة --force آمنة أم لا: التعليق

إذا كنت بحاجة إلى الرجوع إلى إصدار أقدم ، فإليك طريقة جيدة للقيام بذلك: الرجوع إلى الإصدار 2.7.0

ما هذه المعلومات التشخيصية المفيدة "لدفتر الأستاذ" السبر وكيف يمكننا الوصول إليها؟ :ابتسامة:

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

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

هل سيكون من المعقول أن يكون لديك خيار "- التراجع التلقائي" لمواقف CI ، على سبيل المثال "الترقية - التثبيت - التراجع التلقائي". أنا أفضل عادة التراجع عن الفراش للتعامل مع حالة فاشلة 😆 💤

ما هذه المعلومات التشخيصية المفيدة "لدفتر الأستاذ" السبر وكيف يمكننا الوصول إليها؟ 😄

helm help history

شكرا @ bacongobbler. حسنًا ، أفهم أن هذه القائمة هي المقصود بدفتر الأستاذ. وإذا كان لا يزال لديك دفتر الأستاذ ، فيمكنك استخدام helm get manifest --revision 123 لمعرفة ما تم نشره والذي فشل؟ من المؤكد أن الحفاظ على هذا مفيد. وإذا كنا rollback فلن نفقد تلك المعلومات.

History prints historical revisions for a given release.

A default maximum of 256 revisions will be returned. Setting '--max'
configures the maximum length of the revision list returned.

The historical release set is printed as a formatted table, e.g:

    $ helm history angry-bird --max=4
    REVISION   UPDATED                      STATUS           CHART        DESCRIPTION
    1           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Initial install
    2           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Upgraded successfully
    3           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Rolled back to 2
    4           Mon Oct 3 10:15:13 2016     DEPLOYED        alpine-0.1.0  Upgraded successfully

إذا كان لدينا helm upgrade --install --auto-rollback فسيتم تسجيل كل من النشر الفاشل والتراجع في دفتر الأستاذ وسيكون متاحًا للمشغلين. وهذا من شأنه أن يقطع شوطًا طويلاً لمنع عمليات نشر CI من الوصول إلى الحالة "الفاشلة" المستعصية حيث تتوقف "ترقية الدفة - التثبيت" عن العمل. عمليات نشر CI الفاشلة عادةً ما يقوم المطورون بحقن أخطاء إملائية / أخطاء في نظام النشر. باستخدام "--auto-rollback" ، يمكنهم فحص رسالة خطأ الأمر helm المحفوظة في سجل خادم النشر ، وإصلاح القيم المصححة ونشرها.

أعتقد أنه حتى بدون خيار "- auto-rollback" يمكننا استخدام غلاف آلي لتشغيل helm rollback أي وقت يعرض helm update --install خطأ "FAILED". وربما تكتشف مكان التثبيت الأولي ، و helm delete --purge بدلاً من ذلك في تلك الحالات.

وهذا يعني أنه يمكننا تصميم برنامج نصي مُغلف لضمان أن نتائج CI 'helm Upgrade --install' هي دائمًا حالة يكون فيها CI التالي 'helm Upgrade --install' ممكنًا دائمًا. مع الاحتفاظ بمعلومات دفتر الأستاذ لأي محاولات فاشلة (على الأقل للإصدارات التي نجح تثبيتها الأولية).

helm deploy =

• helm upgrade --install
• إذا فشل بعد ذلك
  
  
  
  • إذا كانت المراجعة = 1
  
  
  • ثم helm delete --purge
  
  
  • آخر helm rollback
  
  

Whereisaaron من شأنها أن تكون أنيقة 👍

هل هناك طريقة سهلة للحصول على أحدث إصدار عمل بخلاف شيء مثل helm history ${name} | tail -2 | head -1 | awk '{print $1}' ، ليتم استخدامه بواسطة helm rollback ؟

أهلا بك،

أنا أستخدم Helm 2.12.2 وما زلت أواجه المشكلة ، فشل هذا الدفة ، عند فشل النشر الأول. هل هذا تراجع ربما؟

لست متأكدًا من أنه انحدار ، لكن لم يتم "إصلاحه" مطلقًا.

@ RickS-C137 أعتقد أنه من المفترض أن يتم إصلاح هذا باستخدام helm upgrade --install --force والذي سوف "يحذف" ثم "تثبيت - استبدال" الإصدار الفاشل.

ما زلت أحاول إصلاح هذه المشكلة في Jenkins Pipeline الذي أحاول استخدامه.
أحاول نشر صورة جديدة من تطبيقي ولا يهمني ما إذا كان النشر موجودًا بالفعل أم لا.
أريد تشغيل أمر واحد إما أن يحل محل النشر الحالي أو يثبته فقط إذا لم يكن موجودًا.
لقد جربت helm install --replace غالبًا ما أحصل على Error: a released named xyz is in use, cannot re-use a name that is still in use والذي من الواضح أنه يقتل خط الأنابيب الخاص بي ويفشل البناء.

bacongobbler ما رأيك في https://github.com/helm/helm/issues/3353#issuecomment -385222233؟

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

لقد نفذت هذا في بنائنا:

if helm history --max 1 "$name" 2>/dev/null | grep FAILED | cut -f1 | grep -q 1; then
    helm delete --purge "$name"
fi

helm upgrade --install --wait "$release" chart/

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

في دفة 3 ، من المحتمل أن نهمل install / upgrade / --replace / --upgrade / --force واستبدالهم جميعًا بـ helm deploy معتدل أعلاه ، والتي إذا فشل helm deploy ، تتراجع (المراجعة> 1) أو تحذف + عمليات التطهير (المراجعة = 1) ، لترك الحالة كما كانت من قبل. سيظل البيان الفاشل متاحًا عبر helm history/get . ويمكن أن يكون هناك خيار "- عدم التراجع" للأشخاص الذين يريدون الحفاظ على النشر في حالة فشل للتحقيق

يقترب خيار helm upgrade --install --force ، باستثناء أنه بدلاً من التراجع والترقية ، فإنه يحذف ويستبدل الإصدارات الفاشلة (حتى بالنسبة للمراجعات> 1) ، مما يجعل بعض الأشخاص غاضبين بشأن # 3208 ... 😮 ⚡️ 💥

في الوقت الحالي ، يمكننا استخدام البرامج النصية المجمعة أو الأدوات الوصفية مثل helmsman التي تعد قائمة ميزاتها جزئيًا لتوظيف helm ولكن قم بتخفيف هذه المشكلة:

• Idempotency : طالما أن ملف الحالة الذي تريده لا يتغير ، يمكنك تنفيذ Helmsman عدة مرات والحصول على نفس النتيجة. _ [... بغض النظر عن الوضع الحالي] _
• الاستمرار من الفشل : في حالة النشر الجزئي بسبب فشل نشر مخطط معين ، قم بإصلاح مخطط الدفة الخاص بك وقم بتنفيذ Helmsman مرة أخرى دون الحاجة إلى التراجع عن النجاحات الجزئية أولاً.

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

في الماضي ، هذا هدف تصميم واضح بشكل مذهل.

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

هل هناك أي حل بديل لنشر مخطط عندما `` فشل الإصدار الأولي على ما يبدو '' ولكنه لا بأس به بالفعل؟

إذن ، هل الاستنتاج الذي مفاده أن upgrade --force قوي للغاية ، أي أن هناك أوقاتًا يكون فيها الحذف + استبدال + retry_upgrade هو العلاج غير الصحيح لفشل الترقية؟

هل هناك مشكلة منفصلة تتبع فكرة دمج install & upgrade في أمر deploy ؟

لا أعرف منdcow. ما هي حالة الاستخدام فوق الأمر helm upgrade --install ؟

https://github.com/helm/helm/issues/3353#issuecomment -362497951

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

و

https://github.com/helm/helm/issues/3353#issuecomment -469109854

مع helm حاليًا ، لا تعرف أي مجموعة أوامر + خيارات لاستخدامها دون فحص الحالة الحالية. وبالنسبة لأمر قيادة معين ، فأنت لا تعرف ما الذي ستحصل عليه ، لأنه يعتمد على الحالة الحالية. هذا ليس في الحقيقة ابتسامة zzz سحابة الحلم الإعلاني المطلوب

في helm 3 ، يمكننا إهمال install / Upgrade / --replace / --upgrade / --force واستبدالها جميعًا بنشر خوذة فعالة إما أن تحقق الحالة المطلوبة ، أو تترك الحالة دون تغيير.
...

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

dcow حسنًا ، هل تريد إنشاء مشكلة بعد ذلك مع

hickeyma انتهى https://github.com/helm/helm/issues/8415!