👐 🎷 🤾 Werf 1.1 जारी: आज कलेक्टर में सुधार और भविष्य के लिए योजना 🤲🏾 🏁 🙋🏿

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

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

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

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

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

क्या बदल गया है?

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

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

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

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

... या सामान्य रूप में:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

यहाँ:

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

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

Werf कुछ चरण के हस्ताक्षर की गणना करता है।
में चरणों भंडारण , वहाँ एक दिया हस्ताक्षर के लिए कई चरणों हो सकता है। Werf उन सभी चरणों का चयन करता है जो हस्ताक्षर के लिए उपयुक्त हैं।
वर्तमान चरण Git से संबद्ध है (Git-संग्रह, उपयोगकर्ता कदम ग Git-पैच: install, beforeSetup, setup, या Git-नवीनतम पैच), तो चयन केवल उन कदमों जो प्रतिबद्ध करने के लिए है, जो (वर्तमान के पूर्वज प्रतिबद्ध है संबंधित Werf जिसके लिए विधानसभा का कारण बना )
शेष उपयुक्त चरणों में से, एक का चयन किया जाता है - निर्माण की तारीख तक सबसे पुराना।

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

→ प्रलेखन ।

मंच भंडारण में चरणों को बनाने और बचाने के लिए नया एल्गोरिदम

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

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

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

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

→ प्रलेखन ।

Dockerfile कलेक्टर प्रदर्शन में सुधार

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

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

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

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

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

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

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

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

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

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

इस छवि की सामग्री;
इस सामग्री का नेतृत्व करने वाले इतिहास में संशोधन करें।

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

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

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

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

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

लॉगिंग स्तर

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

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

विस्तृत आउटपुट ( --log-verbose) का उपयोग करते समय , आप यह पता लगा सकते हैं कि वेयरफ कैसे काम करता है: वेयरफ की डीबग जानकारी के अलावा,

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

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

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

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

संस्करण: v1.1
दिनांक: मार्च
मुद्दा

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

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

डिफ़ॉल्ट (पुस्तकालय / रजिस्ट्री) *,
AWS ईसीआर,
Azure *,
डॉकटर हब
जीसीआर *,
गीथूब पैकेज
GitLab रजिस्ट्री *,
बंदरगाह *,
क्वे।

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

दो मुख्य समस्याओं को प्रतिष्ठित किया जा सकता है:

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

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

वितरित छवि असेंबली (↑)

: ~~v1.2~~ v1.1 ( )
: -
Issue

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

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

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

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

आधिकारिक GitHub कार्य समर्थन (नया)

संस्करण: v1.1
दिनांक: मार्च
मुद्दा

इसमें werf प्रलेखन ( संदर्भ और मार्गदर्शक अनुभाग ), साथ ही werf के साथ काम करने के लिए आधिकारिक GitHub एक्शन भी शामिल है।

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

CI सिस्टम के साथ उपयोगकर्ता इंटरैक्शन के मैकेनिक्स एप्लिकेशन को बनाने / रोल करने के लिए कुछ कार्यों को शुरू करने के लिए पुल अनुरोधों पर लेबल लगाने पर आधारित होंगे।

स्थानीय अनुप्रयोग विकास और हर्फ के साथ तैनाती (loyment)

संस्करण: v1.1
तारीखें: ~~जनवरी-फरवरी~~ अप्रैल
मुद्दा

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

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

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

संस्करण: v1.1
दिनांक: अप्रैल
मुद्दा

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

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

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

एन 2 से जुड़ी एन 1 छवियों से अधिक स्टोर न करें, प्रत्येक जीआईटी हेड (शाखाएं और टैग) के लिए अंतिम रूप देता है।
एन 2 से जुड़े एन 1 छवियों-चरणों से अधिक स्टोर न करें, प्रत्येक जीआईटी हेड (शाखाएं और टैग) के लिए अंतिम कमिट करता है।
, - Kubernetes ( kube- namespace'; ).
, , Helm-.
, HEAD git (, HEAD ) Kubernetes Helm.

(↓)

: v1.1
: - *

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

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

हेल्म 3 पर स्विच करें (()

संस्करण: v1.2
दिनांक: ~~फरवरी-मार्च~~ *

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

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

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

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

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

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

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

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

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

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

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

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

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

ओपन सोर्स डेवलपमेंट की दिशा में कदम

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

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

मुद्दों के साथ बहुत काम किया गया है:

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

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

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

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

निष्कर्ष

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

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

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

खबर का पालन करें! और एक मुद्दा बनाने के लिए हमारे गीथहब द्वारा ड्रॉप करने के लिए मत भूलना , एक मौजूदा एक ढूंढें और एक प्लस लगाएं, एक पीआर बनाएं या बस परियोजना के विकास को देखें।

पुनश्च

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

« werf 1.0 stable: GitOps, »
«werf — CI/CD Kubernetes ( )»;
werf:
- «3-way merge werf: Kubernetes Helm „ “»;
- « werf Helm-»;
- « monorepo multirepo werf Docker Registry»;
- « Docker- werf Dockerfile».

Werf 1.1 जारी: आज कलेक्टर में सुधार और भविष्य के लिए योजना