Helm: `हेल्म अपग्रेड - इंस्टॉलेशन` यदि पहले कभी भी विफल रहता है, तो एक इंस्टॉल / अपग्रेड नहीं करता है

यह 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 क्या आपकी इस पर कोई राय है?

सुझाया गया फिक्स एक स्वचालित प्रणाली में पूरी तरह से अस्थिर लगता है। मैं निश्चित रूप से नहीं चाहता कि सब कुछ पतवार को लागू करने के बारे में पता होना चाहिए "अगर पहली रिलीज़ विफल हो जाती है, हटाएं और पुनः प्रयास करें"। एक के लिए, मेरे अधिकांश टूलिंग के बारे में पता नहीं है अगर यह एक इंस्टॉल या अपग्रेड है, या यदि यह पहली बार या 100 वीं बार है, तो यह लगभग हमेशा helm upgrade --install चल रहा है।

मैं यह भी कहना चाहता हूं कि मैंने मूल पीआर https://github.com/kubernetes/helm/pull/3097#discussion_r151808599 पर टिप्पणी करते हुए इस मामले के बारे में विशेष रूप से पूछा।

इस मामले के लिए पुराना व्यवहार बेहतर था।
मैं @chancez से सहमत हूं। यह एक सामान्य घटना के लिए upgrade --install गैर-बेरोजगार बनाता है।

@bacongobbler
यदि हम असफल हुक के कारण छोड़े जाने और छोड़े जाने के बारे में चिंतित हैं, तो मैं कहूंगा कि यह एक डिज़ाइन चार्ट जारी करता है। (हुक बेहतर काम करते हैं जब वे बेकार हैं)
उपयोगकर्ता त्रुटि से निपटने और असहाय व्यवहार करने के लिए स्वतंत्र हैं।

हम अन्य किन किन मामलों के बारे में चिंतित हैं?
लगता है # 3097 बहुत 97 का ख्याल रखता है

अगर मैं helm upgrade -i को भी कम से कम कुछ तर्कों के संयोजन के लिए विफल कर सकता हूं, तो मेरा स्थानीय विकास बहुत अधिक चिकना हो जाएगा। मेरा उपयोग मामला तब है जब मेरे पास कई रिलीज़ की स्क्रिप्ट है जो मुझे पता है कि मैं स्थानीय विकास शुरू करने के लिए उठना चाहता हूं।

इस के अनुरूप हो सकता है --replace के लिए झंडा helm install । ध्यान दें कि --replace से केवल दो झंडे में से एक है helm install कि में याद आ रही है helm upgrade , अन्य किया जा रहा है --name-template ।

बिल्कुल स्पष्ट होने के लिए, हाँ यह ठीक करने के लिए एक अच्छी बात होगी। जब हम अपने हाथों को दूसरे काम से भर लेते हैं तो कोई भी उस पर दरार डालना चाहता है?

नमस्ते,
मैंने एक PR 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 delete --purge चले?
कुछ इस तरह:
1) उपयोगकर्ता helm upgrade --install निष्पादित करता है
2) पहली रिलीज़ विफल
3) उपयोगकर्ता चार्ट में कुछ बदलाव करता है और helm upgrade --install फिर से निष्पादित करता है
4) हेल्म कमांड चलाने की कोशिश करता है
5) यह विफल रहता है और विफल स्थिति में ठीक एक पूर्व रिलीज है
6) हेल्म चुपचाप helm delete --purge निष्पादित करता है
6) शुद्ध करने के बाद, हेल्म ऑटो helm upgrade --install रिट्रीट करता है और उसी से आउटपुट दिखाता है

शायद इस व्यवहार को --force ध्वज के माध्यम से ट्रिगर किया जा सकता है, जिसमें पहले से ही अन्य परिदृश्यों के समान व्यवहार है

अच्छा विचार है, लेकिन मुझे नहीं लगता कि हमें उस डेटा को हटाने के लिए उपयोगकर्ता से स्पष्ट रूप से पूछे बगैर कभी भी रिलीज़ लेज़र को हटाना चाहिए। हेल्म के संचालक यह जानना चाहेंगे कि सेवा पहले विफल रिलीज़ से अपग्रेड करने में विफल क्यों रही, या लेज़र से उस डेटा को एकत्रित करके विफलताओं को घटा दिया।

मैंने पहले थ्रेड में एक थी जो समस्या के समाधान का वर्णन करती है। यह निष्पादन में आपके समाधान के समान है, लेकिन संपूर्ण रिलीज़ लेज़र को हटाने की आवश्यकता के बिना। मेरा मानना ​​है कि # 3437 उस समाधान को एक पैच के रूप में लागू करने का प्रयास कर रहा है।

@rchernobelskiy मेरे साथ भी होता है। बिल्कुल जैसा कि आप वर्णन करते हैं।

मैं इस मुद्दे को चलाने के लिए शायद एक बार प्रति दिन जब नए क्षुधा की तैनाती।
यह एक दर्द है!

@gmanolache हम अभी भी इस कारण से
यह मेरे लिए स्पष्ट नहीं है कि --force ध्वज का उपयोग करने के लिए अपग्रेड करना सुरक्षित है: टिप्पणी नहीं

यदि आपको डाउनग्रेड करने की आवश्यकता है, तो इसे करने का एक अच्छा तरीका है: डाउनग्रेड करने के लिए 2.7.0

यह उपयोगी लगने वाली 'हेलम लेज़र' डायग्नोस्टिक जानकारी क्या है और हम इसे कैसे प्राप्त करते हैं? :मुस्कुराओ:

मुझे चिंता है कि नीचे मूडी के रूप में पढ़ा जा सकता है, यह वास्तव में संकेत के लिए सिर्फ एक निमंत्रण है कि कैसे हम नैदानिक ​​जानकारी प्राप्त कर सकते हैं जब आपके पास एक विफल तैनाती है। क्योंकि यह वास्तव में लगता है जैसे मुझे कुछ याद आ रहा है। ऐसा लगता है कि विफल राज्य को ऑपरेटरों के लिए कुछ उपयोगिता माना जाता है? मैं फिर से पतवार मैनुअल साइट के माध्यम से फंस गया; उपयोगी निदान जानकारी निकालने के लिए विफल स्थिति में 'हेल्म मेनिफ़ेस्ट' कार्य जैसा कुछ होगा?

मेरे उपयोगकर्ता अनुभव जब मुझे एक असफल तैनाती मिलती है तो आपको कोई उपयोगी जानकारी नहीं मिलती है। हेल्म आंशिक रूप से बनाए गए / शेष संसाधनों को इस तरह से निष्क्रिय कर देता है जैसे कि 'हेलम स्टेटस' कुछ भी नहीं दिखाता है। आप बस इतना कर सकते हैं कि 'रोलबैक' या 'डिलीट - अपर्ज' (आप सिर्फ 'डिलीट' नहीं कर सकते या आपका CI 'अपग्रेड-इंस्टॉलेशन' फेल होता रहेगा)। असफल राज्य केवल install अपग्रेड - इंस्टालेशन ’की बेमिसालता को तोड़ने के लिए सेवा करने के लिए लगता है कि हम सभी अपने सीआई की तैनाती के लिए तरसते हैं।

क्या सीआई स्थितियों के लिए '--auto-rollback' विकल्प रखना उचित होगा, उदाहरण के लिए 'उन्नयन --install --auto-rollback'। मैं आमतौर पर एक रोल बैक चाहता हूं जिसे एक विफल स्थिति से निपटने के लिए बिस्तर से बाहर निकलना पड़ता है

यह उपयोगी लगने वाली 'हेलम लेज़र' डायग्नोस्टिक जानकारी क्या है और हम इसे कैसे प्राप्त करते हैं? 😄

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 तो दोनों असफल तैनाती रोलबैक को बहीखाता में दर्ज किया जाता और ऑपरेटरों के लिए उपलब्ध होता। और यह कि 'असहाय' विफल होने की स्थिति में सीआई की तैनाती को रोकने के लिए एक लंबा रास्ता तय किया जाएगा जहां 'हेल्म अपग्रेड - इंस्टॉलेशन' काम करना बंद कर देता है। असफल सीआई तैनाती आमतौर पर तैनाती प्रणाली में टाइपो / गलतियों को इंजेक्ट करने वाले डेवलपर्स हैं। '--ऑटो-रोलबैक' के साथ, वे तैनाती सर्वर लॉग में बनाए helm कमांड त्रुटि संदेश का निरीक्षण कर सकते हैं, ठीक कर सकते हैं और सही किए गए मानों को तैनात कर सकते हैं।

मुझे लगता है कि '- आटो-रोलबैक' विकल्प के बिना भी हम किसी रैपर ऑटोमेट का उपयोग helm rollback किसी भी समय helm update --install 'FAILED' त्रुटि के लिए कर सकते हैं। और हो सकता है कि पता लगाएं कि यह शुरुआती इंस्टॉल कहां है, और उन मामलों में helm delete --purge ।

यही है, हम एक CI 'हेल्म अपग्रेड - इंस्टॉलेशन' के परिणामों को सुनिश्चित करने के लिए एक रैपर स्क्रिप्ट का फैशन कर सकते हैं, हमेशा एक ऐसी स्थिति होती है जहां अगला CI 'हेल्म अपग्रेड - इंस्टॉलेशन' हमेशा संभव होगा। किसी भी असफल प्रयासों के लिए बहीखाता जानकारी को बनाए रखना (कम से कम उन रिलीज के लिए जिनके शुरुआती काम ने काम किया है)।

helm deploy =

• helm upgrade --install
• अगर फेल है तो
  
  
  
  • अगर संशोधन = 1
  
  
  • तब helm delete --purge
  
  
  • helm rollback
  
  

@ वायसैरोन कि सुरुचिपूर्ण 👍 होगी

वहाँ एक आसान तरीका नवीनतम काम कर की तरह कुछ के अलावा अन्य रिहाई पाने के लिए है helm history ${name} | tail -2 | head -1 | awk '{print $1}' , द्वारा प्रयोग की जाने helm rollback ?

नमस्ते,

मैं हेल्म 2.12.2 का उपयोग कर रहा हूं और अभी भी समस्या है, कि पहली तैनाती विफल होने पर, हेल्म विफल हो जाती है। क्या यह एक प्रतिगमन हो सकता है?

मुझे यकीन नहीं है कि यह एक प्रतिगमन है, लेकिन यह वास्तव में "निश्चित" नहीं था।

@ रिक्स- C137 मुझे लगता है कि यह helm upgrade --install --force का उपयोग करके तय किया जाना चाहिए जो कि 'डिलीट' करेगा, फिर 'असफल' हो जाएगा।

फिर भी जेनकींस पाइपलाइन में इस मुद्दे को ठीक करने की कोशिश कर रहा हूं।
मैं अपने आवेदन की एक नई छवि को तैनात करने की कोशिश कर रहा हूं और अगर तैनाती पहले से मौजूद है या नहीं तो मैं इसकी परवाह नहीं कर सकता।
मैं एक आदेश चलाना चाहता हूं जो या तो वर्तमान तैनाती को बदल देता है या बस इसे स्थापित करता है अगर यह मौजूद नहीं है।
मैंने 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/

वर्तमान में, आप वर्तमान स्थिति का निरीक्षण किए बिना उपयोग करने के लिए कौन सा हेलम कमांड + विकल्प संयोजन नहीं जानते हैं। और किसी दिए गए हेलम कमांड के लिए आप नहीं जानते कि आपको क्या मिलने वाला है, क्योंकि यह इस बात पर निर्भर करता है कि वर्तमान स्थिति क्या है। यह वास्तव में घोषित वांछित राज्य का सपना नहीं है ative ative ative

पतवार 3 में हम संभावित रूप से install / upgrade / --replace / --upgrade / --force कमाएँ और उन सभी को एक आदर्श helm deploy साथ बदलें ऊपर के समान एल्गोरिथ्म का उपयोग किया जा रहा हो, जो helm deploy विफल होने पर, वापस (संशोधन> 1) या राज्य से बाहर जाने के लिए + पर्स (संशोधन = 1) हटाता है, जैसा कि पहले था। असफल प्रकट अभी भी helm history/get माध्यम से उपलब्ध होगा। और यहां तक ​​कि उन लोगों के लिए एक '-नो-रोलबैक' विकल्प भी हो सकता है जो जांच के लिए एक विफल स्थिति में तैनाती को संरक्षित करना चाहते हैं

helm upgrade --install --force का विकल्प बंद हो रहा है, सिवाय इसके कि पीछे मुड़ने और अपग्रेड करने के बजाय, यह विफल हो जाता है और बदल देता है (यहां तक ​​कि संशोधन> 1), जो कुछ लोगों को # 3208 ... 😮 over पर गुस्सा करता है 💥

अभी के लिए हम helmsman जैसे रैपर स्क्रिप्ट या मेटा-टूल्स का उपयोग कर सकते हैं जिनकी फ़ीचर सूची helm नियोजित करने के लिए है, लेकिन इस समस्या को कम करें:

• आय : जब तक आपकी वांछित राज्य फ़ाइल नहीं बदलती है, तब तक आप कई बार हेल्समैन को निष्पादित कर सकते हैं और समान परिणाम प्राप्त कर सकते हैं। _ [... वर्तमान स्थिति की परवाह किए बिना] _
• विफलताओं से जारी रखें : एक विशिष्ट चार्ट परिनियोजन विफलता के कारण आंशिक परिनियोजन के मामले में, अपने हेल्म चार्ट को ठीक करें और पहले आंशिक सफलताओं को रोलबैक करने की आवश्यकता के बिना हेल्समैन को फिर से निष्पादित करें।

उन सभी को एक आदर्श हेल्मेट के साथ प्रतिस्थापित करें जो या तो वांछित राज्य को प्राप्त करता है, या राज्य को अपरिवर्तित छोड़ देता है

रेट्रोस्पेक्ट में, यह एक लुभावनी स्पष्ट डिजाइन लक्ष्य है।

नमस्ते,
हमारे मामले में प्रारंभिक रिलीज वास्तव में विफल नहीं हुई ... यह सिर्फ इतना है कि हमारे आवेदन पूरी तरह से तब तक नहीं था जब इंस्टॉल टाइमआउट समाप्त हो गया था या कुछ अन्य अजीब मुद्दे तय हो गए थे। किसी भी मामले में, एप्लिकेशन पूरी तरह से ठीक चल रहा है, और इस तरह इसे हटाने के लिए हमारे लिए एक समस्या होगी (हमारे पास कुछ लगातार भंडारण संलग्न है जो भी हटा दिया जाएगा !!)।

क्या प्रारंभिक रिलीज 'जाहिरा तौर पर विफल' होने पर चार्ट को तैनात करने के लिए कोई वर्कअराउंड है लेकिन यह वास्तव में ठीक है?

तो क्या निष्कर्ष यह है कि upgrade --force बहुत ज़बरदस्त है, यानी कई बार ऐसा होता है कि असफल + रिप्लेसमेंट + रिट्री_अपग्रेड विफल होने का सही उपाय नहीं है?

क्या install & upgrade को deploy कमांड में विलय करने के विचार को ट्रैक करने वाला एक अलग मुद्दा है?

ऐसा नहीं कि मुझे @dcow का पता है। helm upgrade --install आदेश पर उपयोग का मामला क्या है?

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

मुझे यकीन नहीं है कि हमें कमांड और अपग्रेड कमांड की आवश्यकता क्यों है, मैं कभी भी अपग्रेड - इंस्टॉलेशन कमांड का उपयोग करता हूं और ऐसा लगता है कि बहुत सारे लोग ऐसा ही करते हैं। मुझे बस एक कमांड की जरूरत है जो अपग्रेड - इंस्टॉलेशन करता है और एक असफल रन पर यात्रा नहीं करता है। क्या हम सिर्फ अपग्रेड - इंस्टॉलेशन का नाम बदल सकते हैं, इसे सही मायने में बेकार बना सकते हैं, और अन्य दो को खोद सकते हैं?
...

तथा

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

वर्तमान में, आप वर्तमान स्थिति का निरीक्षण किए बिना उपयोग करने के लिए कौन सा हेलम कमांड + विकल्प संयोजन नहीं जानते हैं। और किसी दिए गए हेलम कमांड के लिए आप नहीं जानते कि आपको क्या मिलने वाला है, क्योंकि यह इस बात पर निर्भर करता है कि वर्तमान स्थिति क्या है। यह वास्तव में घोषित वांछित राज्य सपना क्लाउड ज़ज़ मुस्कान नहीं है

पतवार 3 में हम संभावित रूप से स्थापित / अपग्रेड / /replace / --upgrad / --force लागू कर सकते हैं और उन सभी को एक आलसी तैनाती के साथ बदल सकते हैं जो या तो वांछित राज्य को प्राप्त करता है, या राज्य को अपरिवर्तित छोड़ देता है।
...

मैं आम तौर पर सहमत हूं कि पतवार को आपके क्लस्टर की स्थिति के आधार पर विभिन्न प्रकार के आदेशों को चलाने की आवश्यकता के बजाय kubectl apply तरह काम करना चाहिए और वांछित वास्तविकता को प्राप्त करने का प्रयास करना चाहिए। एक समर्पित मुद्दे पर समर्थन जोड़ने की उम्मीद कर रहा था अगर कोई मौजूद था या कम से कम यह पता लगाता है कि संकल्प deploy वर्तमान में लागू नहीं हुआ है और हम helm 3.2 पर हैं।

@dcow ठीक है, क्या आप अपने प्रस्ताव के साथ एक मुद्दा बनाना चाहते हैं?

@hickeyma ने किया https://github.com/helm/helm/issues/8415!