werf 1.1 रिलीज: आज निर्माणकर्तामा सुधारहरू र भविष्यका लागि योजनाहरू

वाफ Kubernetes मा अनुप्रयोगहरू निर्माण र डेलिभर गर्नको लागि हाम्रो खुला स्रोत GitOps CLI उपयोगिता हो। प्रतिज्ञा अनुसार, संस्करण v1.0 को रिलीज werf मा नयाँ सुविधाहरू थप्ने र परम्परागत दृष्टिकोणहरू परिमार्जन गर्ने सुरुवात चिन्ह लगाइयो। अब हामी रिलिज v1.1 प्रस्तुत गर्न पाउँदा खुसी छौं, जुन विकासमा ठूलो कदम र भविष्यको लागि आधार हो कलेक्टर werf। संस्करण हाल मा उपलब्ध छ च्यानल 1.1 ea.

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

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

यस विमोचनमा पनि, सामग्रीद्वारा छविहरू ट्याग गर्ने रणनीति देखा पर्‍यो - सामग्री आधारित ट्यागिङ, जुन अब पूर्वनिर्धारित रूपमा सक्षम छ र एक मात्र सिफारिस गरिएको छ।

werf v1.1 मा प्रमुख आविष्कारहरू नजिकबाट हेरौं, र एकै समयमा भविष्यका लागि योजनाहरू बारे बताउनुहोस्।

werf v1.1 मा के परिवर्तन भएको छ?

नयाँ चरण नामकरण ढाँचा र क्यासबाट चरणहरू चयन गर्न एल्गोरिथ्म

नयाँ चरण नाम पुस्ता नियम। अब प्रत्येक चरण निर्माणले एउटा अद्वितीय चरणको नाम उत्पन्न गर्दछ, जसमा २ भागहरू हुन्छन्: एउटा हस्ताक्षर (जस्तै यो v2 मा थियो) र एक अद्वितीय अस्थायी पहिचानकर्ता।

उदाहरण को लागी, पूर्ण चरण छवि नाम यस्तो देखिन सक्छ:

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 ले विभिन्न शाखाहरूसँग सम्बन्धित क्यासलाई यी शाखाहरू बीच प्रयोग हुनबाट रोक्छ, हस्ताक्षरहरू मेल खाए पनि।

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

स्टेज भण्डारणमा चरणहरू सिर्जना गर्न र बचत गर्नका लागि नयाँ एल्गोरिथ्म

यदि, क्यासबाट चरणहरू चयन गर्दा, werf ले उपयुक्त चरण फेला पारेन भने, नयाँ चरण संयोजन गर्ने प्रक्रिया सुरु हुन्छ।

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

भर्खरै जम्मा गरिएको छविमा एक अद्वितीय पहिचानकर्ताको ग्यारेन्टी छ TIMESTAMP_MILLISEC (नयाँ चरणको नामकरण ढाँचा हेर्नुहोस्)। को मामला मा चरणहरू - भण्डारण उपयुक्त छवि फेला पर्नेछ, werf ले भर्खरै कम्पाइल गरिएको छवि खारेज गर्नेछ र क्यासबाट छवि प्रयोग गर्नेछ।

अर्को शब्दमा: छवि निर्माण गर्ने पहिलो प्रक्रिया (सबैभन्दा छिटो) ले यसलाई चरण-भण्डारणमा भण्डारण गर्ने अधिकार प्राप्त गर्नेछ (र त्यसपछि यो एकल छवि हो जुन सबै निर्माणहरूको लागि प्रयोग गरिनेछ)। एक ढिलो निर्माण प्रक्रियाले हालको चरणको निर्माण परिणामहरू बचत गर्न र अर्को निर्माणमा जानबाट द्रुत प्रक्रियालाई कहिल्यै रोक्दैन।

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

सुधारिएको Dockerfile बिल्डर प्रदर्शन

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

एल्गोरिथ्म मा आधारित छ git ls-ट्री। एल्गोरिदम खाता रेकर्ड मा लिन्छ .dockerignore र आवश्यक भएमा मात्र फाइल ट्रीलाई दोहोरिने गरी पार गर्दछ। यसरी, हामीले फाइल प्रणाली पढ्नबाट अलग गरेका छौं, र साइजमा एल्गोरिदमको निर्भरता। context महत्त्वपूर्ण छैन।

एल्गोरिदमले ट्र्याक नगरिएका फाइलहरू पनि जाँच गर्दछ र आवश्यक भएमा, तिनीहरूलाई चेकसममा खातामा लिन्छ।

फाइलहरू आयात गर्दा सुधारिएको प्रदर्शन

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

macOS मा आयात प्रदर्शन अब डकर भोल्युमहरू द्वारा सीमित छैन, र लिनक्स र विन्डोज जस्तै समयको समान मात्रामा आयात पूरा हुन्छ।

सामग्री-आधारित ट्यागिङ

Werf v1.1 छवि सामग्री द्वारा तथाकथित ट्यागिङ समर्थन गर्दछ - सामग्री आधारित ट्यागिङ। परिणामस्वरूप डकर छविहरूको ट्यागहरू ती छविहरूको सामग्रीहरूमा निर्भर हुन्छन्।

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

छवि चरणहरूको हस्ताक्षर निर्भर गर्दछ:

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

Git भण्डारमा सधैं डमी कमिटहरू हुन्छन् जसले छवि फाइलहरूको सामग्री परिवर्तन गर्दैन। उदाहरणका लागि, केवल टिप्पणीहरू वा मर्ज कमिटहरू वा कमिटहरू जसले Git मा ती फाइलहरू परिवर्तन गर्दछ जुन छविमा आयात गरिने छैन।

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

साथै, सामग्री-आधारित ट्यागिङ Git शाखाहरूमा ट्यागिङ भन्दा बढी भरपर्दो ट्यागिङ विधि हो, किनभने नतिजा छविहरूको सामग्री एउटै शाखाको बहु कमिटहरू जम्मा गर्न CI प्रणालीमा पाइपलाइनहरू कार्यान्वयन गर्ने क्रममा निर्भर गर्दैन।

महत्त्वपूर्ण: अब देखि सुरु चरणहरू - हस्ताक्षर हो मात्र सिफारिस गरिएको ट्यागिङ रणनीति। यो आदेशमा पूर्वनिर्धारित रूपमा प्रयोग गरिनेछ werf ci-env (तपाईंले स्पष्ट रूपमा फरक ट्यागिङ योजना निर्दिष्ट नगरेसम्म)।

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

लगिङ स्तरहरू

प्रयोगकर्तासँग अब आउटपुट नियन्त्रण गर्ने, लगिङ स्तर सेट गर्ने र डिबगिङ जानकारीसँग काम गर्ने अवसर छ। विकल्पहरू थपियो --log-quiet, --log-verbose, --log-debug.

पूर्वनिर्धारित रूपमा, आउटपुटले न्यूनतम जानकारी समावेश गर्दछ:

वर्बोज आउटपुट प्रयोग गर्दा (--log-verbose) तपाईले werf कसरी काम गर्दछ हेर्न सक्नुहुन्छ:

विस्तृत आउटपुट (--log-debug, werf डिबगिङ जानकारीको अतिरिक्त, प्रयोग गरिएको पुस्तकालयहरूको लगहरू पनि समावेश गर्दछ। उदाहरणका लागि, तपाईंले डकर रजिस्ट्रीसँग कसरी अन्तरक्रिया हुन्छ भनेर हेर्न सक्नुहुन्छ, र महत्त्वपूर्ण समय बिताएको ठाउँहरू पनि रेकर्ड गर्नुहोस्:

भावी योजनाहरू

सावधानी तल वर्णन गरिएका विकल्पहरू चिन्ह लगाइएका छन् v1.1 यस संस्करणमा उपलब्ध हुनेछ, ती मध्ये धेरै निकट भविष्यमा। अद्यावधिकहरू स्वत: अद्यावधिकहरू मार्फत आउनेछन् multiwerf प्रयोग गर्दा। यी सुविधाहरूले v1.1 प्रकार्यहरूको स्थिर भागलाई असर गर्दैन; तिनीहरूको उपस्थितिले अवस्थित कन्फिगरेसनहरूमा म्यानुअल प्रयोगकर्ता हस्तक्षेप आवश्यक पर्दैन।

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

• संस्करण: v1.1
• मितिहरू: मार्च
• मुद्दा

लक्ष्य प्रयोगकर्ताको लागि werf प्रयोग गर्दा प्रतिबन्ध बिना अनुकूलन कार्यान्वयन प्रयोग गर्न हो।

हाल, हामीले समाधानहरूको निम्न सेट पहिचान गरेका छौं जसको लागि हामी पूर्ण समर्थनको ग्यारेन्टी गर्न जाँदैछौं:

• पूर्वनिर्धारित (पुस्तकालय/रेजिस्ट्री)*,
• AWS ECR
• नीला*,
• डकर हब
• GCR*,
• GitHub प्याकेजहरू
• GitLab रजिस्ट्री*,
• बन्दरगाह*,
• क्वे।

समाधानहरू जुन हाल werf द्वारा पूर्ण रूपमा समर्थित छन् तारा चिन्हको साथ चिन्ह लगाइएको छ। अरूको लागि समर्थन छ, तर सीमितताहरूको साथ।

दुई मुख्य समस्या पहिचान गर्न सकिन्छ:

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

हामी यी र अन्य समस्याहरू समाधानको नेटिभ API प्रयोग गरेर समाधान गर्न जाँदैछौं। यो कार्यले ती मध्ये प्रत्येकको लागि परीक्षणहरू सहित werf सञ्चालनको पूर्ण चक्रलाई समावेश गर्दछ।

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

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

यस समयमा, werf v1.0 र v1.1 छविहरू निर्माण र प्रकाशन गर्ने र अनुप्रयोगलाई Kubernetes मा डिप्लोइ गर्नका लागि एउटा समर्पित होस्टमा मात्र प्रयोग गर्न सकिन्छ।

werf को वितरित कार्य को सम्भावनाहरु खोल्न को लागी, जब Kubernetes मा आवेदनहरु को निर्माण र तैनाती धेरै मनमानी होस्टहरु मा शुरू गरिन्छ र यी होस्टहरु को बिल्ड (अस्थायी धावकहरु) को बीच आफ्नो राज्य को बचत गर्दैन, werf को उपयोग को क्षमता को लागी आवश्यक छ। स्टेज स्टोरको रूपमा डकर रजिस्ट्री।

पहिले, जब werf परियोजना अझै पनि dapp भनिन्थ्यो, यो यस्तो अवसर थियो। यद्यपि, हामीले werf मा यो कार्यक्षमता लागू गर्दा ध्यानमा राख्नु पर्ने धेरै समस्याहरू सामना गरेका छौं।

भन्नु। यो सुविधाले कलेक्टरलाई Kubernetes पोड भित्र काम गर्न आवश्यक छैन, किनभने यो गर्नको लागि, तपाईंले स्थानीय डकर सर्भरमा निर्भरताबाट छुटकारा पाउन आवश्यक छ (कुबर्नेट्स पोडमा स्थानीय डकर सर्भरमा पहुँच छैन, किनभने प्रक्रिया आफैं कन्टेनरमा चलिरहेको छ, र werf ले समर्थन गर्दैन र समर्थन गर्दैन। नेटवर्कमा डकर सर्भरसँग काम गर्दै)। Kubernetes चलाउनको लागि समर्थन अलग रूपमा लागू गरिनेछ।

GitHub कार्यहरूको लागि आधिकारिक समर्थन (नयाँ)

• संस्करण: v1.1
• मितिहरू: मार्च
• मुद्दा

werf कागजात समावेश गर्दछ (खण्डहरू सन्दर्भ и डोऱ्याउन), साथै werf सँग काम गर्नको लागि आधिकारिक GitHub कार्य।

थप रूपमा, यसले werf लाई अल्पकालिक धावकहरूमा काम गर्न अनुमति दिनेछ।

CI प्रणालीसँग प्रयोगकर्ताको अन्तरक्रियाको मेकानिक्स एप्लिकेसन निर्माण/रोल आउट गर्न निश्चित कार्यहरू प्रारम्भ गर्न पुल अनुरोधहरूमा लेबलहरू राख्नमा आधारित हुनेछ।

स्थानीय विकास र werf (↓) सँग अनुप्रयोगहरूको तैनाती

• संस्करण: v1.1
• मितिहरू: जनवरी-फेब्रुअरी अप्रिल
• मुद्दा

मुख्य लक्ष्य भनेको बक्स बाहिर, जटिल कार्यहरू बिना, स्थानीय र उत्पादनमा अनुप्रयोगहरू प्रयोग गर्नको लागि एकल एकीकृत कन्फिगरेसन प्राप्त गर्नु हो।

werf सँग अपरेटिङ मोड हुनु पनि आवश्यक छ जसमा एप कोड सम्पादन गर्न र डिबगिङका लागि चलिरहेको एप्लिकेसनबाट तुरुन्तै प्रतिक्रिया प्राप्त गर्न सहज हुनेछ।

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

• संस्करण: v1.1
• मितिहरू: अप्रिल
• मुद्दा

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

साथै, werf को हालको संस्करण (v1.0 र v1.1) ले ट्यागिङ योजनाहरू अन्तर्गत प्रकाशित छविहरूको लागि विभिन्न सफाई नीतिहरू प्रयोग गर्दछ: Git शाखा, Git ट्याग वा Git कमिट।

Git मा कमिटको इतिहासमा आधारित छविहरू सफा गर्नको लागि नयाँ एल्गोरिथ्म, सबै ट्यागिङ योजनाहरूको लागि एकीकृत, आविष्कार गरिएको छ:

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

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

• संस्करण: v1.1
• मितिहरू: जनवरी-फेब्रुअरी अप्रिल*

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

* नोट: वितरण गरिएको एसेम्बली कार्यान्वयन गर्नको लागि बढ्दो प्राथमिकताका कारण समयसीमा सारिएको छ, जसले थप तेर्सो मापन क्षमताहरू थप्नेछ, साथै GitHub कार्यहरूसँग werf को प्रयोग गर्नेछ। समानान्तर एसेम्बली अर्को अप्टिमाइजेसन चरण हो, एउटा प्रोजेक्ट एसेम्बल गर्दा ठाडो स्केलेबिलिटी प्रदान गर्ने।

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

• संस्करण: v1.2
• मितिहरू: फेब्रुअरी-मार्च मे*

नयाँ कोडबेसमा माइग्रेसन समावेश गर्दछ हेलम 3 र अवस्थित स्थापनाहरू माइग्रेट गर्ने प्रमाणित, सुविधाजनक तरिका।

* नोट: Helm 3 मा स्विच गर्दा werf मा महत्त्वपूर्ण विशेषताहरू थपिने छैन, किनकि Helm 3 का सबै मुख्य विशेषताहरू (3-मार्ग-मर्ज र कुनै टिलर) पहिले नै werf मा लागू गरिएका छन्। यसबाहेक, werf छ थप सुविधाहरू संकेत गरेको बाहेक। यद्यपि, यो संक्रमण हाम्रो योजनाहरूमा रहन्छ र लागू हुनेछ।

Kubernetes कन्फिगरेसन (↓) वर्णन गर्नका लागि Jsonnet

• संस्करण: v1.2
• मितिहरू: जनवरी-फेब्रुअरी अप्रिल-मे

Werf ले Jsonnet ढाँचामा Kubernetes को लागि कन्फिगरेसन विवरण समर्थन गर्नेछ। एकै समयमा, werf हेल्मसँग उपयुक्त रहनेछ र वर्णन ढाँचाको छनोट हुनेछ।

कारण यो हो कि गो टेम्प्लेटहरू, धेरै व्यक्तिहरूका अनुसार, उच्च प्रविष्टि बाधा छ, र यी टेम्प्लेटहरूको कोडको बुझाइ पनि पीडित छ।

अन्य Kubernetes कन्फिगरेसन विवरण प्रणालीहरू (उदाहरणका लागि, Kustomize) परिचय गर्ने सम्भावना पनि विचार गरिँदैछ।

Kubernetes (↓) भित्र काम गर्दै

• संस्करण: v1.2
• मितिहरू: अप्रिल-मे मे-जून

लक्ष्य: सुनिश्चित गर्नुहोस् कि छविहरू बनाइएका छन् र कुबर्नेट्समा धावकहरू प्रयोग गरेर अनुप्रयोग डेलिभर गरिएको छ। ती। नयाँ छविहरू निर्माण गर्न, प्रकाशित गर्न, सफा गर्न, र Kubernetes पोडहरूबाट सिधै तैनात गर्न सकिन्छ।

यो क्षमता लागू गर्न, तपाईंले पहिले वितरित छविहरू निर्माण गर्न सक्षम हुन आवश्यक छ (माथिको बिन्दु हेर्नुहोस्).

यसलाई डकर सर्भर बिना निर्माणकर्ताको अपरेटिङ मोडको लागि समर्थन चाहिन्छ (जस्तै Kaniko-जस्तो निर्माण वा प्रयोगकर्ता स्थानमा निर्माण)।

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

खुला विकासको दिशामा एक कदम

हामी हाम्रो समुदायलाई माया गर्छौं (GitHub, तार) र हामी धेरै भन्दा धेरै मानिसहरूले werf लाई अझ राम्रो बनाउन मद्दत गर्न चाहन्छौं, हामी कुन दिशामा जाँदैछौं, र विकासमा सहभागी हुन चाहन्छौं।

हालसालै यसलाई स्विच गर्ने निर्णय गरियो GitHub परियोजना बोर्डहरू हाम्रो टोलीको कार्य प्रक्रिया प्रकट गर्न। अब तपाईंले तत्काल योजनाहरू, साथै निम्न क्षेत्रहरूमा हालको कामहरू हेर्न सक्नुहुन्छ:

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

समस्याहरु संग धेरै काम गरिएको छ:

• अप्रासंगिक हटाइयो।
• अवस्थितहरूलाई एकल ढाँचामा ल्याइएको छ, पर्याप्त विवरण र विवरणहरूको साथ।
• विचार र सुझावका साथ नयाँ मुद्दाहरू थपिएका छन्।

संस्करण v1.1 कसरी सक्षम गर्ने

संस्करण हाल मा उपलब्ध छ च्यानल 1.1 ea (च्यानलहरूमा स्थिर и ढु rock्गा ठोस स्थिरीकरण हुँदा रिलीजहरू देखा पर्नेछ, तथापि 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 प्रयोग गर्दै»;
  • «werf मा मोनोरेपो र मल्टिरेपोको लागि समर्थन र डकर रजिस्ट्रीले यससँग के गर्नुपर्दछ»;
  • «तपाईं अब नियमित डकरफाइल प्रयोग गरेर डकर छविहरू werf मा निर्माण गर्न सक्नुहुन्छ"।

स्रोत: www.habr.com