वेयरफ़ में 3-तरफ़ा विलय: "स्टेरॉयड पर" हेल्म के साथ कुबेरनेट्स में तैनाती

जिसका हम (और केवल हम ही नहीं) लंबे समय से इंतजार कर रहे थे वह हुआ: Werf, एप्लिकेशन बनाने और उन्हें कुबेरनेट्स तक पहुंचाने के लिए हमारी ओपन सोर्स उपयोगिता, अब 3-तरफ़ा मर्ज पैच का उपयोग करके परिवर्तन लागू करने का समर्थन करती है! इसके अतिरिक्त, इन संसाधनों के पुनर्निर्माण के बिना मौजूदा K8s संसाधनों को हेल्म रिलीज़ में अपनाना संभव है।

यदि यह बहुत छोटा है, तो हम डालते हैं WERF_THREE_WAY_MERGE=enabled - हमें तैनाती मिलती है "जैसा कि kubectl apply", मौजूदा हेल्म 2 इंस्टॉलेशन और उससे भी कुछ अधिक के साथ संगत।

लेकिन आइए सिद्धांत से शुरू करें: वास्तव में 3-वे-मर्ज पैच क्या हैं, लोग उन्हें उत्पन्न करने के दृष्टिकोण के साथ कैसे आए, और वे कुबेरनेट्स-आधारित बुनियादी ढांचे के साथ सीआई/सीडी प्रक्रियाओं में क्यों महत्वपूर्ण हैं? और उसके बाद, आइए देखें कि वेयरफ़ में 3-वे-मर्ज क्या है, डिफ़ॉल्ट रूप से कौन से मोड का उपयोग किया जाता है और इसे कैसे प्रबंधित किया जाए।

3-वे-मर्ज पैच क्या है?

तो, आइए YAML मैनिफ़ेस्ट में वर्णित संसाधनों को कुबेरनेट्स में रोल आउट करने का कार्य शुरू करें।

संसाधनों के साथ काम करने के लिए, कुबेरनेट्स एपीआई निम्नलिखित बुनियादी संचालन प्रदान करता है: बनाएं, पैच करें, बदलें और हटाएं। यह माना जाता है कि उनकी मदद से क्लस्टर में संसाधनों के सुविधाजनक निरंतर रोलआउट का निर्माण करना आवश्यक है। कैसे?

kubectl अनिवार्य आदेश

कुबेरनेट्स में वस्तुओं को प्रबंधित करने का पहला तरीका उन वस्तुओं को बनाने, संशोधित करने और हटाने के लिए कुबेक्टल अनिवार्य आदेशों का उपयोग करना है। सीधे शब्दों में कहें:

• टीम kubectl run आप परिनियोजन या कार्य चला सकते हैं:

  kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE

• टीम kubectl scale - प्रतिकृतियों की संख्या बदलें:

  kubectl scale --replicas=3 deployment/mysql

• आदि

यह दृष्टिकोण पहली नज़र में सुविधाजनक लग सकता है। हालाँकि समस्याएँ हैं:

1. यह मुश्किल है स्वचालित करने के लिए.
2. जैसा विन्यास प्रतिबिंबित करें गिट में? क्लस्टर में हो रहे परिवर्तनों की समीक्षा कैसे करें?
3. कैसे प्रदान करें reproducibility पुनरारंभ पर कॉन्फ़िगरेशन?
4. ...

यह स्पष्ट है कि यह दृष्टिकोण एप्लिकेशन और बुनियादी ढांचे को कोड (IaC; या यहां तक ​​​​कि) के रूप में संग्रहीत करने के साथ अच्छी तरह फिट नहीं बैठता है GitOps एक अधिक आधुनिक विकल्प के रूप में, कुबेरनेट्स पारिस्थितिकी तंत्र में लोकप्रियता प्राप्त कर रहा है)। इसलिए, इन कमांडों को कुबेक्टल में और विकास नहीं मिला।

संचालन बनाएं, प्राप्त करें, बदलें और हटाएं

प्राथमिक के साथ का निर्माण यह सरल है: ऑपरेशन के लिए मेनिफेस्ट भेजें create क्यूब एपीआई और संसाधन बनाया गया है। मेनिफेस्ट का YAML प्रतिनिधित्व Git में संग्रहीत किया जा सकता है और कमांड का उपयोग करके बनाया जा सकता है kubectl create -f manifest.yaml.

С निष्कासन यह भी सरल है: वही स्थानापन्न करें manifest.yaml Git से टीम तक kubectl delete -f manifest.yaml.

आपरेशन replace आपको संसाधन को दोबारा बनाए बिना, संसाधन कॉन्फ़िगरेशन को पूरी तरह से एक नए से बदलने की अनुमति देता है। इसका मतलब यह है कि किसी संसाधन में परिवर्तन करने से पहले, ऑपरेशन के साथ वर्तमान संस्करण को क्वेरी करना तर्कसंगत है get, इसे बदलें और ऑपरेशन के साथ इसे अपडेट करें replace. क्यूब एपीसर्वर बनाया गया है आशावादी ताला और, यदि सर्जरी के बाद get ऑब्जेक्ट बदल गया है, फिर ऑपरेशन replace यह काम नहीं करेगा.

कॉन्फ़िगरेशन को Git में संग्रहीत करने और रिप्लेस का उपयोग करके इसे अपडेट करने के लिए, आपको ऑपरेशन करने की आवश्यकता है get, जो हमें प्राप्त हुआ उसके साथ Git से कॉन्फिगरेशन को मर्ज करें और निष्पादित करें replace. डिफ़ॉल्ट रूप से, kubectl आपको केवल कमांड का उपयोग करने की अनुमति देता है kubectl replace -f manifest.yamlजहां manifest.yaml - पहले से ही पूरी तरह से तैयार (हमारे मामले में, विलय) मैनिफ़ेस्ट जिसे स्थापित करने की आवश्यकता है। यह पता चला है कि उपयोगकर्ता को मर्ज मैनिफ़ेस्ट लागू करने की आवश्यकता है, और यह कोई मामूली बात नहीं है...

हालाँकि यह भी ध्यान देने योग्य बात है manifest.yaml और Git में संग्रहीत है, हम पहले से नहीं जान सकते कि किसी ऑब्जेक्ट को बनाना या उसे अपडेट करना आवश्यक है - यह उपयोगकर्ता सॉफ़्टवेयर द्वारा किया जाना चाहिए।

कुल: क्या हम एक सतत रोलआउट बना सकते हैं? केवल बनाएं, बदलें और हटाएं का उपयोग करके यह सुनिश्चित करें कि बुनियादी ढांचा कॉन्फ़िगरेशन कोड और सुविधाजनक सीआई/सीडी के साथ गिट में संग्रहीत है?

सिद्धांत रूप में, हम इसके लिए... कर सकते हैं आपको मर्ज ऑपरेशन लागू करने की आवश्यकता होगी घोषणापत्र और किसी प्रकार का बंधन जो:

• क्लस्टर में किसी ऑब्जेक्ट की उपस्थिति की जाँच करता है,
• प्रारंभिक संसाधन निर्माण करता है,
• उसे अद्यतन करता है या हटा देता है।

अपडेट करते समय कृपया इस बात का ध्यान रखें संसाधन बदल गया होगा पिछली बार से लेकर get और स्वचालित रूप से आशावादी लॉकिंग के मामले को संभालें - बार-बार अद्यतन प्रयास करें।

हालाँकि, जब क्यूब-एपिसर्वर संसाधनों को अद्यतन करने का एक और तरीका प्रदान करता है: ऑपरेशन, तो पहिए का पुन: आविष्कार क्यों करें patch, जो उपयोगकर्ता को वर्णित कुछ समस्याओं से छुटकारा दिलाता है?

पैच

अब हम पैच पर आते हैं।

कुबेरनेट्स में मौजूदा ऑब्जेक्ट में परिवर्तन लागू करने का प्राथमिक तरीका पैच है। संचालन patch यह इस तरह काम करता है:

• क्यूब-एपिसर्वर उपयोगकर्ता को JSON फॉर्म में एक पैच भेजने और ऑब्जेक्ट निर्दिष्ट करने की आवश्यकता है,
• और एपिसर्वर स्वयं वस्तु की वर्तमान स्थिति से निपटेगा और उसे आवश्यक रूप में लाएगा।

इस मामले में आशावादी लॉकिंग की आवश्यकता नहीं है। यह ऑपरेशन रिप्लेस की तुलना में अधिक घोषणात्मक है, हालाँकि पहली बार में यह दूसरा तरीका लग सकता है।

इस प्रकार:

• एक ऑपरेशन का उपयोग करना create हम Git के मेनिफेस्ट के अनुसार एक ऑब्जेक्ट बनाते हैं,
• के माध्यम से delete - यदि ऑब्जेक्ट की अब आवश्यकता नहीं है तो हटा दें,
• के माध्यम से patch - हम ऑब्जेक्ट को बदलते हैं, इसे Git में वर्णित रूप में लाते हैं।

हालाँकि, ऐसा करने के लिए, आपको बनाने की आवश्यकता है सही पैच!

हेल्म 2 में पैच कैसे काम करते हैं: 2-वे-मर्ज

जब आप पहली बार कोई रिलीज़ स्थापित करते हैं, तो हेल्म ऑपरेशन करता है create चार्ट संसाधनों के लिए.

प्रत्येक संसाधन के लिए हेल्म रिलीज़ को अद्यतन करते समय:

• पिछले चार्ट के संसाधन संस्करण और वर्तमान चार्ट संस्करण के बीच पैच पर विचार करता है,
• इस पैच को लागू करता है.

हम इस पैच को कॉल करेंगे 2-तरफा मर्ज पैच, क्योंकि इसके निर्माण में 2 घोषणापत्र शामिल हैं:

• पिछली रिलीज़ से संसाधन प्रकट,
• वर्तमान संसाधन से संसाधन प्रकट।

ऑपरेशन हटाते समय delete क्यूब में एपिसर्वर को उन संसाधनों के लिए बुलाया जाता है जो पिछली रिलीज़ में घोषित किए गए थे, लेकिन वर्तमान रिलीज़ में घोषित नहीं किए गए थे।

2-तरफ़ा मर्ज पैच दृष्टिकोण में एक समस्या है: यह की ओर ले जाती है क्लस्टर में संसाधन की वास्तविक स्थिति और Git में प्रकट होने के साथ समन्वय से बाहर.

एक उदाहरण के साथ समस्या का चित्रण

• Git में, एक चार्ट एक मेनिफेस्ट संग्रहीत करता है जिसमें फ़ील्ड image तैनाती मायने रखती है ubuntu:18.04.
• उपयोगकर्ता के माध्यम से kubectl edit इस फ़ील्ड का मान बदल दिया ubuntu:19.04.
• हेल्म चार्ट को पुनः तैनात करते समय एक पैच उत्पन्न नहीं करता, क्योंकि फ़ील्ड image रिलीज़ के पिछले संस्करण और वर्तमान चार्ट में समान हैं।
• पुन: तैनाती के बाद image अवशेष ubuntu:19.04, हालाँकि चार्ट कहता है ubuntu:18.04.

हमें डीसिंक्रनाइज़ेशन मिला और घोषणात्मकता खो गई।

समकालिक संसाधन क्या है?

आम तौर पर बोलते हुए पूर्ण रनिंग क्लस्टर में रिसोर्स मेनिफेस्ट और Git से मेनिफेस्ट के बीच मिलान प्राप्त करना असंभव है। क्योंकि वास्तविक मैनिफ़ेस्ट में सेवा एनोटेशन/लेबल, अतिरिक्त कंटेनर और अन्य डेटा हो सकते हैं जो कुछ नियंत्रकों द्वारा गतिशील रूप से संसाधन से जोड़े और हटाए जाते हैं। हम इस डेटा को Git में नहीं रख सकते और न ही रखना चाहते हैं। हालाँकि, हम चाहते हैं कि जिन फ़ील्ड्स को हमने Git में स्पष्ट रूप से निर्दिष्ट किया है, वे रोलआउट पर उचित मान लें।

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

3-तरफा मर्ज पैच

केंद्रीय विचार 3-तरफा मर्ज पैच: चल रहे क्लस्टर से मेनिफेस्ट के वर्तमान संस्करण को ध्यान में रखते हुए, Git से मेनिफेस्ट के अंतिम लागू संस्करण और Git से मेनिफेस्ट के लक्ष्य संस्करण के बीच एक पैच उत्पन्न करें। परिणामी पैच को सिंक्रनाइज़ संसाधन नियम का पालन करना होगा:

• लक्ष्य संस्करण में जोड़े गए नए फ़ील्ड पैच का उपयोग करके जोड़े जाते हैं;
• अंतिम लागू संस्करण में पहले से मौजूद फ़ील्ड और लक्ष्य संस्करण में मौजूद नहीं को पैच का उपयोग करके रीसेट किया जाता है;
• ऑब्जेक्ट के वर्तमान संस्करण में वे फ़ील्ड जो मेनिफेस्ट के लक्ष्य संस्करण से भिन्न हैं, पैच का उपयोग करके अपडेट किए जाते हैं।

इसी सिद्धांत पर यह पैच उत्पन्न करता है kubectl apply:

• मेनिफेस्ट का अंतिम लागू संस्करण ऑब्जेक्ट के एनोटेशन में ही संग्रहीत है,
• लक्ष्य - निर्दिष्ट YAML फ़ाइल से लिया गया,
• वर्तमान एक चालू क्लस्टर से है।

अब जब हमने सिद्धांत को सुलझा लिया है, तो अब आपको यह बताने का समय आ गया है कि हमने वेयरफ़ में क्या किया।

वेयरफ़ में परिवर्तन लागू करना

पहले, हेल्म 2 की तरह, वेयरफ़, 2-वे-मर्ज पैच का उपयोग करता था।

मरम्मत पैच

एक नए प्रकार के पैच - 3-वे-मर्ज - पर स्विच करने के लिए पहला कदम हमने तथाकथित पेश किया मरम्मत पैच.

तैनाती करते समय, एक मानक 2-वे-मर्ज पैच का उपयोग किया जाता है, लेकिन वेयरफ़ अतिरिक्त रूप से एक पैच उत्पन्न करता है जो संसाधन की वास्तविक स्थिति को Git में लिखे गए के साथ सिंक्रनाइज़ करेगा (ऐसा पैच ऊपर वर्णित समान सिंक्रनाइज़ संसाधन नियम का उपयोग करके बनाया गया है) .

यदि कोई डीसिंक्रनाइज़ेशन होता है, तो तैनाती के अंत में उपयोगकर्ता को संबंधित संदेश और एक पैच के साथ एक चेतावनी प्राप्त होती है जिसे संसाधन को एक सिंक्रनाइज़ फॉर्म में लाने के लिए लागू किया जाना चाहिए। यह पैच एक विशेष एनोटेशन में भी दर्ज किया गया है werf.io/repair-patch. यह माना जाता है कि उपयोगकर्ता के हाथ स्वयं इस पैच को लागू करेगा: वेयर्फ़ इसे बिल्कुल भी लागू नहीं करेगा।

मरम्मत पैच उत्पन्न करना एक अस्थायी उपाय है जो आपको वास्तव में 3-वे-मर्ज सिद्धांत के आधार पर पैच के निर्माण का परीक्षण करने की अनुमति देता है, लेकिन इन पैच को स्वचालित रूप से लागू नहीं करता है। फिलहाल, यह ऑपरेटिंग मोड डिफ़ॉल्ट रूप से सक्षम है।

3-वे-मर्ज पैच केवल नई रिलीज़ के लिए

1 दिसंबर, 2019 से वेयरफ़ के बीटा और अल्फा संस्करण शुरू होंगे डिफ़ॉल्ट रूप से केवल वेयरफ़ के माध्यम से जारी किए गए नए हेल्म रिलीज़ में परिवर्तन लागू करने के लिए पूर्ण विकसित 3-वे-मर्ज पैच का उपयोग करें। मौजूदा रिलीज़ 2-वे-मर्ज + रिपेयर पैच दृष्टिकोण का उपयोग करना जारी रखेंगे।

इस ऑपरेटिंग मोड को सेटिंग द्वारा स्पष्ट रूप से सक्षम किया जा सकता है WERF_THREE_WAY_MERGE_MODE=onlyNewReleases अब।

नोट: यह सुविधा कई रिलीजों में वेयरफ़ में दिखाई दी: अल्फा चैनल में यह संस्करण के साथ तैयार हो गया v1.0.5-अल्फा.19, और बीटा चैनल में - साथ v1.0.4-बीटा.20.

सभी रिलीज़ों के लिए 3-वे-मर्ज पैच

15 दिसंबर, 2019 से, वेयरफ़ के बीटा और अल्फा संस्करण सभी रिलीज़ में परिवर्तन लागू करने के लिए डिफ़ॉल्ट रूप से पूर्ण 3-वे-मर्ज पैच का उपयोग करना शुरू कर देते हैं।

इस ऑपरेटिंग मोड को सेटिंग द्वारा स्पष्ट रूप से सक्षम किया जा सकता है WERF_THREE_WAY_MERGE_MODE=enabled अब।

संसाधन ऑटोस्केलिंग के साथ क्या करें?

कुबेरनेट्स में ऑटोस्केलिंग 2 प्रकार की होती है: एचपीए (क्षैतिज) और वीपीए (ऊर्ध्वाधर)।

क्षैतिज स्वचालित रूप से प्रतिकृतियों की संख्या का चयन करता है, ऊर्ध्वाधर - संसाधनों की संख्या। प्रतिकृतियों की संख्या और संसाधन आवश्यकताएँ दोनों संसाधन मेनिफेस्ट में निर्दिष्ट हैं (संसाधन मेनिफेस्ट देखें)। spec.replicas या spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и अन्य लोग).

समस्या: यदि कोई उपयोगकर्ता किसी चार्ट में किसी संसाधन को कॉन्फ़िगर करता है ताकि वह संसाधनों या प्रतिकृतियों के लिए कुछ मान निर्दिष्ट कर सके और इस संसाधन के लिए ऑटोस्केलर सक्षम हो, तो प्रत्येक परिनियोजन के साथ वेयरफ़ इन मानों को चार्ट मेनिफेस्ट में लिखे गए मानों पर रीसेट कर देगा। .

समस्या के दो समाधान हैं. आरंभ करने के लिए, चार्ट मेनिफेस्ट में स्पष्ट रूप से ऑटोस्केल्ड मान निर्दिष्ट करने से बचना सबसे अच्छा है। यदि यह विकल्प किसी कारण से उपयुक्त नहीं है (उदाहरण के लिए, क्योंकि प्रारंभिक संसाधन सीमाएं और चार्ट में प्रतिकृतियों की संख्या निर्धारित करना सुविधाजनक है), तो वेयरफ़ निम्नलिखित एनोटेशन प्रदान करता है:

• werf.io/set-replicas-only-on-creation=true
• werf.io/set-resources-only-on-creation=true

यदि ऐसा कोई एनोटेशन मौजूद है, तो वेयरफ़ प्रत्येक परिनियोजन पर संबंधित मानों को रीसेट नहीं करेगा, बल्कि उन्हें केवल तभी सेट करेगा जब संसाधन प्रारंभ में बनाया गया हो।

अधिक विवरण के लिए, प्रोजेक्ट दस्तावेज़ देखें एचपीए и VPA.

3-वे-मर्ज पैच के उपयोग पर रोक लगाएं

उपयोगकर्ता वर्तमान में पर्यावरण चर का उपयोग करके वेयरफ़ में नए पैच के उपयोग को प्रतिबंधित कर सकता है WERF_THREE_WAY_MERGE_MODE=disabled. हालाँकि, शुरू हो रहा है 1 मार्च 2020 से यह प्रतिबंध लागू नहीं होगा. और केवल 3-वे-मर्ज पैच का उपयोग करना संभव होगा।

वेयरफ़ में संसाधनों को अपनाना

3-वे-मर्ज पैच के साथ परिवर्तनों को लागू करने की विधि में महारत हासिल करने से हमें क्लस्टर में मौजूद संसाधनों को हेल्म रिलीज़ में अपनाने जैसी सुविधा को तुरंत लागू करने की अनुमति मिली।

हेल्म 2 में एक समस्या है: आप इस संसाधन को स्क्रैच से दोबारा बनाए बिना क्लस्टर में पहले से मौजूद चार्ट मैनिफ़ेस्ट में कोई संसाधन नहीं जोड़ सकते (देखें)। #6031, #3275). हमने वेयरफ़ को रिलीज़ के लिए मौजूदा संसाधनों को स्वीकार करना सिखाया। ऐसा करने के लिए, आपको चल रहे क्लस्टर से संसाधन के वर्तमान संस्करण पर एक एनोटेशन स्थापित करना होगा (उदाहरण के लिए, का उपयोग करके) kubectl edit):

"werf.io/allow-adoption-by-release": RELEASE_NAME

अब संसाधन को चार्ट में वर्णित करने की आवश्यकता है और अगली बार जब वेयरफ़ उपयुक्त नाम के साथ एक रिलीज़ तैनात करेगा, तो मौजूदा संसाधन इस रिलीज़ में स्वीकार कर लिया जाएगा और इसके नियंत्रण में रहेगा। इसके अलावा, रिलीज के लिए एक संसाधन को स्वीकार करने की प्रक्रिया में, वेयरफ़ समान 3-वे-मर्ज पैच और सिंक्रनाइज़ संसाधन नियम का उपयोग करके, चल रहे क्लस्टर से संसाधन की वर्तमान स्थिति को चार्ट में वर्णित स्थिति में लाएगा।

नोट: स्थापना WERF_THREE_WAY_MERGE_MODE संसाधनों को अपनाने पर कोई प्रभाव नहीं पड़ता - गोद लेने के मामले में, 3-वे-मर्ज पैच का हमेशा उपयोग किया जाता है।

विवरण - में प्रलेखन.

निष्कर्ष एवं भविष्य की योजनाएँ

मुझे उम्मीद है कि इस लेख के बाद यह स्पष्ट हो गया है कि 3-वे-मर्ज पैच क्या हैं और वे उनके पास क्यों आए। वेयरफ़ परियोजना के विकास के व्यावहारिक दृष्टिकोण से, उनका कार्यान्वयन हेल्म जैसी तैनाती में सुधार की दिशा में एक और कदम था। अब आप कॉन्फ़िगरेशन सिंक्रोनाइज़ेशन की समस्याओं के बारे में भूल सकते हैं, जो अक्सर हेल्म 2 का उपयोग करते समय उत्पन्न होती हैं। साथ ही, हेल्म रिलीज़ में पहले से डाउनलोड किए गए कुबेरनेट्स संसाधनों को अपनाने की एक नई उपयोगी सुविधा जोड़ी गई थी।

हेल्म जैसी तैनाती के साथ अभी भी कुछ मुद्दे और चुनौतियाँ हैं, जैसे गो टेम्पलेट्स का उपयोग, जिन्हें हम संबोधित करना जारी रखेंगे।

संसाधन अद्यतन विधियों और अपनाने के बारे में जानकारी यहां भी पाई जा सकती है यह दस्तावेज़ पृष्ठ.

पतवार 3

विशेष ध्यान देने योग्य जारी किया अभी कुछ ही दिन पहले हेल्म का एक नया प्रमुख संस्करण - वी3 - जो 3-वे-मर्ज पैच का भी उपयोग करता है और टिलर से छुटकारा दिलाता है। हेल्म के नए संस्करण की आवश्यकता है प्रवास मौजूदा इंस्टॉलेशन को नए रिलीज़ स्टोरेज फॉर्मेट में बदलने के लिए।

वेर्फ़ ने, अपनी ओर से, वर्तमान में टिलर का उपयोग करने से छुटकारा पा लिया है, 3-वे-मर्ज पर स्विच किया है और जोड़ा है बहुत अधिक, मौजूदा हेल्म 2 इंस्टॉलेशन के साथ संगत रहते हुए (किसी माइग्रेशन स्क्रिप्ट को निष्पादित करने की आवश्यकता नहीं है)। इसलिए, जब तक वेयरफ़ हेल्म 3 पर स्विच नहीं हो जाता, तब तक वेयरफ़ उपयोगकर्ता हेल्म 3 की तुलना में हेल्म 2 के मुख्य लाभों को नहीं खोते हैं (वेर्फ़ के पास भी हैं)।

हालाँकि, वेयरफ़ का हेल्म 3 कोडबेस पर स्विच अपरिहार्य है और निकट भविष्य में होगा। संभवतः यह werf 1.1 या werf 1.2 होगा (फिलहाल, werf का मुख्य संस्करण 1.0 है; werf संस्करण डिवाइस के बारे में अधिक जानकारी के लिए, देखें यहां). इस दौरान हेल्म 3 को स्थिर होने का समय मिलेगा।

पुनश्च

हमारे ब्लॉग पर भी पढ़ें:

• वेयरफ़ में नवाचारों के बारे में नोट्स की एक श्रृंखला:
  • «जटिल हेल्म चार्ट को रोल आउट करने के लिए वेयरफ़ का उपयोग करना";
  • «Werf में मोनोरेपो और मल्टीरेपो के लिए समर्थन और डॉकर रजिस्ट्री का इससे क्या लेना-देना है";
  • «अब आप नियमित डॉकरफाइल का उपयोग करके वेयरफ में डॉकर छवियां बना सकते हैं'.
• «werf - कुबेरनेट्स में CI / CD के लिए हमारा टूल (अवलोकन और वीडियो रिपोर्ट)";
• «वेयरफ़ और गिटलैब सीआई के साथ एक ही प्रकार की माइक्रोसर्विसेज बनाएं और तैनात करें";
• «हेल्म 3 का परिचय'.

स्रोत: www.habr.com