werf 1.1 प्रकाशन: आज बिल्डर सुधारणा आणि भविष्यासाठी योजना

werf Kubernetes ला ऍप्लिकेशन तयार करण्यासाठी आणि वितरीत करण्यासाठी आमची मुक्त स्रोत GitOps CLI उपयुक्तता आहे. आश्वासन, आवृत्ती v1.0 चे प्रकाशन werf मध्ये नवीन वैशिष्ट्ये जोडण्याची आणि पारंपारिक दृष्टीकोन सुधारण्याची सुरुवात म्हणून चिन्हांकित केले. आता आम्हाला रिलीझ v1.1 सादर करताना आनंद होत आहे, जे विकासातील एक मोठे पाऊल आहे आणि भविष्यासाठी एक पाया आहे कलेक्टर werf आवृत्ती सध्या उपलब्ध आहे चॅनेल 1.1 ea.

रिलीझचा आधार स्टेज स्टोरेजचे नवीन आर्किटेक्चर आहे आणि दोन्ही कलेक्टर्सच्या कामाचे ऑप्टिमायझेशन (स्टेपल आणि डॉकरफाइलसाठी). नवीन स्टोरेज आर्किटेक्चर एकाच होस्टवर एकाधिक होस्ट आणि समांतर असेंब्लीमधून वितरित असेंब्ली लागू करण्याची शक्यता उघडते.

कामाच्या ऑप्टिमायझेशनमध्ये स्टेज स्वाक्षरीची गणना करण्याच्या टप्प्यावर अनावश्यक गणनापासून मुक्त होणे आणि फाइल चेकसमची गणना करण्यासाठी यंत्रणा अधिक कार्यक्षमतेमध्ये बदलणे समाविष्ट आहे. हे ऑप्टिमायझेशन werf वापरून प्रोजेक्ट बिल्डचा सरासरी वेळ कमी करते. आणि निष्क्रिय बिल्ड, जेव्हा कॅशेमध्ये सर्व टप्पे अस्तित्वात असतात टप्पे-स्टोरेज, आता खरोखर जलद आहेत. बहुतेक प्रकरणांमध्ये, बिल्ड रीस्टार्ट करण्यास 1 सेकंदापेक्षा कमी वेळ लागेल! हे कार्यसंघाच्या कार्याच्या प्रक्रियेतील टप्प्यांची पडताळणी करण्याच्या प्रक्रियेवर देखील लागू होते. werf deploy и werf run.

तसेच या प्रकाशनात, सामग्रीनुसार प्रतिमा टॅग करण्याची एक रणनीती दिसून आली - सामग्री-आधारित टॅगिंग, जे आता डीफॉल्टनुसार सक्षम केले आहे आणि फक्त एक शिफारस केलेले आहे.

चला werf v1.1 मधील प्रमुख नवकल्पनांवर बारकाईने नजर टाकूया, आणि त्याच वेळी भविष्यातील योजनांबद्दल सांगू.

werf 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. सध्याचा टप्पा गिटशी जोडलेला असल्यास (गिट-आर्काइव्ह, गिट पॅचसह सानुकूल स्टेज: install, beforeSetup, setup; किंवा git-latest-patch), नंतर werf फक्त ते टप्पे निवडतो जे कमिटशी संबंधित आहेत जे वर्तमान कमिटचे पूर्वज आहेत (ज्यासाठी बिल्ड म्हणतात).
4. उर्वरित योग्य टप्प्यांमधून, एक निवडला जातो - निर्मिती तारखेनुसार सर्वात जुना.

वेगवेगळ्या Git शाखांच्या स्टेजमध्ये समान स्वाक्षरी असू शकते. परंतु werf वेगवेगळ्या शाखांशी संबंधित कॅशे या शाखांमध्ये वापरण्यापासून प्रतिबंधित करेल, जरी स्वाक्षरी जुळत असली तरीही.

→ दस्तऐवजीकरण.

स्टेज स्टोरेजमध्ये टप्पे तयार करण्यासाठी आणि जतन करण्यासाठी नवीन अल्गोरिदम

जर, कॅशेमधून टप्पे निवडताना, werf ला योग्य स्टेज सापडला नाही, तर नवीन स्टेज एकत्र करण्याची प्रक्रिया सुरू केली जाते.

लक्षात घ्या की एकाधिक प्रक्रिया (एक किंवा अधिक होस्टवर) अंदाजे एकाच वेळी समान स्टेज तयार करणे सुरू करू शकतात. Werf एक आशावादी ब्लॉकिंग अल्गोरिदम वापरते टप्पे-स्टोरेज मध्ये नवीन गोळा केलेली प्रतिमा जतन करण्याच्या क्षणी टप्पे-स्टोरेज. अशा प्रकारे, नवीन स्टेज बिल्ड तयार झाल्यावर, वेर्फ ब्लॉक्स टप्पे-स्टोरेज आणि योग्य प्रतिमा अस्तित्वात नसेल तरच नवीन गोळा केलेली प्रतिमा तेथे जतन करते (स्वाक्षरी आणि इतर पॅरामीटर्सद्वारे - कॅशेमधून टप्पे निवडण्यासाठी नवीन अल्गोरिदम पहा).

नव्याने एकत्रित केलेल्या प्रतिमेला एक अद्वितीय अभिज्ञापक असण्याची हमी दिली जाते TIMESTAMP_MILLISEC (नवीन स्टेज नामकरण स्वरूप पहा). मध्ये बाबतीत टप्पे-स्टोरेज एक योग्य प्रतिमा सापडेल, werf नव्याने संकलित केलेली प्रतिमा टाकून देईल आणि कॅशेमधून प्रतिमा वापरेल.

दुसऱ्या शब्दात: प्रतिमा तयार करणे पूर्ण करण्याच्या पहिल्या प्रक्रियेस (सर्वात जलद) ते स्टेज-स्टोरेजमध्ये संग्रहित करण्याचा अधिकार मिळेल (आणि नंतर ही एकच प्रतिमा सर्व बिल्डसाठी वापरली जाईल). धीमे बिल्ड प्रक्रिया सध्याच्या स्टेजचे बिल्ड परिणाम जतन करण्यापासून आणि पुढील बिल्डवर जाण्यापासून वेगवान प्रक्रियेस कधीही अवरोधित करणार नाही.

→ दस्तऐवजीकरण.

डॉकरफाइल बिल्डरची कामगिरी सुधारली

याक्षणी, डॉकरफाइलमधून तयार केलेल्या प्रतिमेच्या टप्प्यांच्या पाइपलाइनमध्ये एक टप्पा असतो - dockerfile. स्वाक्षरीची गणना करताना, फाईल्सचा चेकसम मोजला जातो context, जे असेंब्ली दरम्यान वापरले जाईल. या सुधारणेपूर्वी, werf सर्व फायलींमधून वारंवार फिरत असे आणि प्रत्येक फाईलचा संदर्भ आणि मोड एकत्रित करून चेकसम प्राप्त केला. v1.1 सह प्रारंभ करून, werf Git रेपॉजिटरीमध्ये संग्रहित गणना केलेले चेकसम वापरू शकते.

अल्गोरिदम आधारित आहे git ls-वृक्ष. अल्गोरिदम खाते रेकॉर्ड मध्ये घेते .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 शाखांवर टॅग करण्यापेक्षा अधिक विश्वासार्ह टॅगिंग पद्धत आहे, कारण परिणामी प्रतिमांची सामग्री एकाच शाखेच्या एकाधिक कमिट एकत्र करण्यासाठी CI प्रणालीमध्ये पाइपलाइन कार्यान्वित केल्या जातात त्या क्रमावर अवलंबून नाही.

महत्वाचे: आत्तापासून सुरू टप्पे - स्वाक्षरी - हे आहे फक्त शिफारस केलेले टॅगिंग धोरण. हे कमांडमध्ये डीफॉल्टनुसार वापरले जाईल werf ci-env (जोपर्यंत तुम्ही वेगळी टॅगिंग योजना स्पष्टपणे नमूद करत नाही तोपर्यंत).

→ दस्तऐवजीकरण. या वैशिष्ट्यासाठी एक स्वतंत्र प्रकाशन देखील समर्पित केले जाईल. अद्यतनित (3 एप्रिल): तपशीलांसह लेख प्रकाशित.

लॉगिंग पातळी

वापरकर्त्याला आता आउटपुट नियंत्रित करण्याची, लॉगिंग पातळी सेट करण्याची आणि डीबगिंग माहितीसह कार्य करण्याची संधी आहे. पर्याय जोडले --log-quiet, --log-verbose, --log-debug.

डीफॉल्टनुसार, आउटपुटमध्ये किमान माहिती असते:

वर्बोज आउटपुट वापरताना (--log-verbose) आपण werf कसे कार्य करते ते पाहू शकता:

तपशीलवार आउटपुट (--log-debug), werf डीबगिंग माहिती व्यतिरिक्त, वापरलेल्या लायब्ररीचे लॉग देखील समाविष्ट करते. उदाहरणार्थ, डॉकर रेजिस्ट्रीसह परस्परसंवाद कसा होतो ते आपण पाहू शकता आणि ज्या ठिकाणी महत्त्वपूर्ण वेळ घालवला जातो त्या ठिकाणांची नोंद देखील करू शकता:

भविष्यातील योजना

खबरदारी खाली वर्णन केलेले पर्याय चिन्हांकित केले आहेत v1.1 या आवृत्तीमध्ये उपलब्ध होतील, त्यापैकी अनेक नजीकच्या भविष्यात. अद्यतने स्वयं-अद्यतनांद्वारे येतील मल्टीवर्फ वापरताना. ही वैशिष्ट्ये v1.1 फंक्शन्सच्या स्थिर भागावर परिणाम करत नाहीत; त्यांचे स्वरूप विद्यमान कॉन्फिगरेशनमध्ये मॅन्युअल वापरकर्त्याच्या हस्तक्षेपाची आवश्यकता नाही.

विविध डॉकर रेजिस्ट्री अंमलबजावणीसाठी पूर्ण समर्थन (नवीन)

• आवृत्ती: v1.1
• तारखा: मार्च
• परिणाम

werf वापरताना वापरकर्त्याने निर्बंधांशिवाय सानुकूल अंमलबजावणी वापरणे हे ध्येय आहे.

सध्या, आम्ही खालील उपायांचा संच ओळखला आहे ज्यासाठी आम्ही पूर्ण समर्थनाची हमी देणार आहोत:

• डीफॉल्ट (लायब्ररी/रेजिस्ट्री)*,
• AWS ECR
• Azure*,
• डॉकर हब
• GCR*,
• GitHub पॅकेजेस
• GitLab रजिस्ट्री*,
• हार्बर*,
• क्वे.

सध्या werf द्वारे पूर्णपणे समर्थित असलेल्या सोल्युशन्सना तारकाने चिन्हांकित केले आहे. इतरांसाठी समर्थन आहे, परंतु मर्यादांसह.

दोन मुख्य समस्या ओळखल्या जाऊ शकतात:

• काही उपाय डॉकर रेजिस्ट्री API वापरून टॅग काढण्यास समर्थन देत नाहीत, वापरकर्त्यांना werf चे स्वयंचलित क्लीनअप वापरण्यापासून प्रतिबंधित करते. हे AWS ECR, Docker Hub आणि GitHub पॅकेजेससाठी खरे आहे.
• काही उपाय तथाकथित नेस्टेड रेपॉजिटरीज (डॉकर हब, गिटहब पॅकेजेस आणि क्वे) ला समर्थन देत नाहीत किंवा करतात, परंतु वापरकर्त्याने ते UI किंवा API (AWS ECR) वापरून व्यक्तिचलितपणे तयार केले पाहिजेत.

आम्ही सोल्यूशन्सचे मूळ API वापरून या आणि इतर समस्या सोडवणार आहोत. या कार्यामध्ये werf ऑपरेशनचे संपूर्ण चक्र त्या प्रत्येकाच्या चाचण्यांसह समाविष्ट आहे.

वितरित प्रतिमा बिल्ड (↑)

• आवृत्ती: v1.2 v1.1 (हे वैशिष्ट्य लागू करण्यासाठी प्राधान्य वाढवले ​​गेले आहे)
• तारखा: मार्च-एप्रिल मार्च
• परिणाम

याक्षणी, werf v1.0 आणि v1.1 फक्त एका समर्पित होस्टवर प्रतिमा तयार करणे आणि प्रकाशित करणे आणि Kubernetes वर अनुप्रयोग तैनात करणे यासाठी वापरले जाऊ शकते.

werf च्या वितरीत कार्याच्या शक्यता उघडण्यासाठी, जेव्हा अनेक अनियंत्रित होस्टवर कुबर्नेट्समध्ये अनुप्रयोग तयार करणे आणि तैनात करणे सुरू केले जाते आणि हे यजमान बिल्ड (तात्पुरते धावपटू) दरम्यान त्यांचे राज्य वाचवत नाहीत, तेव्हा werf वापरण्याची क्षमता लागू करणे आवश्यक आहे. स्टेज स्टोअर म्हणून डॉकर रेजिस्ट्री.

पूर्वी, जेव्हा वेर्फ प्रकल्पाला अजूनही डॅप म्हटले जात असे, तेव्हा त्याला अशी संधी होती. तथापि, werf मध्ये या कार्यक्षमतेची अंमलबजावणी करताना आम्हाला अनेक समस्या आल्या आहेत ज्या विचारात घेतल्या पाहिजेत.

शेरा. या वैशिष्ट्यासाठी कलेक्टरला कुबर्नेट्स पॉड्समध्ये काम करण्याची आवश्यकता नाही, कारण हे करण्यासाठी, तुम्हाला स्थानिक डॉकर सर्व्हरवरील अवलंबित्वापासून मुक्त होणे आवश्यक आहे (कुबर्नेट्स पॉडमध्ये स्थानिक डॉकर सर्व्हरमध्ये प्रवेश नाही, कारण प्रक्रिया स्वतः कंटेनरमध्ये चालत आहे आणि werf समर्थन करत नाही आणि करणार नाही. नेटवर्कवर डॉकर सर्व्हरसह कार्य करणे). कुबर्नेट्स चालविण्यासाठी समर्थन स्वतंत्रपणे लागू केले जाईल.

GitHub क्रियांसाठी अधिकृत समर्थन (नवीन)

• आवृत्ती: v1.1
• तारखा: मार्च
• परिणाम

werf दस्तऐवजीकरण (विभाग संदर्भ и मार्गदर्शन), तसेच werf सह काम करण्यासाठी अधिकृत GitHub क्रिया.

याव्यतिरिक्त, ते werf ला क्षणिक धावपटूंवर काम करण्यास अनुमती देईल.

सीआय सिस्टमसह वापरकर्त्याच्या परस्परसंवादाचे यांत्रिकी अनुप्रयोग तयार/रोल आउट करण्यासाठी विशिष्ट क्रिया सुरू करण्यासाठी पुल विनंत्यांवर लेबले ठेवण्यावर आधारित असेल.

werf (↓) सह अनुप्रयोगांचा स्थानिक विकास आणि उपयोजन

• आवृत्ती: v1.1
• तारखा: जानेवारी-फेब्रुवारी एप्रिल
• परिणाम

स्थानिक पातळीवर आणि उत्पादनात, जटिल क्रियांशिवाय, बॉक्सच्या बाहेर अनुप्रयोग तैनात करण्यासाठी एकल युनिफाइड कॉन्फिगरेशन प्राप्त करणे हे मुख्य ध्येय आहे.

werf ला एक ऑपरेटिंग मोड असणे देखील आवश्यक आहे ज्यामध्ये अनुप्रयोग कोड संपादित करणे आणि डीबगिंगसाठी चालू असलेल्या अनुप्रयोगाकडून त्वरित अभिप्राय प्राप्त करणे सोयीचे असेल.

नवीन स्वच्छता अल्गोरिदम (नवीन)

• आवृत्ती: v1.1
• तारखा: एप्रिल
• परिणाम

प्रक्रियेमध्ये werf v1.1 च्या वर्तमान आवृत्तीमध्ये cleanup सामग्री-आधारित टॅगिंग योजनेसाठी प्रतिमा साफ करण्याची कोणतीही तरतूद नाही - या प्रतिमा जमा होतील.

तसेच, werf ची वर्तमान आवृत्ती (v1.0 आणि v1.1) टॅगिंग योजनांच्या अंतर्गत प्रकाशित प्रतिमांसाठी भिन्न क्लीनअप धोरणे वापरते: Git branch, Git tag किंवा Git कमिट.

Git मधील कमिटच्या इतिहासावर आधारित प्रतिमा साफ करण्यासाठी एक नवीन अल्गोरिदम, सर्व टॅगिंग योजनांसाठी एकत्रित, शोधण्यात आला आहे:

• प्रत्येक गिट हेड (शाखा आणि टॅग) साठी N1 सर्वात अलीकडील कमिटशी संबंधित N2 पेक्षा जास्त प्रतिमा ठेवू नका.
• प्रत्येक गिट हेड (शाखा आणि टॅग) साठी N1 सर्वात अलीकडील कमिटशी संबंधित N2 स्टेज इमेजेसपेक्षा जास्त संग्रहित करू नका.
• कोणत्याही Kubernetes क्लस्टर संसाधनांमध्ये वापरल्या जाणाऱ्या सर्व प्रतिमा संग्रहित करा (कॉन्फिगरेशन फाइलचे सर्व क्यूब संदर्भ आणि नेमस्पेस स्कॅन केल्या आहेत; तुम्ही विशेष पर्यायांसह हे वर्तन मर्यादित करू शकता).
• हेल्म रिलीझमध्ये सेव्ह केलेल्या रिसोर्स कॉन्फिगरेशन मॅनिफेस्टमध्ये वापरल्या जाणाऱ्या सर्व इमेजेस स्टोअर करा.
• एखादी प्रतिमा git मधील कोणत्याही HEAD शी संबंधित नसल्यास ती हटविली जाऊ शकते (उदाहरणार्थ, संबंधित HEAD स्वतःच हटविण्यात आले होते) आणि ती Kubernetes क्लस्टर आणि Helm प्रकाशनांमध्ये कोणत्याही मॅनिफेस्टमध्ये वापरली जात नाही.

समांतर प्रतिमा इमारत (↓)

• आवृत्ती: v1.1
• तारखा: जानेवारी-फेब्रुवारी एप्रिल*

werf ची वर्तमान आवृत्ती वर्णन केलेल्या प्रतिमा आणि कलाकृती गोळा करते werf.yaml, क्रमशः. प्रतिमा आणि कलाकृतींचे स्वतंत्र टप्पे एकत्रित करण्याच्या प्रक्रियेस समांतर करणे आवश्यक आहे, तसेच सोयीस्कर आणि माहितीपूर्ण आउटपुट प्रदान करणे आवश्यक आहे.

* टीप: वितरित असेंब्लीच्या अंमलबजावणीसाठी वाढीव प्राधान्यामुळे अंतिम मुदत हलविण्यात आली आहे, ज्यामुळे अधिक क्षैतिज स्केलिंग क्षमता जोडल्या जातील, तसेच GitHub क्रियांसह werf चा वापर केला जाईल. समांतर असेंब्ली ही पुढील ऑप्टिमायझेशन पायरी आहे, एक प्रोजेक्ट असेंबल करताना वर्टिकल स्केलेबिलिटी प्रदान करते.

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

• आवृत्ती: v1.2
• तारखा: फेब्रुवारी-मार्च मे*

नवीन कोडबेसमध्ये स्थलांतर समाविष्ट आहे हेल्म 3 आणि विद्यमान स्थापना स्थलांतरित करण्याचा सिद्ध, सोयीस्कर मार्ग.

* टीप: हेल्म 3 वर स्विच केल्याने werf मध्ये महत्त्वपूर्ण वैशिष्ट्ये जोडली जाणार नाहीत, कारण हेल्म 3 ची सर्व प्रमुख वैशिष्ट्ये (3-वे-मर्ज आणि नो टिलर) आधीच werf मध्ये लागू केलेली आहेत. शिवाय, werf आहे अतिरिक्त वैशिष्ट्ये सूचित केलेल्या व्यतिरिक्त. तथापि, हे संक्रमण आमच्या योजनांमध्ये कायम आहे आणि ते लागू केले जाईल.

Kubernetes कॉन्फिगरेशनचे वर्णन करण्यासाठी Jsonnet (↓)

• आवृत्ती: v1.2
• तारखा: जानेवारी-फेब्रुवारी एप्रिल-मे

Werf Jsonnet फॉरमॅटमध्ये Kubernetes साठी कॉन्फिगरेशन वर्णनांना समर्थन देईल. त्याच वेळी, werf हेल्मशी सुसंगत राहील आणि वर्णन स्वरूपाची निवड असेल.

याचे कारण असे आहे की अनेक लोकांच्या मते गो टेम्प्लेट्समध्ये उच्च प्रवेशाचा अडथळा असतो आणि या टेम्प्लेट्सच्या कोडची समजूतदारता देखील प्रभावित होते.

इतर Kubernetes कॉन्फिगरेशन वर्णन प्रणाली (उदाहरणार्थ, Kustomize) सादर करण्याच्या शक्यतेचा देखील विचार केला जात आहे.

कुबर्नेट्समध्ये काम करणे (↓)

• आवृत्ती: v1.2
• तारखा: एप्रिल-मे मे-जून

ध्येय: कुबर्नेट्समधील धावपटू वापरून प्रतिमा तयार केल्या आहेत आणि अनुप्रयोग वितरित केला आहे याची खात्री करा. त्या. नवीन प्रतिमा तयार केल्या जाऊ शकतात, प्रकाशित केल्या जाऊ शकतात, साफ केल्या जाऊ शकतात आणि थेट कुबर्नेट्स पॉड्समधून तैनात केल्या जाऊ शकतात.

ही क्षमता अंमलात आणण्यासाठी, आपण प्रथम वितरित प्रतिमा तयार करण्यास सक्षम असणे आवश्यक आहे (वरील बिंदू पहा).

यासाठी डॉकर सर्व्हरशिवाय बिल्डरच्या ऑपरेटिंग मोडसाठी समर्थन आवश्यक आहे (म्हणजे कानिको सारखी बिल्ड किंवा वापरकर्ता स्पेसमध्ये बिल्ड).

Werf केवळ डॉकरफाइलच नव्हे, तर त्याच्या स्टेपल बिल्डरला वाढीव पुनर्बांधणी आणि उत्तरदायित्वासह कुबर्नेट्सवरील इमारतींना समर्थन देईल.

खुल्या विकासाच्या दिशेने एक पाऊल

आम्हाला आमच्या समाजावर प्रेम आहे (GitHub, तार) आणि आम्हाला अधिकाधिक लोकांनी वेर्फला अधिक चांगले बनविण्यात मदत करावी, आम्ही ज्या दिशेने वाटचाल करत आहोत ते समजून घ्या आणि विकासात सहभागी व्हावे अशी आमची इच्छा आहे.

अगदी अलीकडे वर स्विच करण्याचा निर्णय घेण्यात आला GitHub प्रकल्प बोर्ड आमच्या कार्यसंघाची कार्य प्रक्रिया प्रकट करण्यासाठी. आता तुम्ही तत्काळ योजना पाहू शकता, तसेच खालील क्षेत्रातील चालू कार्ये पाहू शकता:

• दस्तऐवजीकरण आणि साइट;
• चाचणी;
• बग आणि खराब UX;
• 1.1.

समस्यांसह बरेच काम केले गेले आहे:

• असंबद्ध काढले.
• अस्तित्वात असलेले एकल फॉरमॅटमध्ये आणले जातात, ज्यामध्ये पुरेसे तपशील आणि तपशील आहेत.
• कल्पना आणि सूचनांसह नवीन समस्या जोडल्या गेल्या आहेत.

आवृत्ती v1.1 कशी सक्षम करावी

आवृत्ती सध्या उपलब्ध आहे चॅनेल 1.1 ea (चॅनेलमध्ये स्थिर и खडकाळ स्थिरीकरण झाल्यावर प्रकाशन दिसून येईल, तथापि ea स्वत: आधीच वापरासाठी पुरेसे स्थिर आहे, कारण वाहिन्यांमधून गेले अल्फा и बीटा). सक्रिय केले multiwerf द्वारे खालील प्रकारे:

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

निष्कर्ष

स्टॅपल आणि डॉकरफाइल बिल्डर्ससाठी नवीन स्टेज स्टोरेज आर्किटेक्चर आणि बिल्डर ऑप्टिमायझेशन्स werf मध्ये वितरित आणि समांतर बिल्ड्सची अंमलबजावणी करण्याची शक्यता उघडतात. ही वैशिष्ट्ये लवकरच त्याच v1.1 रिलीझमध्ये दिसून येतील आणि स्वयं-अपडेट यंत्रणेद्वारे (वापरकर्त्यांसाठी) स्वयंचलितपणे उपलब्ध होतील multiwerf).

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

पुढील महत्त्वाची पायरी म्हणजे वितरित असेंब्ली जोडणे. v1.0 पासून समांतर बिल्ड्सपेक्षा वितरित बिल्ड्सना उच्च प्राधान्य मिळाले आहे कारण ते werf ला अधिक मूल्य जोडतात: बिल्डर्सचे अनुलंब स्केलिंग आणि विविध CI/CD सिस्टीममध्ये अल्पकालीन बिल्डर्ससाठी समर्थन, तसेच GitHub क्रियांसाठी अधिकृत समर्थन करण्याची क्षमता . त्यामुळे समांतर असेंब्लीच्या अंमलबजावणीची मुदत बदलण्यात आली. तथापि, आम्ही दोन्ही शक्यता लवकरात लवकर अंमलात आणण्यासाठी काम करत आहोत.

बातम्यांचे अनुसरण करा! आणि येथे आम्हाला भेट द्यायला विसरू नका GitHubसमस्या निर्माण करण्यासाठी, विद्यमान एक शोधा आणि प्लस जोडा, एक PR तयार करा किंवा फक्त प्रकल्पाचा विकास पहा.

PS

आमच्या ब्लॉगवर देखील वाचा:

• «सादर करत आहोत werf 1.0 स्थिर: GitOps चा त्याच्याशी काय संबंध आहे, स्थिती आणि योजना»
• «werf - Kubernetes मधील CI/CD साठी आमचे साधन (विहंगावलोकन आणि व्हिडिओ अहवाल)";
• werf मधील नवकल्पनांबद्दल नोट्सची मालिका:
  • «werf मध्ये 3-वे विलीनीकरण: हेल्मसह कुबर्नेट्सला “स्टिरॉइड्सवर” तैनात करा";
  • «जटिल हेल्म चार्ट रोल आउट करण्यासाठी werf वापरणे";
  • «werf मधील मोनोरेपो आणि मल्टीरेपोसाठी समर्थन आणि डॉकर रजिस्ट्रीचा त्याच्याशी काय संबंध आहे";
  • «तुम्ही आता नियमित Dockerfile वापरून werf मध्ये डॉकर प्रतिमा तयार करू शकता».

स्त्रोत: www.habr.com