कन्टेनर छविहरूको "स्मार्ट" सफाईको समस्या र werf मा यसको समाधान

लेखले Kubernetes मा डेलिभर गरिएका क्लाउड नेटिभ अनुप्रयोगहरूको लागि आधुनिक CI/CD पाइपलाइनहरूको वास्तविकताहरूमा कन्टेनर रजिस्ट्रीहरू (डकर रजिस्ट्री र यसको एनालगहरू) मा जम्मा हुने छविहरू सफा गर्ने समस्याहरूको बारेमा छलफल गर्दछ। छविहरूको सान्दर्भिकताको लागि मुख्य मापदण्ड र स्वचालित सफाई, ठाउँ बचत र टोलीहरूको आवश्यकताहरू पूरा गर्नमा परिणामस्वरूप कठिनाइहरू दिइएको छ। अन्तमा, एउटा विशेष खुला स्रोत परियोजनाको उदाहरण प्रयोग गरेर, हामी तपाईंलाई यी कठिनाइहरूलाई कसरी पार गर्न सकिन्छ भनेर बताउनेछौं।

परिचय

कन्टेनर रजिस्ट्रीमा छविहरूको संख्या द्रुत रूपमा बढ्न सक्छ, थप भण्डारण ठाउँ लिन्छ र यसरी यसको लागतमा उल्लेखनीय वृद्धि हुन्छ। रजिस्ट्रीमा ओगटेको ठाउँको स्वीकार्य वृद्धिलाई नियन्त्रण गर्न, सीमित गर्न वा कायम राख्न, यो स्वीकार गरिन्छ:

1. छविहरूको लागि निश्चित संख्यामा ट्यागहरू प्रयोग गर्नुहोस्;
2. कुनै तरिकामा छविहरू सफा गर्नुहोस्।

पहिलो सीमा कहिलेकाहीँ साना टोलीहरूको लागि स्वीकार्य छ। यदि विकासकर्ताहरूसँग पर्याप्त स्थायी ट्यागहरू छन् (latest, main, test, boris आदि), रजिस्ट्री आकारमा फुल्ने छैन र लामो समयको लागि तपाईले यसलाई सफा गर्ने बारे सोच्नु पर्दैन। आखिर, सबै अप्रासंगिक तस्बिरहरू मेटाइन्छ, र त्यहाँ सफाईको लागि कुनै काम बाँकी छैन (सबै कुरा नियमित फोहोर संकलनकर्ताद्वारा गरिन्छ)।

यद्यपि, यो दृष्टिकोणले विकासलाई धेरै हदसम्म सीमित गर्दछ र आधुनिक CI/CD परियोजनाहरूमा विरलै लागू हुन्छ। विकासको अभिन्न अंग थियो स्वचालन, जसले तपाईंलाई प्रयोगकर्ताहरूलाई धेरै छिटो परीक्षण गर्न, डिप्लोय गर्न र नयाँ कार्यक्षमता प्रदान गर्न अनुमति दिन्छ। उदाहरणका लागि, हाम्रा सबै परियोजनाहरूमा, प्रत्येक प्रतिबद्धतासँग सीआई पाइपलाइन स्वचालित रूपमा सिर्जना गरिन्छ। यसमा, छविलाई भेला गरिन्छ, परीक्षण गरिन्छ, डिबग गर्न र बाँकी जाँचहरूका लागि विभिन्न Kubernetes सर्किटहरूमा रोल आउट गरिन्छ, र यदि सबै ठीक छ भने, परिवर्तनहरू अन्तिम प्रयोगकर्तामा पुग्छन्। र यो अब रकेट विज्ञान होइन, तर धेरैको लागि दैनिक घटना हो - सम्भवतः तपाइँको लागि, किनकि तपाइँ यो लेख पढ्दै हुनुहुन्छ।

बगहरू फिक्स गर्ने र नयाँ कार्यक्षमता विकास गर्ने कार्य समानान्तर रूपमा गरिन्छ, र रिलीजहरू दिनमा धेरै पटक प्रदर्शन गर्न सकिन्छ, यो स्पष्ट छ कि विकास प्रक्रिया महत्त्वपूर्ण संख्याको साथमा छ, जसको मतलब रजिस्ट्रीमा छविहरूको ठूलो संख्या। नतिजाको रूपमा, रजिस्ट्रीको प्रभावकारी सफाई व्यवस्थित गर्ने मुद्दा उठ्छ, अर्थात्। अप्रासंगिक छविहरू हटाउँदै।

तर तपाईं कसरी एक छवि सान्दर्भिक छ कि भनेर निर्धारण गर्न?

छविको प्रासंगिकताको लागि मापदण्ड

धेरै जसो केसहरूमा, मुख्य मापदण्डहरू हुनेछन्:

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

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

३. तेस्रो - विकासकर्ताको आवश्यकता: सबै छविहरू जुन तिनीहरूको हालको कामसँग सम्बन्धित छन्। उदाहरण को लागी, यदि हामी PR लाई विचार गर्दैछौं, त्यसपछि अन्तिम प्रतिबद्धता र भनौं, अघिल्लो प्रतिबद्धतासँग मिल्दोजुल्दो छवि छोड्नु अर्थपूर्ण हुन्छ: यस तरीकाले विकासकर्ताले कुनै पनि कार्यमा छिटो फर्कन सक्छ र नवीनतम परिवर्तनहरूसँग काम गर्न सक्छ।

4. चौथो - छविहरू हाम्रो अनुप्रयोगको संस्करण अनुरूप, अर्थात् अन्तिम उत्पादन हो: v1.0.0, 20.04.01/XNUMX/XNUMX, sierra, आदि।

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

योग्यता र अवस्थित समाधानहरू

कन्टेनर रजिस्ट्रीहरूसँग लोकप्रिय सेवाहरू, एक नियमको रूपमा, तिनीहरूको आफ्नै छवि सफाई नीतिहरू प्रस्ताव गर्छन्: तिनीहरूमा तपाइँले रजिस्ट्रीबाट ट्याग हटाउने सर्तहरू परिभाषित गर्न सक्नुहुन्छ। यद्यपि, यी सर्तहरू नाम, सिर्जना समय, र ट्यागहरूको संख्या* जस्ता प्यारामिटरहरूद्वारा सीमित छन्।

* विशिष्ट कन्टेनर रजिस्ट्री कार्यान्वयनमा निर्भर गर्दछ। हामीले निम्न समाधानहरूको सम्भावनाहरू विचार गर्यौं: Azure CR, Docker Hub, ECR, GCR, GitHub प्याकेजहरू, GitLab कन्टेनर रजिस्ट्री, हार्बर रजिस्ट्री, JFrog आर्टिफ्याक्ट्री, Quay.io - सेप्टेम्बर २०२० सम्म।

प्यारामिटरहरूको यो सेट चौथो मापदण्ड पूरा गर्न पर्याप्त छ - त्यो हो, संस्करणहरूसँग मेल खाने छविहरू चयन गर्न। यद्यपि, अन्य सबै मापदण्डहरूको लागि, अपेक्षा र वित्तीय क्षमताहरूमा निर्भर गर्दै - एक प्रकारको सम्झौता समाधान (एक कठिन वा, विपरित, अधिक उदार नीति) छनोट गर्नुपर्छ।

उदाहरणका लागि, तेस्रो मापदण्ड - विकासकर्ताहरूको आवश्यकतासँग सम्बन्धित - टोलीहरू भित्र प्रक्रियाहरू व्यवस्थित गरेर समाधान गर्न सकिन्छ: छविहरूको विशिष्ट नामकरण, विशेष अनुमति सूचीहरू र आन्तरिक सम्झौताहरू कायम राख्ने। तर अन्ततः यो अझै पनि स्वचालित हुन आवश्यक छ। र यदि तयार समाधानहरूको क्षमताहरू पर्याप्त छैनन् भने, तपाईंले आफ्नै केही गर्नुपर्छ।

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

Git मा कार्यप्रवाह को चित्रण

मानौं कि तपाइँ Git मा यस्तो केहि काम गर्दै हुनुहुन्छ:

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

के हुन्छ यदि क्लीनअप नीतिहरूले छविहरूलाई मात्र राख्न अनुमति दिन्छ (मेटिने छैन) दिइएको ट्याग नामहरू द्वारा?

निस्सन्देह, यस्तो परिदृश्यले कसैलाई खुशी बनाउँदैन।

यदि नीतिहरूले छविहरू मेटाउन नदिने अनुमति दिन्छ भने के परिवर्तन हुनेछ? दिइएको समय अन्तराल / अन्तिम कमिटहरूको संख्या अनुसार?

परिणाम धेरै राम्रो भएको छ, तर अझै पनि आदर्श देखि टाढा छ। जे भए पनि, हामीसँग अझै पनि विकासकर्ताहरू छन् जसलाई बगहरू डिबग गर्न रजिस्ट्रीमा छविहरू चाहिन्छ (वा K8s मा तैनाथ गरिएको छ)...

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

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

विश्वव्यापी छवि सफाईको लागि हाम्रो मार्ग

यो आवश्यकता कहाँबाट आयो? तथ्य यो हो कि हामी विकासकर्ताहरूको छुट्टै समूह होइनौं, तर एउटा टोली जसले तिनीहरूमध्ये धेरैलाई एकैचोटि सेवा दिन्छ, CI/CD समस्याहरूलाई व्यापक रूपमा समाधान गर्न मद्दत गर्दछ। र यसको लागि मुख्य प्राविधिक उपकरण खुला स्रोत उपयोगिता हो वाफ। यसको विशिष्टता यो हो कि यसले एकल प्रकार्य प्रदर्शन गर्दैन, तर सबै चरणहरूमा निरन्तर डेलिभरी प्रक्रियाहरू साथ दिन्छ: विधानसभा देखि तैनाती सम्म।

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

* यद्यपि दर्ताहरू आफैं फरक हुन सक्छन् (डकर रजिस्ट्री, GitLab कन्टेनर रजिस्ट्री, हार्बर, आदि), तिनीहरूका प्रयोगकर्ताहरूले समान समस्याहरूको सामना गर्छन्। हाम्रो मामला मा विश्वव्यापी समाधान रजिस्ट्री को कार्यान्वयन मा निर्भर छैन, किनभने आफैं रजिस्ट्रीहरू बाहिर चल्छ र सबैको लागि समान व्यवहार प्रस्ताव गर्दछ।

यद्यपि हामीले werf लाई उदाहरण कार्यान्वयनको रूपमा प्रयोग गर्दैछौं, हामी आशा गर्छौं कि प्रयोग गरिएका दृष्टिकोणहरू समान कठिनाइहरूको सामना गर्ने अन्य टोलीहरूको लागि उपयोगी हुनेछ।

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

यो मामूली समाधानले सबैभन्दा महत्त्वपूर्ण समस्या (मापदण्ड नम्बर 1) लाई हल गर्यो, तर सफाई संयन्त्र सुधार गर्न हाम्रो यात्राको सुरुवात मात्र थियो। अर्को - र धेरै रोचक - कदम निर्णय थियो Git इतिहास संग प्रकाशित छविहरू सम्बद्ध.

ट्यागिङ योजनाहरू

सुरु गर्नको लागि, हामीले एउटा दृष्टिकोण रोज्यौं जसमा अन्तिम छविले सफाईको लागि आवश्यक जानकारी भण्डार गर्नुपर्छ, र ट्यागिङ योजनाहरूमा प्रक्रिया निर्माण गर्‍यौं। छवि प्रकाशित गर्दा, प्रयोगकर्ताले एक विशिष्ट ट्यागिङ विकल्प चयन गर्यो (git-branch, git-commit वा git-tag) र सम्बन्धित मान प्रयोग गरियो। CI प्रणालीहरूमा, यी मानहरू वातावरण चरहरूमा आधारित स्वचालित रूपमा सेट गरिएका थिए। वास्तबमा अन्तिम छवि एक विशिष्ट Git आदिम संग सम्बन्धित थियो, लेबल मा सफाई को लागी आवश्यक डाटा भण्डारण।

यो दृष्टिकोणले नीतिहरूको सेटमा परिणाम दियो जसले Git लाई सत्यको एकल स्रोतको रूपमा प्रयोग गर्न अनुमति दियो:

• Git मा शाखा/ट्याग मेटाउँदा, रजिस्ट्रीमा सम्बन्धित छविहरू स्वचालित रूपमा मेटाइयो।
• Git ट्यागहरू र कमिटहरूसँग सम्बन्धित छविहरूको संख्या चयन गरिएको स्कीमामा प्रयोग गरिएको ट्यागहरूको संख्या र सम्बन्धित प्रतिबद्धता सिर्जना गरिएको समयद्वारा समायोजन गर्न सकिन्छ।

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

नयाँ एल्गोरिथ्म

किन? सामग्री-आधारित ट्यागिङको साथ, प्रत्येक ट्यागले Git मा धेरै कमिटहरू पूरा गर्न सक्छ। तस्बिरहरू सफा गर्दा, तपाईं अब मान्न सक्नुहुन्न मात्र कमिटबाट जहाँ नयाँ ट्याग रजिस्ट्रीमा थपिएको थियो।

नयाँ सफाई एल्गोरिदमको लागि, यो ट्यागिङ योजनाहरू र निर्माणबाट टाढा जाने निर्णय गरियो मेटा-छवि प्रक्रिया, जसमध्ये प्रत्येकले एउटा गुच्छा भण्डार गर्दछ:

• प्रतिबद्धता जसमा प्रकाशन गरिएको थियो (यसले फरक पार्दैन कि छवि थपियो, परिवर्तन भयो वा कन्टेनर रजिस्ट्रीमा उस्तै रह्यो);
• र भेला गरिएको छविसँग सम्बन्धित हाम्रो आन्तरिक पहिचानकर्ता।

अर्को शब्दमा, यो प्रदान गरिएको थियो Git मा कमिटहरूसँग प्रकाशित ट्यागहरू लिङ्क गर्दै.

अन्तिम कन्फिगरेसन र सामान्य एल्गोरिथ्म

सफाई कन्फिगर गर्दा, प्रयोगकर्ताहरूले हालका छविहरू चयन गर्ने नीतिहरूमा पहुँच राख्छन्। प्रत्येक यस्तो नीति परिभाषित गरिएको छ:

• धेरै सन्दर्भ, अर्थात् Git ट्यागहरू वा Git शाखाहरू जुन स्क्यानिङको समयमा प्रयोग गरिन्छ;
• र सेटबाट प्रत्येक सन्दर्भको लागि खोजी गरिएका छविहरूको सीमा।

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

cleanup:
  keepPolicies:
  - references:
      tag: /.*/
      limit:
        last: 10
  - references:
      branch: /.*/
      limit:
        last: 10
        in: 168h
        operator: And
    imagesPerReference:
      last: 2
      in: 168h
      operator: And
  - references:  
      branch: /^(main|staging|production)$/
    imagesPerReference:
      last: 10

यो कन्फिगरेसनले निम्न नियमहरूको पालना गर्ने तीनवटा नीतिहरू समावेश गर्दछ:

1. अन्तिम 10 Git ट्यागहरूको लागि छवि बचत गर्नुहोस् (ट्याग सिर्जना मिति द्वारा)।
2. पछिल्लो हप्तामा प्रकाशित 2 भन्दा बढी तस्बिरहरू गत हप्तामा गतिविधि भएका 10 थ्रेडहरू भन्दा बढीको लागि बचत नगर्नुहोस्।
3. शाखाहरूको लागि 10 छविहरू बचत गर्नुहोस् main, staging и production.

अन्तिम एल्गोरिथ्म निम्न चरणहरूमा उबलिन्छ:

• कन्टेनर रजिस्ट्रीबाट प्रकटहरू पुन: प्राप्त गर्दै।
• Kubernetes मा प्रयोग गरिएका छविहरू बाहेक, किनभने हामीले पहिले नै K8s API मा मतदान गरेर तिनीहरूलाई पूर्व-चयन गरिसकेका छौं।
• Git इतिहास स्क्यान गर्दै र निर्दिष्ट नीतिहरूमा आधारित छविहरू बाहेक।
• बाँकी छविहरू हटाउँदै।

हाम्रो दृष्टान्तमा फर्केर, यो werf सँग के हुन्छ:

यद्यपि, यदि तपाइँ werf प्रयोग गर्नुहुन्न भने, उन्नत छवि सफाईको लागि समान दृष्टिकोण - एक कार्यान्वयन वा अर्कोमा (छवि ट्यागिङको लागि मनपर्ने दृष्टिकोण अनुसार) - अन्य प्रणाली/उपयोगिताहरूमा लागू गर्न सकिन्छ। यो गर्नको लागि, यो समस्याहरू सम्झना गर्न पर्याप्त छ र तपाइँको स्ट्याकमा ती अवसरहरू फेला पार्नुहोस् जसले तपाइँलाई उनीहरूको समाधानलाई सकेसम्म सहज रूपमा एकीकृत गर्न अनुमति दिन्छ। हामी आशा गर्छौं कि हामीले यात्रा गरेको बाटोले तपाईंलाई नयाँ विवरण र विचारहरूको साथ तपाईंको विशेष केस हेर्न मद्दत गर्नेछ।

निष्कर्षमा

• ढिलो वा पछि, धेरै टोलीहरूले रजिस्ट्री ओभरफ्लोको समस्या सामना गर्छन्।
• समाधानहरू खोज्दा, छविको सान्दर्भिकताको लागि मापदण्ड निर्धारण गर्न पहिले आवश्यक छ।
• लोकप्रिय कन्टेनर रजिस्ट्री सेवाहरू द्वारा प्रस्तावित उपकरणहरूले तपाईंलाई "बाहिरको संसार" लाई ध्यानमा राख्दैन: कुबर्नेट्समा प्रयोग गरिएका छविहरू र टोलीको कार्यप्रवाहको विशेषताहरूलाई धेरै सरल सफाई व्यवस्थित गर्न अनुमति दिन्छ।
• लचिलो र कुशल एल्गोरिथ्ममा सीआई/सीडी प्रक्रियाहरूको बुझाइ हुनुपर्दछ र डकर छवि डाटासँग मात्र काम गर्दैन।

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «werf कलेक्टरमा सामग्री-आधारित ट्यागिङ: किन र कसरी यसले काम गर्छ?»;
• «वेर्फमा ३-मार्ग मर्ज: हेल्मको साथ कुबर्नेट्समा तैनाती "स्टेरोइडहरूमा"»;
• «werf मा मोनोरेपो र मल्टिरेपोको लागि समर्थन र डकर रजिस्ट्रीले यससँग के गर्नुपर्दछ»;
• «werf 1.1 रिलीज: आज निर्माणकर्तामा सुधारहरू र भविष्यका लागि योजनाहरू"।

स्रोत: www.habr.com