वेयरफ में मोनोरपो और मल्टीरेपो के लिए समर्थन और डॉकर रजिस्ट्री को इसके साथ क्या करना है?

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

वेयरफ में मोनो-रेपो के लिए हालिया समर्थन एक अच्छा उदाहरण है। लेकिन पहले, आइए देखें कि यह समर्थन आम तौर पर वेयरफ के उपयोग से जुड़ा हुआ है और डॉक रजिस्ट्री को इसके साथ क्या करना है ...

समस्याओं

इस स्थिति की कल्पना कीजिए। कंपनी के पास कई विकास दल हैं जो स्वतंत्र परियोजनाओं में शामिल हैं। अधिकांश एप्लिकेशन कुबेरनेट पर चलते हैं और तदनुसार, कंटेनरीकृत होते हैं। कंटेनरों, छवियों को संग्रहीत करने के लिए, एक रजिस्ट्री की आवश्यकता होती है। कंपनी ऐसी रजिस्ट्री के रूप में एकल COMPANY खाते के साथ डॉकर हब का उपयोग करती है। अधिकांश स्रोत कोड भंडारण प्रणालियों के समान, डॉकर हब आपको रिपॉजिटरी की नेस्टेड पदानुक्रम बनाने की अनुमति नहीं देता है जैसे कि COMPANY/PROJECT/IMAGE । इस मामले में ... प्रत्येक परियोजना के लिए एक अलग खाता बनाए बिना इस प्रतिबंध के साथ रजिस्ट्री में गैर-अखंड अनुप्रयोगों को कैसे रखा जा सकता है?



शायद वर्णित स्थिति किसी को पहले से परिचित है, लेकिन आइए सामान्य रूप से आवेदन भंडारण के आयोजन के मुद्दे को देखें, अर्थात्। उपरोक्त उदाहरण और डॉकर हब के संदर्भ के बिना।

समाधान के तरीके

यदि एप्लिकेशन अखंड है , एक छवि में आता है, तो कोई सवाल नहीं है और हम सिर्फ प्रोजेक्ट रिपॉजिटरी में छवियों को सहेजते हैं।

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

1. अलग नेस्टेड रिपॉजिटरी में चित्र स्टोर करें:
   
   
2. एक भंडार में सब कुछ स्टोर करें, और छवि का नाम टैग में ले लें, उदाहरण के लिए, निम्नानुसार है:
   
   

NB : वास्तव में, अभी भी विभिन्न रिपॉजिटरी में PROJECT-frontend और PROJECT-backend को संग्रहीत करने का विकल्प है, लेकिन हम उपयोगकर्ताओं के बीच समर्थन, संगठन और अधिकारों के वितरण की जटिलता के कारण इस पर विचार नहीं करेंगे।

समर्थन करते हैं

प्रारंभ में, werf ने खुद को नेस्टेड रिपॉजिटरी तक सीमित कर दिया - सौभाग्य से, अधिकांश रजिस्ट्रियां इस सुविधा का समर्थन करती हैं। संस्करण v1.0.4-अल्फा.3 के साथ शुरू, काम रजिस्ट्रियों के साथ जोड़ा गया है जिसमें घोंसले के शिकार का समर्थन नहीं किया जाता है , और उनके साथ डॉकर हब। इस क्षण से, उपयोगकर्ता के पास एक विकल्प था कि कैसे एप्लिकेशन छवियों को संग्रहीत किया जाए।

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

चूँकि अधिकांश वेयरफ विकल्प पर्यावरण चर के साथ सेट किए जा सकते हैं, CI / CD सिस्टम में, स्टोरेज मोड आमतौर पर पूरी परियोजना के लिए विश्व स्तर पर स्थापित करना आसान होता है। उदाहरण के लिए, गिटलैब के मामले में, प्रोजेक्ट सेटिंग्स में केवल पर्यावरण चर जोड़ें: सेटिंग्स -> CI / CD -> चर: WERF_IMAGES_REPO_MODE: multirepo|monorepo |

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

शैतान विस्तार से

नई संग्रहण पद्धति को जोड़ने पर अंतर और मुख्य कठिनाई रजिस्ट्री सफाई प्रक्रिया के दौरान है (वेयरफ द्वारा समर्थित सफाई विकल्पों के लिए, सफाई प्रक्रिया देखें) ।

सफाई करते समय, वेयरफ कुबेरनेट्स समूहों में उपयोग की जाने वाली छवियों के साथ-साथ उपयोगकर्ता-कॉन्फ़िगर नीतियों को भी ध्यान में रखता है। नीतियाँ रणनीतियों में टैग विभाजित करने पर आधारित होती हैं। वर्तमान में समर्थित रणनीतियाँ:

1. Git आदिम से संबंधित 3 रणनीतियाँ, जैसे टैग, शाखा और वचन;
2. कस्टम टैग के लिए 1 रणनीति।

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

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

एनबी : यदि आप हर्फ स्रोत कोड में वर्णित सभी चीजों को देखने में रुचि रखते हैं, तो पीआर 1684 एक प्रारंभिक बिंदु के रूप में काम कर सकता है।

इस लेख में, हम अपने दृष्टिकोण की समस्याओं और औचित्य पर अधिक ध्यान नहीं देंगे: टैगिंग रणनीतियों, लेबल में डेटा भंडारण और संपूर्ण रूप में प्रकाशन प्रक्रिया के बारे में - दिमित्री स्टोलारोव द्वारा हालिया रिपोर्ट में विस्तार से वर्णन किया गया है: " सीएफ / सीडी के लिए हमारा टूल है कुबेरनेट्स । "

सारांश

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

हमारे साथ रहें और बहुत जल्द हम आपको werf में अन्य नवाचारों के बारे में बताएंगे !

पुनश्च

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

• " अब आप डॉक में छवियों को इकट्ठा कर सकते हैं सामान्य डॉकफाइल का उपयोग करके ";
• " Werf Kubernetes (समीक्षा और वीडियो रिपोर्ट) में हमारे CI / CD टूल है ।"