वेयरफ़ 1.1 रिलीज़: बिल्डर में आज सुधार और भविष्य के लिए योजनाएँ

Werf कुबेरनेट्स के लिए एप्लिकेशन बनाने और वितरित करने के लिए हमारी ओपन सोर्स GitOps CLI उपयोगिता है। वादे के अनुसार, संस्करण v1.0 का विमोचन वेयरफ़ में नई सुविधाएँ जोड़ने और पारंपरिक दृष्टिकोण को संशोधित करने की शुरुआत हुई। अब हम रिलीज़ v1.1 प्रस्तुत करते हुए प्रसन्न हैं, जो विकास में एक बड़ा कदम है और भविष्य के लिए एक आधार है एकत्र करनेवाला वेयरफ़. संस्करण वर्तमान में उपलब्ध है चैनल 1.1 ईए.

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

कार्य के अनुकूलन में चरण हस्ताक्षरों की गणना के चरण में अनावश्यक गणनाओं से छुटकारा पाना और फ़ाइल चेकसम की गणना के लिए तंत्र को अधिक कुशल में बदलना शामिल है। यह अनुकूलन वेयरफ़ का उपयोग करके प्रोजेक्ट निर्माण के औसत समय को कम कर देता है। और निष्क्रिय बिल्ड, जब सभी चरण कैश में मौजूद होते हैं चरण-भंडारण, अब वास्तव में तेज़ हैं। अधिकांश मामलों में, बिल्ड को पुनः आरंभ करने में 1 सेकंड से भी कम समय लगेगा! यह टीमों के काम की प्रक्रिया में चरणों के सत्यापन की प्रक्रियाओं पर भी लागू होता है। werf deploy и werf run.

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

आइए werf v1.1 में प्रमुख नवाचारों पर करीब से नज़र डालें और साथ ही आपको भविष्य की योजनाओं के बारे में भी बताएं।

वेयरफ़ v1.1 में क्या परिवर्तन हुआ है?

कैश से चरणों का चयन करने के लिए नया चरण नामकरण प्रारूप और एल्गोरिदम

नया चरण नाम निर्माण नियम. अब प्रत्येक चरण का निर्माण एक अद्वितीय चरण नाम उत्पन्न करता है, जिसमें 2 भाग होते हैं: एक हस्ताक्षर (जैसा कि यह v1.0 में था) और एक अद्वितीय अस्थायी पहचानकर्ता।

उदाहरण के लिए, पूर्ण चरण छवि का नाम इस तरह दिख सकता है:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...या सामान्य तौर पर:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Здесь:

• SIGNATURE एक स्टेज हस्ताक्षर है, जो स्टेज सामग्री के पहचानकर्ता का प्रतिनिधित्व करता है और Git में संपादन के इतिहास पर निर्भर करता है जिसके कारण यह सामग्री प्राप्त हुई;
• TIMESTAMP_MILLISEC एक गारंटीकृत अद्वितीय छवि पहचानकर्ता है जो एक नई छवि के निर्माण के समय उत्पन्न होता है।

कैश से चरणों का चयन करने के लिए एल्गोरिदम Git कमिट के संबंध की जाँच पर आधारित है:

1. Werf एक निश्चित चरण के हस्ताक्षर की गणना करता है।
2. В चरण-भंडारण किसी दिए गए हस्ताक्षर के लिए कई चरण हो सकते हैं। Werf हस्ताक्षर से मेल खाने वाले सभी चरणों का चयन करता है।
3. यदि वर्तमान चरण Git से जुड़ा हुआ है (git-संग्रह, Git पैच के साथ कस्टम चरण: install, beforeSetup, setup; या git-latest-patch), तो werf केवल उन चरणों का चयन करता है जो एक कमिट से जुड़े होते हैं जो वर्तमान कमिट का पूर्वज है (जिसके लिए बिल्ड कहा जाता है)।
4. शेष उपयुक्त चरणों में से, एक का चयन किया जाता है - निर्माण तिथि के अनुसार सबसे पुराना।

विभिन्न Git शाखाओं के लिए एक चरण में एक ही हस्ताक्षर हो सकता है। लेकिन वेयरफ़ विभिन्न शाखाओं से जुड़े कैश को इन शाखाओं के बीच उपयोग करने से रोक देगा, भले ही हस्ताक्षर मेल खाते हों।

→ दस्तावेज़ीकरण.

स्टेज स्टोरेज में स्टेज बनाने और सहेजने के लिए नया एल्गोरिदम

यदि, कैश से चरणों का चयन करते समय, वेयरफ़ को उपयुक्त चरण नहीं मिलता है, तो एक नए चरण को असेंबल करने की प्रक्रिया शुरू की जाती है।

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

ताज़ा इकट्ठी की गई छवि में एक विशिष्ट पहचानकर्ता होने की गारंटी होती है TIMESTAMP_MILLISEC (नया चरण नामकरण प्रारूप देखें). मामले में चरण-भंडारण एक उपयुक्त छवि मिल जाएगी, वेयरफ़ ताज़ा संकलित छवि को हटा देगा और कैश से छवि का उपयोग करेगा।

दूसरे शब्दों में: छवि का निर्माण पूरा करने की पहली प्रक्रिया (सबसे तेज़ प्रक्रिया) को इसे चरण-भंडारण में संग्रहीत करने का अधिकार मिलेगा (और फिर यह एकल छवि है जिसका उपयोग सभी निर्माणों के लिए किया जाएगा)। एक धीमी निर्माण प्रक्रिया कभी भी तेज़ प्रक्रिया को वर्तमान चरण के निर्माण परिणामों को सहेजने और अगले निर्माण पर जाने से नहीं रोकेगी।

→ दस्तावेज़ीकरण.

बेहतर डॉकरफ़ाइल बिल्डर प्रदर्शन

फिलहाल, डॉकरफ़ाइल से निर्मित छवि के लिए चरणों की पाइपलाइन में एक चरण होता है - dockerfile. हस्ताक्षर की गणना करते समय, फ़ाइलों के चेकसम की गणना की जाती है context, जिसका उपयोग असेंबली के दौरान किया जाएगा। इस सुधार से पहले, वेयरफ़ सभी फ़ाइलों के माध्यम से पुनरावर्ती रूप से चलता था और प्रत्येक फ़ाइल के संदर्भ और मोड को जोड़कर एक चेकसम प्राप्त करता था। V1.1 से शुरू करके, werf Git रिपॉजिटरी में संग्रहीत गणना किए गए चेकसम का उपयोग कर सकता है।

एल्गोरिदम पर आधारित है गिट एलएस-ट्री. एल्गोरिदम रिकॉर्ड को ध्यान में रखता है .dockerignore और आवश्यक होने पर ही फ़ाइल ट्री को पुनरावर्ती रूप से ट्रैवर्स करता है। इस प्रकार, हमने फ़ाइल सिस्टम को पढ़ने और आकार पर एल्गोरिदम की निर्भरता को अलग कर दिया है context महत्वपूर्ण नहीं है.

एल्गोरिदम अनट्रैक की गई फ़ाइलों की भी जांच करता है और यदि आवश्यक हो, तो उन्हें चेकसम में ध्यान में रखता है।

फ़ाइलें आयात करते समय प्रदर्शन में सुधार हुआ

werf v1.1 के संस्करण rsync सर्वर का उपयोग करते हैं जब कलाकृतियों और छवियों से फ़ाइलें आयात करना. पहले, होस्ट सिस्टम से डायरेक्टरी माउंट का उपयोग करके आयात दो चरणों में किया जाता था।

MacOS पर आयात प्रदर्शन अब डॉकर वॉल्यूम द्वारा सीमित नहीं है, और आयात Linux और Windows के समान समय में पूरा हो जाता है।

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

Werf v1.1 छवि सामग्री द्वारा तथाकथित टैगिंग का समर्थन करता है - सामग्री-आधारित टैगिंग. परिणामी डॉकर छवियों के टैग इन छवियों की सामग्री पर निर्भर करते हैं।

कमांड चलाते समय werf publish --tags-by-stages-signature या werf ci-env --tagging-strategy=stages-signature तथाकथित की प्रकाशित छवियाँ मंच पर हस्ताक्षर छवि। प्रत्येक छवि को इस छवि के चरणों के अपने स्वयं के हस्ताक्षर के साथ टैग किया जाता है, जिसकी गणना प्रत्येक चरण के नियमित हस्ताक्षर के समान नियमों के अनुसार अलग-अलग की जाती है, लेकिन यह छवि का एक सामान्य पहचानकर्ता है।

छवि चरणों का हस्ताक्षर इस पर निर्भर करता है:

1. इस छवि की सामग्री;
2. Git परिवर्तनों का इतिहास जिसके कारण यह सामग्री प्राप्त हुई।

Git रिपॉजिटरी में हमेशा डमी कमिट होते हैं जो छवि फ़ाइलों की सामग्री को नहीं बदलते हैं। उदाहरण के लिए, केवल टिप्पणियों के साथ कमिट करता है या मर्ज कमिट करता है, या कमिट करता है जो Git में उन फ़ाइलों को बदलता है जिन्हें छवि में आयात नहीं किया जाएगा।

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

इसके अलावा, सामग्री-आधारित टैगिंग Git शाखाओं पर टैगिंग की तुलना में अधिक विश्वसनीय टैगिंग विधि है, क्योंकि परिणामी छवियों की सामग्री उस क्रम पर निर्भर नहीं करती है जिसमें एक ही शाखा के कई कमिटों को इकट्ठा करने के लिए CI प्रणाली में पाइपलाइनों को निष्पादित किया जाता है।

यह महत्वपूर्ण है: अभी से शुरू चरण-हस्ताक्षर - क्या एकमात्र अनुशंसित टैगिंग रणनीति. इसका उपयोग कमांड में डिफ़ॉल्ट रूप से किया जाएगा werf ci-env (जब तक आप स्पष्ट रूप से एक अलग टैगिंग योजना निर्दिष्ट नहीं करते)।

→ दस्तावेज़ीकरण. इस सुविधा के लिए एक अलग प्रकाशन भी समर्पित किया जाएगा। अद्यतन (अप्रैल 3): विवरण सहित लेख प्रकाशित.

लॉगिंग स्तर

उपयोगकर्ता के पास अब आउटपुट को नियंत्रित करने, लॉगिंग स्तर सेट करने और डिबगिंग जानकारी के साथ काम करने का अवसर है। विकल्प जोड़े गए --log-quiet, --log-verbose, --log-debug.

डिफ़ॉल्ट रूप से, आउटपुट में न्यूनतम जानकारी होती है:

वर्बोज़ आउटपुट का उपयोग करते समय (--log-verbose) आप देख सकते हैं कि वेयरफ़ कैसे काम करता है:

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

आगे की योजना

चेतावनी! नीचे वर्णित विकल्प चिन्हित हैं v1.1 निकट भविष्य में उनमें से कई इस संस्करण में उपलब्ध हो जाएंगे। अपडेट ऑटो-अपडेट के माध्यम से आएंगे मल्टीवर्फ का उपयोग करते समय. ये सुविधाएँ v1.1 फ़ंक्शंस के स्थिर भाग को प्रभावित नहीं करती हैं; उनकी उपस्थिति के लिए मौजूदा कॉन्फ़िगरेशन में मैन्युअल उपयोगकर्ता के हस्तक्षेप की आवश्यकता नहीं होगी।

विभिन्न डॉकर रजिस्ट्री कार्यान्वयन के लिए पूर्ण समर्थन (नया)

• संस्करण: v1.1
• तिथियाँ: मार्च
• मुद्दा

लक्ष्य यह है कि उपयोगकर्ता वेयरफ़ का उपयोग करते समय बिना किसी प्रतिबंध के कस्टम कार्यान्वयन का उपयोग करें।

वर्तमान में, हमने समाधानों के निम्नलिखित सेट की पहचान की है जिसके लिए हम पूर्ण समर्थन की गारंटी देने जा रहे हैं:

• डिफ़ॉल्ट (लाइब्रेरी/रजिस्ट्री)*,
• एडब्ल्यूएस ईसीआर
• नीला*,
• डॉकर हब
• जीसीआर*,
• गिटहब पैकेज
• गिटलैब रजिस्ट्री*,
• बंदरगाह*,
• क्वे.

जो समाधान वर्तमान में वेयर्फ़ द्वारा पूरी तरह से समर्थित हैं, उन्हें तारांकन चिह्न से चिह्नित किया गया है। दूसरों के लिए समर्थन है, लेकिन सीमाओं के साथ।

दो मुख्य समस्याओं की पहचान की जा सकती है:

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

हम समाधानों के मूल एपीआई का उपयोग करके इन और अन्य समस्याओं को हल करने जा रहे हैं। इस कार्य में उनमें से प्रत्येक के लिए परीक्षणों के साथ वेयरफ़ ऑपरेशन के पूरे चक्र को कवर करना भी शामिल है।

वितरित छवि निर्माण (↑)

• संस्करण: v1.2 v1.1 (इस सुविधा को लागू करने की प्राथमिकता बढ़ा दी गई है)
• तिथियाँ: मार्च-अप्रैल मार्च
• मुद्दा

फिलहाल, werf v1.0 और v1.1 का उपयोग छवियों के निर्माण और प्रकाशन के संचालन और कुबेरनेट्स पर एप्लिकेशन को तैनात करने के लिए केवल एक समर्पित होस्ट पर किया जा सकता है।

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

पहले, जब वेयरफ़ परियोजना को अभी भी डैप कहा जाता था, तब उसके पास ऐसा अवसर था। हालाँकि, हमें कई मुद्दों का सामना करना पड़ा है जिन्हें वेयरफ़ में इस कार्यक्षमता को लागू करते समय ध्यान में रखा जाना चाहिए।

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

GitHub क्रियाओं के लिए आधिकारिक समर्थन (नया)

• संस्करण: v1.1
• तिथियाँ: मार्च
• मुद्दा

वेयर्फ़ दस्तावेज़ीकरण (अनुभाग) शामिल हैं संदर्भ и गाइड), साथ ही वेयरफ़ के साथ काम करने के लिए आधिकारिक GitHub एक्शन।

इसके अलावा, यह वेयर्फ़ को अल्पकालिक धावकों पर काम करने की अनुमति देगा।

सीआई प्रणाली के साथ उपयोगकर्ता की बातचीत की यांत्रिकी एप्लिकेशन को बनाने/रोल आउट करने के लिए कुछ कार्रवाई शुरू करने के लिए पुल अनुरोधों पर लेबल लगाने पर आधारित होगी।

वेयरफ़ के साथ अनुप्रयोगों का स्थानीय विकास और परिनियोजन (↓)

• संस्करण: v1.1
• तिथियाँ: जनवरी-फरवरी अप्रैल
• मुद्दा

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

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

नया सफाई एल्गोरिदम (नया)

• संस्करण: v1.1
• तिथियाँ: अप्रैल
• मुद्दा

प्रक्रिया में werf v1.1 के वर्तमान संस्करण में cleanup सामग्री-आधारित टैगिंग योजना के लिए छवियों को साफ़ करने का कोई प्रावधान नहीं है - ये छवियां जमा हो जाएंगी।

इसके अलावा, वेयरफ़ का वर्तमान संस्करण (v1.0 और v1.1) टैगिंग योजनाओं के तहत प्रकाशित छवियों के लिए विभिन्न सफाई नीतियों का उपयोग करता है: Git शाखा, Git टैग या Git कमिट।

सभी टैगिंग योजनाओं के लिए एकीकृत, Git में कमिट के इतिहास के आधार पर छवियों की सफाई के लिए एक नया एल्गोरिदम का आविष्कार किया गया है:

• प्रत्येक git HEAD (शाखाओं और टैग) के लिए N1 के सबसे हालिया कमिट से जुड़ी N2 छवियों से अधिक न रखें।
• प्रत्येक git HEAD (शाखाओं और टैग) के लिए N1 के सबसे हालिया कमिट से जुड़ी N2 स्टेज छवियों से अधिक को स्टोर न करें।
• किसी भी कुबेरनेट्स क्लस्टर संसाधनों में उपयोग की जाने वाली सभी छवियों को संग्रहीत करें (कॉन्फ़िगरेशन फ़ाइल और नेमस्पेस के सभी क्यूब संदर्भ स्कैन किए गए हैं; आप इस व्यवहार को विशेष विकल्पों के साथ सीमित कर सकते हैं)।
• हेल्म रिलीज़ में सहेजे गए संसाधन कॉन्फ़िगरेशन मैनिफ़ेस्ट में उपयोग की जाने वाली सभी छवियों को संग्रहीत करें।
• एक छवि को हटाया जा सकता है यदि वह git से किसी HEAD से संबद्ध नहीं है (उदाहरण के लिए, क्योंकि संबंधित HEAD को स्वयं हटा दिया गया था) और Kubernetes क्लस्टर और हेल्म रिलीज़ में किसी भी मैनिफ़ेस्ट में इसका उपयोग नहीं किया गया है।

समानांतर छवि निर्माण (↓)

• संस्करण: v1.1
• तिथियाँ: जनवरी-फरवरी अप्रैल*

वेयरफ़ का वर्तमान संस्करण वर्णित छवियों और कलाकृतियों को एकत्रित करता है werf.yaml, क्रमिक रूप से। छवियों और कलाकृतियों के स्वतंत्र चरणों को इकट्ठा करने की प्रक्रिया को समानांतर करना, साथ ही सुविधाजनक और सूचनात्मक आउटपुट प्रदान करना आवश्यक है।

* नोट: वितरित असेंबली को लागू करने के लिए बढ़ी हुई प्राथमिकता के कारण समय सीमा को स्थानांतरित कर दिया गया है, जो अधिक क्षैतिज स्केलिंग क्षमताओं को जोड़ देगा, साथ ही GitHub क्रियाओं के साथ वेयरफ़ का उपयोग भी करेगा। समानांतर असेंबली अगला अनुकूलन चरण है, जो एक प्रोजेक्ट को असेंबल करते समय ऊर्ध्वाधर स्केलेबिलिटी प्रदान करता है।

हेल्म 3 में संक्रमण (↓)

• संस्करण: v1.2
• तिथियाँ: फरवरी-मार्च मई*

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

* नोट: हेल्म 3 पर स्विच करने से वेयरफ़ में महत्वपूर्ण सुविधाएँ नहीं जुड़ेंगी, क्योंकि हेल्म 3 की सभी प्रमुख विशेषताएँ (3-वे-मर्ज और नो टिलर) पहले से ही वेयरफ़ में लागू हैं। इसके अलावा, वेयरफ़ के पास है अतिरिक्त सुविधाये संकेतित के अतिरिक्त. हालाँकि, यह परिवर्तन हमारी योजनाओं में बना हुआ है और इसे लागू किया जाएगा।

कुबेरनेट्स कॉन्फ़िगरेशन का वर्णन करने के लिए Jsonnet (↓)

• संस्करण: v1.2
• तिथियाँ: जनवरी-फरवरी अप्रैल-मई

Werf Jsonnet प्रारूप में Kubernetes के लिए कॉन्फ़िगरेशन विवरण का समर्थन करेगा। साथ ही, वेयरफ़ हेल्म के साथ संगत रहेगा और विवरण प्रारूप का विकल्प होगा।

इसका कारण यह है कि कई लोगों के अनुसार, गो टेम्प्लेट में उच्च प्रवेश बाधा होती है, और इन टेम्प्लेट के कोड की समझ में भी कमी आती है।

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

कुबेरनेट्स के अंदर काम करना (↓)

• संस्करण: v1.2
• तिथियाँ: अप्रैल-मई मई-जून

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

इस क्षमता को लागू करने के लिए, आपको सबसे पहले वितरित छवियां बनाने में सक्षम होना होगा (ऊपर बिंदु देखें).

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

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

खुले विकास की ओर एक कदम

हम अपने समुदाय से प्यार करते हैं (GitHub, Telegram) और हम चाहते हैं कि अधिक से अधिक लोग वेयरफ़ को बेहतर बनाने में मदद करें, हम जिस दिशा में आगे बढ़ रहे हैं उसे समझें और विकास में भाग लें।

हाल ही में इस पर स्विच करने का निर्णय लिया गया GitHub प्रोजेक्ट बोर्ड ताकि हमारी टीम की कार्यप्रणाली का पता चल सके। अब आप निम्नलिखित क्षेत्रों में तात्कालिक योजनाओं के साथ-साथ वर्तमान कार्य भी देख सकते हैं:

• दस्तावेज़ीकरण और साइट;
• परीक्षण;
• बग और ख़राब UX;
• 1.1.

मुद्दों पर बहुत काम किया गया है:

• अप्रासंगिक हटा दिए गए.
• मौजूदा को पर्याप्त संख्या में विवरण और विवरण के साथ एक ही प्रारूप में लाया गया है।
• विचारों और सुझावों के साथ नए मुद्दे जोड़े गए हैं।

संस्करण v1.1 को कैसे सक्षम करें

संस्करण वर्तमान में उपलब्ध है चैनल 1.1 ईए (चैनलों में स्थिर и ठोस चट्टान हालाँकि, स्थिरीकरण होते ही रिलीज़ दिखाई देंगी ea स्वयं उपयोग के लिए पहले से ही पर्याप्त रूप से स्थिर है, क्योंकि चैनलों के माध्यम से चला गया अल्फा и बीटा). सक्रिय मल्टीवर्फ के माध्यम से इस अनुसार:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

निष्कर्ष

स्टेपल और डॉकरफाइल बिल्डरों के लिए नए स्टेज स्टोरेज आर्किटेक्चर और बिल्डर ऑप्टिमाइज़ेशन से वेयरफ़ में वितरित और समानांतर बिल्ड को लागू करने की संभावना खुलती है। ये सुविधाएँ जल्द ही उसी v1.1 रिलीज़ में दिखाई देंगी और ऑटो-अपडेट तंत्र (उपयोगकर्ताओं के लिए) के माध्यम से स्वचालित रूप से उपलब्ध हो जाएंगी मल्टीवर्फ).

इस रिलीज़ में, छवि सामग्री पर आधारित एक टैगिंग रणनीति जोड़ी गई है - सामग्री-आधारित टैगिंग, जो डिफ़ॉल्ट रणनीति बन गई है। मुख्य कमांड लॉग पर भी दोबारा काम किया गया है: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

अगला महत्वपूर्ण कदम वितरित असेंबली को जोड़ना है। वितरित बिल्ड v1.0 के बाद से समानांतर बिल्ड की तुलना में उच्च प्राथमिकता बन गए हैं क्योंकि वे वेयरफ़ में अधिक मूल्य जोड़ते हैं: बिल्डरों की ऊर्ध्वाधर स्केलिंग और विभिन्न सीआई/सीडी प्रणालियों में अल्पकालिक बिल्डरों के लिए समर्थन, साथ ही GitHub क्रियाओं के लिए आधिकारिक समर्थन बनाने की क्षमता . इसलिए, समानांतर असेंबली के लिए कार्यान्वयन की समय सीमा स्थानांतरित कर दी गई। हालाँकि, हम दोनों संभावनाओं को जल्द से जल्द लागू करने के लिए काम कर रहे हैं।

समाचार का पालन करें! और हमसे मिलने आना न भूलें GitHubकोई समस्या पैदा करने के लिए, कोई मौजूदा समस्या ढूंढें और उसमें एक प्लस जोड़ें, एक पीआर बनाएं, या बस परियोजना के विकास को देखें।

पुनश्च

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

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

स्रोत: www.habr.com