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

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

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

समस्याएँ

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

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

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

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

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

1. छवियों को अलग-अलग नेस्टेड रिपॉजिटरी में स्टोर करें:

   

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

   

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

वेयरफ समर्थन

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

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

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

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

शैतान विवरण में है

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

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

1. गिट प्रिमिटिव से जुड़ी 3 रणनीतियाँ जैसे टैग, ब्रांच और कमिट;
2. मनमाना कस्टम टैग के लिए 1 रणनीति।

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

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

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

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

सारांश

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

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

पुनश्च

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

• «अब आप नियमित डॉकरफाइल का उपयोग करके वेयरफ में डॉकर छवियां बना सकते हैं";
• «werf - कुबेरनेट्स में CI / CD के लिए हमारा टूल (अवलोकन और वीडियो रिपोर्ट)'.

स्रोत: www.habr.com