werf मा मोनोरेपो र मल्टिरेपोको लागि समर्थन र डकर रजिस्ट्रीले यससँग के गर्नुपर्दछ

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

werf को हालको मोनो-रेपो समर्थन यसको राम्रो उदाहरण हो। तर पहिले, यो समर्थन सामान्यतया werf प्रयोग गर्नसँग कसरी सम्बन्धित छ र डकर रजिस्ट्रीले यससँग के गर्नु पर्छ भनेर पत्ता लगाउनुहोस् ...

मुद्दाहरू

यस्तो अवस्थाको कल्पना गरौं। कम्पनीसँग स्वतन्त्र परियोजनाहरूमा काम गर्ने धेरै विकास टोलीहरू छन्। धेरै जसो अनुप्रयोगहरू Kubernetes मा चल्छन् र त्यसैले कन्टेनराइज्ड हुन्छन्। कन्टेनरहरू, छविहरू भण्डारण गर्न, तपाईंलाई रजिस्ट्री (रजिस्ट्री) चाहिन्छ। यस्तो रजिस्ट्रीको रूपमा, कम्पनीले एकल खाताको साथ डकर हब प्रयोग गर्दछ COMPANY। धेरै स्रोत कोड भण्डारण प्रणाली जस्तै, डकर हबले नेस्टेड रिपोजिटरी पदानुक्रमलाई अनुमति दिँदैन, जस्तै COMPANY/PROJECT/IMAGE। त्यस अवस्थामा... तपाइँ कसरी प्रत्येक परियोजनाको लागि छुट्टै खाता सिर्जना नगरीकन यस सीमाको साथ रजिस्ट्रीमा गैर-मोनोलिथिक अनुप्रयोगहरू भण्डारण गर्न सक्नुहुन्छ?

सायद, वर्णन गरिएको अवस्था कसैलाई प्रत्यक्ष रूपमा परिचित छ, तर सामान्य रूपमा अनुप्रयोग भण्डारण व्यवस्थित गर्ने मुद्दालाई विचार गरौं, अर्थात्। माथिको उदाहरण र डकर हबको सन्दर्भ बिना।

समाधानहरू

यदि आवेदन मोनोलिथिक, एउटा छविमा आउँछ, त्यसपछि त्यहाँ कुनै प्रश्नहरू छैनन् र हामी केवल छविहरूलाई परियोजनाको कन्टेनर रजिस्ट्रीमा बचत गर्छौं।

जब एप्लिकेसनलाई धेरै कम्पोनेन्टको रूपमा प्रस्तुत गरिन्छ, सूक्ष्म सेवाहरूत्यसपछि एक निश्चित दृष्टिकोण आवश्यक छ। दुई तस्बिरहरू समावेश भएको सामान्य वेब अनुप्रयोगको उदाहरणमा: frontend и backend - सम्भावित विकल्पहरू हुन्:

1. तस्बिरहरूलाई छुट्टै नेस्टेड भण्डारहरूमा भण्डार गर्नुहोस्:

   

2. सबै कुरा एक भण्डारमा भण्डार गर्नुहोस्, र ट्यागमा छवि नामलाई विचार गर्नुहोस्, उदाहरणका लागि, निम्नानुसार:

   

NB: वास्तवमा, विभिन्न भण्डारहरूमा बचतको साथ अर्को विकल्प छ, PROJECT-frontend и PROJECT-backend, तर हामी समर्थन, संगठन र प्रयोगकर्ताहरू बीच अधिकारको वितरणको जटिलताको कारणले यसलाई विचार गर्दैनौं।

werf समर्थन

प्रारम्भमा, werf ले नेस्टेड रिपोजिटरीहरूमा सीमित गर्यो - सौभाग्य देखि, धेरै रजिस्ट्रीहरूले यो सुविधालाई समर्थन गर्दछ। संस्करणबाट सुरु गर्दै v1.0.4-alpha.3, रजिस्ट्रीहरूसँग काम थपियो जसमा नेस्टिङ समर्थित छैन, र डकर हब ती मध्ये एक हो। त्यस बिन्दुबाट, प्रयोगकर्तासँग अनुप्रयोग छविहरू कसरी भण्डार गर्ने भन्ने छनौट छ।

विकल्प अन्तर्गत कार्यान्वयन उपलब्ध छ --images-repo-mode=multirepo|monorepo (पूर्वनिर्धारित multirepo, अर्थात् नेस्टेड रिपोजिटरीहरूमा भण्डारण)। यसले ढाँचाहरू परिभाषित गर्दछ जसद्वारा छविहरू रजिस्ट्रीमा भण्डारण गरिन्छ। आधारभूत आदेशहरू प्रयोग गर्दा इच्छित मोड चयन गर्न पर्याप्त छ, र सबै कुरा अपरिवर्तित रहनेछ।

किनकि धेरै जसो werf विकल्पहरू सेट गर्न सकिन्छ वातावरण चर, CI / CD प्रणालीहरूमा, भण्डारण मोड सामान्यतया सम्पूर्ण परियोजनाको लागि विश्वव्यापी रूपमा सेट गर्न सजिलो हुन्छ। उदाहरणका लागि, GitLab को मामला मा केवल परियोजना सेटिङहरूमा वातावरण चर थप्नुहोस्: सेटिङहरू -> CI / CD -> चर: WERF_IMAGES_REPO_MODE: multirepo|monorepo.

यदि हामी छविहरू प्रकाशित गर्ने र अनुप्रयोगहरू रोल आउट गर्ने बारे कुरा गर्छौं (तपाईले यी प्रक्रियाहरूको बारेमा सान्दर्भिक कागजात लेखहरूमा विस्तृत रूपमा पढ्न सक्नुहुन्छ: प्रकाशन प्रक्रिया и डिप्लोय प्रक्रिया), त्यसपछि मोडले मात्र टेम्प्लेट निर्धारण गर्दछ जसद्वारा तपाइँ छविसँग काम गर्न सक्नुहुन्छ।

शैतान विवरणमा छ

नयाँ भण्डारण विधि थप्दा फरक र मुख्य कठिनाई रजिस्ट्री सफा गर्ने प्रक्रियामा छ (werf द्वारा समर्थित शुद्ध सुविधाहरूको लागि, हेर्नुहोस् सफाई प्रक्रिया).

सफा गर्दा, werf ले Kubernetes क्लस्टरहरूमा प्रयोग गरिएका छविहरू, साथै प्रयोगकर्ताद्वारा कन्फिगर गरिएका नीतिहरूलाई ध्यानमा राख्छ। नीतिहरू रणनीतिहरूमा ट्यागहरूको विभाजनमा आधारित हुन्छन्। हाल समर्थित रणनीतिहरू:

1. 3 रणनीतिहरू ट्याग, शाखा, र कमिट जस्ता Git आदिम द्वारा जोडिएको;
2. मनमानी अनुकूलन ट्यागहरूको लागि 1 रणनीति।

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

एक भण्डारमा बचत गर्दा (monorepo), छवि ट्यागमा, मेटा ट्यागको अतिरिक्त, छविको नाम पनि भण्डारण गर्न सकिन्छ: PROJECT:frontend-META-TAG। तिनीहरूलाई अलग गर्न, हामीले कुनै विशेष विभाजक परिचय दिएनौं, तर प्रकाशन गर्दा अन्तिम छविको लेबलमा आवश्यक मान थपेका छौं।

NB: यदि तपाइँ werf स्रोत कोडमा वर्णन गरिएका सबै कुराहरू हेर्न इच्छुक हुनुहुन्छ भने, त्यसपछि सुरूवात बिन्दु हुन सक्छ पीआर 1684.

यस लेखमा, हामी हाम्रो दृष्टिकोणको समस्या र औचित्यमा थप ध्यान दिनेछैनौं: ट्यागिङ रणनीतिहरू, लेबलहरूमा डाटा भण्डारण र समग्र रूपमा प्रकाशन प्रक्रियाको बारेमा - यो सबै दिमित्री स्टोल्यारोभ द्वारा हालैको रिपोर्टमा विस्तृत रूपमा वर्णन गरिएको छ: "werf Kubernetes मा CI/CD को लागि हाम्रो उपकरण हो"।

संक्षिप्त गर्न

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

हामीसँग रहनुहोस् र छिट्टै हामी तपाईंलाई अन्य आविष्कारहरूको बारेमा बताउनेछौं वाफ!

PS

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

• «तपाईं अब नियमित डकरफाइल प्रयोग गरेर डकर छविहरू werf मा निर्माण गर्न सक्नुहुन्छ»;
• «werf - Kubernetes मा CI / CD को लागि हाम्रो उपकरण (अवलोकन र भिडियो रिपोर्ट)"।

स्रोत: www.habr.com