werf मधील मोनोरेपो आणि मल्टीरेपोसाठी समर्थन आणि डॉकर रजिस्ट्रीचा त्याच्याशी काय संबंध आहे

मोनो-रेपॉजिटरी विषयावर एकापेक्षा जास्त वेळा चर्चा केली गेली आहे आणि नियम म्हणून, खूप सक्रिय विवाद निर्माण करतो. निर्माण करून werf Git ते डॉकर इमेजेस ऍप्लिकेशन कोड बनवण्याच्या प्रक्रियेत सुधारणा करण्यासाठी डिझाइन केलेले एक मुक्त स्त्रोत साधन म्हणून (आणि नंतर ते कुबर्नेट्सवर वितरित करणे), कोणती निवड सर्वोत्तम आहे याबद्दल आम्ही जास्त विचार करत नाही. आमच्यासाठी, भिन्न मतांच्या समर्थकांसाठी आवश्यक असलेल्या सर्व गोष्टी प्रदान करणे प्राथमिक आहे (जर हे अर्थातच सामान्य ज्ञानाचा विरोध करत नसेल तर).

werf चे अलीकडील मोनो-रेपो सपोर्ट हे याचे उत्तम उदाहरण आहे. परंतु प्रथम, हे समर्थन सामान्यतः werf वापरण्याशी कसे संबंधित आहे आणि डॉकर रेजिस्ट्रीचा त्याच्याशी काय संबंध आहे ते शोधूया ...

मुद्दे

अशा परिस्थितीची कल्पना करूया. कंपनीकडे स्वतंत्र प्रकल्पांवर काम करणारे अनेक विकास कार्यसंघ आहेत. बहुतेक ऍप्लिकेशन्स कुबर्नेट्सवर चालतात आणि त्यामुळे कंटेनराइज्ड असतात. कंटेनर, प्रतिमा संग्रहित करण्यासाठी, आपल्याला नोंदणी (रेजिस्ट्री) आवश्यक आहे. अशी नोंदणी म्हणून, कंपनी एकाच खात्यासह डॉकर हब वापरते 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. टॅग, ब्रँच आणि कमिट यासारख्या Git प्रिमिटिव्हद्वारे जोडलेल्या 3 धोरणे;
2. अनियंत्रित सानुकूल टॅगसाठी 1 धोरण.

अंतिम प्रतिमेच्या लेबलमध्ये प्रतिमा प्रकाशित करताना आम्ही टॅग धोरणाबद्दल माहिती जतन करतो. अर्थ स्वतः तथाकथित आहे मेटा टॅग - काही पॉलिसी लागू करणे आवश्यक आहे. उदाहरणार्थ, गिट रेपॉजिटरीमधून शाखा किंवा टॅग हटवताना, संबंधित हटवणे तर्कसंगत आहे न वापरलेले रेजिस्ट्रीमधील प्रतिमा, ज्या आमच्या धोरणांच्या भागामध्ये समाविष्ट आहेत.

एका भांडारात जतन केल्यावर (monorepo), इमेज टॅगमध्ये, मेटा टॅग व्यतिरिक्त, इमेजचे नाव देखील संग्रहित केले जाऊ शकते: PROJECT:frontend-META-TAG. त्यांना वेगळे करण्यासाठी, आम्ही कोणताही विशिष्ट विभाजक सादर केला नाही, परंतु प्रकाशन करताना अंतिम प्रतिमेच्या लेबलमध्ये आवश्यक मूल्य जोडले.

NB: जर तुम्हाला werf सोर्स कोडमध्ये वर्णन केलेल्या सर्व गोष्टी पाहण्यात स्वारस्य असेल, तर सुरुवातीचा बिंदू असू शकतो जनसंपर्क 1684.

या लेखात, आम्ही आमच्या दृष्टिकोनाच्या समस्या आणि औचित्य यावर अधिक लक्ष देणार नाही: रणनीती टॅग करणे, लेबल्समध्ये डेटा संग्रहित करणे आणि संपूर्णपणे प्रकाशन प्रक्रिया - या सर्व गोष्टींचे तपशीलवार वर्णन दिमित्री स्टोलियारोव्हच्या अलीकडील अहवालात केले आहे: “werf हे Kubernetes मधील CI/CD साठी आमचे साधन आहे».

सारांश करणे

अननेस्‍ट रजिस्‍ट्रीजच्‍या समर्थनाचा अभाव हा आम्‍हाला किंवा आम्‍हाला ज्ञात असलेल्‍या werf वापरकर्त्‍यांसाठी अवरोधित करणारा घटक नव्हता - शेवटी, तुम्ही नेहमी एक वेगळी इमेज रेजिस्ट्री वाढवू शकता (किंवा Google Cloud मधील कंडिशनल कंटेनर रेजिस्ट्री वर स्विच करू शकता)... तथापि, विस्तीर्ण DevOps समुदायासाठी साधन अधिक सोयीस्कर होण्यासाठी असे निर्बंध काढून टाकणे तर्कसंगत वाटले. त्याची अंमलबजावणी करताना, आम्हाला कंटेनर रेजिस्ट्री क्लीनअप यंत्रणा पुन्हा कार्य करण्यात मुख्य अडचण आली. आता सर्व काही तयार झाले आहे, हे समजून घेणे चांगले आहे की हे एखाद्यासाठी सोपे झाले आहे आणि आम्हाला (प्रकल्पाचे मुख्य विकासक म्हणून) या वैशिष्ट्याचे समर्थन करण्यात कोणत्याही लक्षणीय अडचणी येणार नाहीत.

आमच्यासोबत रहा आणि लवकरच आम्ही तुम्हाला इतर नवकल्पनांबद्दल सांगू werf!

PS

आमच्या ब्लॉगवर देखील वाचा:

• «तुम्ही आता नियमित Dockerfile वापरून werf मध्ये डॉकर प्रतिमा तयार करू शकता";
• «werf - Kubernetes मधील CI/CD साठी आमचे साधन (विहंगावलोकन आणि व्हिडिओ अहवाल)».

स्त्रोत: www.habr.com