1.0 स्थिर स्थिर का परिचय: GitOps को इसके साथ क्या करना है, स्थिति और योजना

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

लंबे समय से प्रतीक्षित स्थिर रिलीज 1.0 कार्यों द्वारा पूरी की गई उपयोगिता का मूल संस्करण है (पहली स्थिर रिलीज का सटीक संस्करण संख्या 1.0.6 है) । मूल संस्करण में, वेयरफ एप्लिकेशन डिलीवरी और रखरखाव के पूर्ण चक्र का समर्थन करता है। इसमें एप्लिकेशन इमेज असेंबल करना, कुबेरनेट्स को तैनात करना और अप्रयुक्त चित्रों को शामिल करना शामिल है।

यह महत्वपूर्ण है कि संस्करण 1.0 में, एक मेजबान पर एक परियोजना ( build , deploy , cleanup ) पर सभी संचालन किए जाने चाहिए। इसका मतलब यह है कि सीआई सिस्टम में एक निश्चित कार्यकर्ता का उपयोग किया जाना चाहिए। इसी समय, कार्यों की समानता पर कोई प्रतिबंध नहीं है: वेयरफ पूरी तरह से इस मुद्दे को हल करता है। आप विभिन्न श्रमिकों के बीच विभिन्न परियोजनाओं को भी वितरित कर सकते हैं।

रिलीज के लिए समर्पित इस लेख में, हम इस संस्करण को प्रदान करने और प्रदान नहीं करने के साथ-साथ भविष्य के संस्करणों के लिए हमारी योजनाओं पर भी बारीकी से विचार करेंगे। लेकिन हम "GitOps" शब्द की समझ और निरंतर एकीकरण और अनुप्रयोग वितरण (CI / CD) की प्रक्रियाओं में werf की भूमिका को समझने के द्वारा शुरू करेंगे।

क्यों werf GitOps है

तो हमें GitOps से क्या मतलब है और किन क्षेत्रों में werf कवर है?

"GitOps" शब्द Weaveworks द्वारा लगभग 2.5 साल पहले बनाया गया था, और हमने हाल ही में इसके लेखकों के एक लेख का अनुवाद किया है जो ब्लॉग के लिए इस नई घटना का सार बताता है। हमारी समझ में, GitOps का मुख्य विचार और मुख्य अर्थ यह है कि Git एक "सत्य का एकल स्रोत" है । Git स्टोर:

• आवेदन कोड
• सभी निर्भरताएं;
• कंटेनरों को इकट्ठा करने के बारे में जानकारी;
• कुबेरनेट्स को कैसे तैनात किया जाए, इस पर जानकारी;
• और अन्य

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

वेयरफ उच्च स्तरीय सीएलआई इंटरफेस प्रदान करता है, जो चित्रों को बनाने और प्रकाशित करने, अनुप्रयोगों और सफाई चित्रों को वितरित करने के लिए बुनियादी आदेशों के साथ प्रदान करता है: werf build-and-publish , werf deploy , werf dismiss , werf cleanup । यह माना जाता है कि ये बहुत ही मूल आदेश एक विशेष CI सिस्टम में एम्बेडेड हैं और वास्तविकता के साथ आवश्यक सिंक्रनाइज़ेशन प्रदान करते हैं। इसके अलावा, werf विभिन्न उप-प्रणालियों के प्रबंधन के लिए एक निम्न-स्तरीय CLI इंटरफ़ेस भी प्रदान करता है - प्रलेखन में निम्न स्तर के प्रबंधन आदेश देखें।

इससे कोई फर्क नहीं पड़ता कि क्या अंतर्निहित CI / CD पुश- या पुल-मॉडल के अनुसार काम करेगा ( यहां उनके बारे में अधिक पढ़ें) , क्योंकि werf को किसी भी मॉडल में बनाया जा सकता है । उसी समय, werf ऐसी समस्याओं को अलग-अलग निम्न-स्तरीय उपयोगिताओं जैसे git , docker और kubernetes api-server के साथ काम करते हुए बंद कर देता है, एक एकीकृत CI / CD एप्लिकेशन को कॉन्फ़िगर करने के लिए "लापता भाग" होता है।

1.0f स्थिर क्या है

1. विधानसभा, प्रकाशन और छवियों की सफाई

यदि आपके आवेदन में डॉकर चित्रों के निर्माण की आवश्यकता है, तो आप 1.0 का उपयोग कर सकते हैं:

• एकल werf.yaml कॉन्फ़िगरेशन में छवियों को इकट्ठा करने के नियम (आप कई हो सकते हैं) का werf.yaml ;
• छवियों को इकट्ठा करें और डॉकर रजिस्ट्री में प्रकाशित करें
• कस्टम नीतियों के लिए समय-समय पर डॉकर रजिस्ट्री को साफ करें।

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

एकत्रित चित्रों की टैगिंग / संस्करणकरण के लिए विभिन्न योजनाएँ Git कमिट, शाखाओं और टैग के संदर्भ में उपलब्ध हैं।

छवियों को इकट्ठा करना आवेदन परिनियोजन का एक वैकल्पिक चरण है और इसे आपके स्वयं के इकट्ठे चित्रों की अनुपस्थिति में छोड़ दिया जा सकता है।

2. केवल एक मेजबान पर स्टेज स्टोरेज

वेयरफ ने चरणों के भंडारण की अवधारणा का परिचय दिया। निम्न प्रकार से मुख्य वेयरफ कमांड चरण भंडारण का उपयोग करते हैं:

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

एक एकल आवेदन को तैनात करते समय, सभी टीमों (विधानसभा, प्रकाशन, छवि सफाई, आवेदन परिनियोजन) के लिए एक एकल चरण भंडारण का उपयोग किया जाना चाहिए।

संस्करण 1.0 में, केवल स्थानीय होस्ट स्टोरेज एक स्टोरेज स्टोरेज के रूप में कार्य कर सकता है (कमांड के लिए संबंधित पैरामीटर है: - --stages-storage=:local )। उपयोग करते समय :local चरणों को डिस्क पर संग्रहीत किया जाता है। इसका परिणाम: werf 1.0 का उपयोग केवल एक होस्ट पर एक आवेदन की तैनाती को व्यवस्थित करने के लिए किया जा सकता है। यह होस्ट सही ढंग से काम करने के लिए वेयरफ के लिए कमांड लॉन्च के बीच डेटा को सहेजना चाहिए।

संस्करण 1.0 में, बाहरी भंडारण में चरणों के भंडारण के लिए कोई समर्थन नहीं है, जिसके साथ आप एक वितरित असेंबली का आयोजन कर सकते हैं। हालांकि, इस तरह के एक फ़ंक्शन वेयरफ के भविष्य के संस्करणों में दिखाई देगा (अधिक विवरण के लिए नीचे देखें) ।

3. एप्लिकेशन को रोल करें और उपलब्धता जांचें

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

वेयरफ़ ने कुबेरनेट्स में एप्लिकेशन लॉन्च किया और एक गारंटी प्रदान करता है कि यह शुरू होता है और आवेदन रोलआउट प्रक्रिया को पूरा करने से पहले। इसमें घटक लॉग का आउटपुट और रोलआउट त्रुटियों के लिए त्वरित प्रतिक्रिया शामिल है जब कुछ गलत हो गया - रोलआउट कमांड एक गैर-शून्य कोड के साथ छोड़ देगा। इस प्रकार, जब CI / CD में वेयरफ रोलआउट का उपयोग किया जाता है, तो हमें सॉफ़्टवेयर से पर्याप्त प्रतिक्रिया मिलती है : एप्लिकेशन डाउनलोड किया जाता है या नहीं, और डिबग और समस्याओं को ठीक करने के लिए पर्याप्त जानकारी है ( kubectl जैसी समस्याओं को खोजने के लिए अन्य उपयोगिताओं को चलाने के बिना)।

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

4. आवेदन वितरण प्रक्रिया के साथ एकत्र की गई छवियों का संबंध

वेयरफ ने एकत्र की गई छवियों को एक सिस्टम में एकीकृत किया, उन्हें कुबेरनेट्स को एप्लिकेशन पहुंचाने की प्रक्रिया के साथ टैग करने और उन्हें संस्करणित करने की प्रक्रिया। वेफ्स जो छवियाँ एकत्रित करती हैं उनका उपयोग कुबेरनेट्स संसाधन विवरण टेम्पलेट्स में किया जा सकता है।

यह इन कार्यों के कारण है कि हम कह सकते हैं कि हर्फ अलग से तैनात करने के लिए हेल्म, डॉकर और अन्य बिल्डरों और उपयोगिताओं की तुलना में एक उच्च स्तरीय इंटरफ़ेस प्रदान करता है । यह इंटरफ़ेस आपको किसी भी मौजूदा CI / CD सिस्टम में केवल werf को एकीकृत करने की अनुमति देता है और उपयोग किए गए सभी घटकों के संयोजन की समस्याओं को हल नहीं करता है - वह इस कार्य का ध्यान रखता है।

5. मौजूदा सीआई / सीडी सिस्टम के साथ एकीकरण

संस्करण 1.0 में, स्वचालित एकीकरण केवल GitLab CI सिस्टम के साथ उपलब्ध है । ऐसा करने के लिए, werf ci-env कमांड प्रदान किया गया है। यह CI / CD सिस्टम से आवश्यक जानकारी प्राप्त करता है और स्वचालित रूप से CI वातावरण में सही ढंग से काम करने के लिए werf को कॉन्फ़िगर करता है।

मैनुअल ( समीक्षा , GitLab CI बारीकियों , अन्य प्रणालियों के साथ एकीकरण ) में किसी भी CI / CD सिस्टम के साथ एकीकरण कैसे काम करता है, इसके बारे में आप अधिक पढ़ सकते हैं।

6. लिनक्स, विंडोज और मैकओएस के लिए क्रॉस-प्लेटफॉर्म विकास

werf 1.0 एक स्टैटिकली लिंक्ड बाइनरी फाइल है जो डॉकर और हेल्म दोनों रिलीज के साथ स्वतंत्र रूप से काम करती है। मेजबान प्रणाली पर बाहरी निर्भरता:

• स्थानीय डॉकर डेमॉन
• गिट उपयोगिता।

werf GNU / Linux, Windows, या macOS के किसी भी ऑपरेटिंग सिस्टम और वातावरण पर चल सकता है। इसके अलावा, असेंबली का परिणाम उपयोग किए गए सिस्टम की परवाह किए बिना समान होगा: कैश चरणों का समान हस्ताक्षर, चरणों का एक ही भरना, उस चरण की परवाह किए बिना जहां यह चरण एकत्र किया गया था। विभिन्न प्रणालियों में काम करने के लिए विन्यास में परिवर्तन की भी आवश्यकता नहीं होती है।

इस प्रकार, वेयरफ 1.0, कुबेरनेट्स को अनुप्रयोगों के निर्माण और वितरण के लिए क्रॉस-प्लेटफ़ॉर्म टूल प्रदान करता है।

यहां यह भी ध्यान दिया जाना चाहिए कि वेयरफ लिनक्स वातावरण में काम करने के लिए मानक डॉकर छवियां एकत्र करता है, लेकिन विंडोज कंटेनर संस्करण 1.0 में समर्थित नहीं हैं ।

7. परीक्षणों के साथ कार्यक्षमता को कवर करना

वर्तमान में 60% वेयरफ कोड एकीकरण e2e परीक्षणों और इकाई परीक्षणों द्वारा कवर किया गया है।

अपने लॉन्च को व्यवस्थित करने के लिए GitHub Actions का उपयोग करके सभी समर्थित OS (Linux, Windows और macOS) पर werf का परीक्षण किया गया है। कुछ परीक्षण विवरण कोड जलवायु पर भी उपलब्ध हैं।

8. वर्फ़िंग वेयरफ़

फिलहाल, 1.0 संस्करण की रिलीज के द्वारा, परियोजना में लगभग 700 रिलीज किए गए हैं।

एरेस स्थिरता चैनलों के साथ एक उन्नत रिलीज सिस्टम का उपयोग करता है: अल्फा , बीटा , ईई (प्रारंभिक पहुंच) , स्थिर और रॉक-सॉलिड । यह पोस्ट स्थिर चैनल में पहले संस्करण 1.0 की रिलीज के साथ मेल खाने के लिए समयबद्ध है। संस्करण में अस्थिर परिवर्तन पहले चैनलों की एक श्रृंखला के माध्यम से जाते हैं और अंततः रॉक-सॉलिड में समाप्त होते हैं । रिलीज़ अक्सर किए जाते हैं (कभी-कभी प्रति दिन कई) और परिवर्तन "छोटे हिस्से" में लगातार वितरित किए जाते हैं।

स्थिरता चैनल और कई लगातार रिलीज आपको नए परिवर्तनों पर निरंतर प्रतिक्रिया प्राप्त करने की अनुमति देते हैं, जल्दी से उन्हें वापस रोल करने की क्षमता और आमतौर पर सॉफ्टवेयर की उच्च स्थिरता सुनिश्चित करते हैं और एक ही समय में इसके विकास की स्वीकार्य गति।

महत्वपूर्ण बिंदु यह है कि संस्करण 1.0-> 1.1, 1.1-> 1.2 के बीच स्विच करते समय, वेयरफ़ में परिवर्तन संभव है जो उपयोगकर्ता द्वारा मैन्युअल हस्तक्षेप की आवश्यकता होती है (यह एक माइग्रेशन स्क्रिप्ट हो सकती है या रिलीज में वर्णित मैनुअल निष्पादन के लिए निर्देश)। 1.0 (1.0.1, 1.0.2, ... 1.0.6-अल्फा.1, 1.0.6-बीटा.2, आदि) के अंदर संस्करणों को अपडेट करना सुनिश्चित करता है कि इस तरह के मैनुअल बदलाव की आवश्यकता नहीं है।

आप पिछड़े अनुकूलता वादे के बारे में अधिक यहाँ पढ़ सकते हैं।

आगे की योजना

भविष्य के संस्करणों के लिए कार्य के मुख्य प्रमुख क्षेत्र क्या हैं जैसे उनके कार्यान्वयन के लिए अनुमानित और अनुमानित शर्तें:

1. स्थानीय विकास और वेयरफ के साथ अनुप्रयोगों की तैनाती

मुख्य लक्ष्य दोनों स्थानीय स्तर पर और उत्पादन में, जटिल कार्यों के बिना, बॉक्स से बाहर अनुप्रयोगों को तैनात करने के लिए एक एकीकृत विन्यास प्राप्त करना है।

Werf को ऑपरेशन के एक मोड की भी आवश्यकता होती है, जिसमें एप्लिकेशन कोड को संपादित करना और डिबगिंग के लिए काम कर रहे एप्लिकेशन से तुरंत प्रतिक्रिया प्राप्त करना सुविधाजनक होगा।

संस्करण 1.1, जनवरी-फरवरी 2020

2. सामग्री-आधारित टैगिंग

जब वे प्रकाशित होते हैं तो छवियों को टैग करना, केवल इस छवि की सामग्री पर आधारित होता है। बाइंडिंग के साथ मोड के विपरीत गिट हिट करता है, इस मोड से पूरी तरह से अनावश्यक पुनर्निर्माण से छुटकारा मिल जाएगा। गिट-कमिट-आईडी वर्कट्री सामग्री के लिए एक सार्वभौमिक पहचानकर्ता नहीं है (हालांकि यह इस पर निर्भर करता है)।

उस स्थिति में जहां एप्लिकेशन कोड नहीं बदला गया है, लेकिन एक नई प्रतिबद्धता बनाई गई है, गिट कमिट के लिए वर्तमान टैगिंग मोड प्रकाशित होने पर एक नया नाम के साथ एक छवि बनाएगा। यह कुबेरनेट्स में इस छवि का उपयोग करके संसाधनों का एक रोलबैक भी करेगा। उसी समय, छवि की सामग्री स्वयं नहीं बदली।

इन समस्याओं को हल करने के लिए, वेयरफ एप्लीकेशन सामग्री के चेकसम की गणना के आधार पर एक नए प्रकार की टैगिंग का परिचय देंगे - सामग्री-आधारित टैगिंग ।

संस्करण 1.1, फरवरी-मार्च 2020

3. हेल्म 3 में संक्रमण

इसमें नए हेल्म 3 कोड बेस में संक्रमण और मौजूदा प्रतिष्ठानों को स्थानांतरित करने का एक सिद्ध, सुविधाजनक तरीका शामिल है।

संस्करण 1.1, फरवरी-मार्च 2020

4. छवियों की समानांतर विधानसभा

फिलहाल, werf 1.0 सभी श्रेणियों के चित्र और कलाकृतियों को werf.yaml क्रमिक रूप से घोषित werf.yaml है। मंच विधानसभा प्रक्रिया को समानांतर करने की क्षमता की आवश्यकता है।

संस्करण: 1.1, जनवरी-फरवरी 2020

5. छवियों की असेंबली वितरित

फिलहाल, werf 1.0 को केवल एक समर्पित होस्ट पर इस्तेमाल किया जा सकता है (केवल एक होस्ट पर स्टेज स्टोरेज के बारे में ऊपर की बात देखें) ।

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

पहले, जब वेयरफ प्रोजेक्ट को डैप भी कहा जाता था, तो ऐसा अवसर था। हालाँकि, हमें कई समस्याओं का सामना करना पड़ा, जिन्हें इस फ़ंक्शन को werf में लागू करते समय विचार किया जाना चाहिए।

संस्करण 1.2: मार्च-अप्रैल 2020

6. कुबेरनेट्स विन्यास का वर्णन करने के लिए Jsonnet

Jfnet प्रारूप में Kubernetes के लिए विन्यास विवरण का समर्थन करेगा। उसी समय, हर्फ हेम के साथ संगत रहेगा और विवरण प्रारूप का चयन करना संभव होगा।

कारण यह है कि कई लोगों के अनुसार, गो भाषा के टेम्प्लेट में एक बड़ी प्रविष्टि सीमा होती है, और इन टेम्प्लेट की कोड इंटेलीजेंसी भी ग्रस्त होती है।

कुबेरनेट विन्यास विवरण प्रणाली (जैसे कि कस्टमाइज़) को लागू करने के अन्य विकल्पों पर भी विचार किया जा रहा है।

संस्करण 1.1: जनवरी-फरवरी 2020

7. कुबेरनेट्स के अंदर काम करना

उद्देश्य: कुबेरनेट्स में धावकों का उपयोग करके छवियों और आवेदन वितरण की विधानसभा सुनिश्चित करना। यानी नई छवियों, उनके प्रकाशन, सफाई और परिनियोजन का संयोजन सीधे कुबेरनेट्स पॉड्स से हो सकता है।

इस सुविधा का एहसास करने के लिए, आपको सबसे पहले वितरित तरीके से छवियों को वितरित करने की क्षमता की आवश्यकता है (ऊपर पैराग्राफ देखें) ।

इसे डॉकर डेमॉन के बिना ऑपरेशन के बिल्ड मोड के लिए समर्थन की आवश्यकता होती है (यानी, एक कनीको जैसा निर्माण या उपयोगकर्ता में निर्माण )।

वेयरफ कुबेरनेट्स का निर्माण न केवल डोकरफाइल के साथ करेगा, बल्कि इसके स्टेपल बिल्डर के साथ वृद्धिशील पुनर्निर्माण भी करेगा।

संस्करण 1.2: अप्रैल-मई 2020

8. अन्य

यह भी योजनाबद्ध है:

• अन्सिबल वर्जन अपग्रेड और अन्सिबल के विभिन्न संस्करणों का उपयोग करने की क्षमता;
• ansible भूमिकाओं के लिए समर्थन;
• स्टेपल में मनमाने ढंग से विधानसभा चरणों के लिए समर्थन (वर्तमान में werf चरणों का एक स्थिर सेट का समर्थन करता है: beforeInstall , install , beforeSetup , setup , setup );
• बेहतर werf.yaml सिंटैक्स, werf.yaml स्विच करना configVersion: 2 (जुड़े हुए हैं, दो अन्य बिंदुओं के साथ अंतर), OpenAPI विनिर्देश के लिए समर्थन;
• Git में बड़ी फ़ाइलों को संग्रहीत करने के लिए स्टेपल में Git LFS का समर्थन;
• छवि सफाई तंत्र में सुधार (वर्तमान संस्करण में गैर-महत्वपूर्ण खामियां मुख्य मास्टर शाखा में werf.yaml कॉन्फ़िगरेशन में घोषित नहीं की गई छवियों से जुड़ी हैं - इन छवियों को आवधिक सफाई द्वारा हटा दिया जाएगा);
• साझा कुबेरनेट नामस्थान के साथ अधिक सही कार्य, जब एक नाम स्थान में कई एप्लिकेशन तैनात किए जाते हैं;
• असफल तैनाती के मामले में नवीनतम कार्यशील संस्करण के लिए आवेदन का स्वचालित रोलबैक।

कुल मिलाकर

संक्षेप में संक्षेप में बताऊंगा। हम हैं:

• लंबे संस्करण 1.0 के आगमन के लिए चला गया;
• वास्तविक अनुभव का एक बहुत ध्यान में रखा;
• हम स्थिर कार्यक्षमता के साथ एक सिद्ध उपयोगिता का उपयोग करने के लिए प्रस्तुत करते हैं, हजारों रोलआउट द्वारा सत्यापित।

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

पुनश्च

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

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