Carnotzet के साथ मॉड्यूलर और पुन: प्रयोज्य डॉकर पर्यावरण

हमने एक टूल बनाया जो डॉकटर और मावेन को एकीकृत करता है ताकि हमारे सैकड़ों डेवलपर्स कम से कम प्रयास के साथ सैकड़ों विकास के साथ जटिल विकास वातावरण का प्रबंधन कर सकें। यह एक कहानी है कि कैसे एक पागल विचार एक वास्तविकता बन गया। यह Carnotzet की कहानी है।

यह सब लगभग पांच साल पहले शुरू हुआ था (लगभग प्रकाशन की तारीख 3 अगस्त, 2017), स्विसक्वेट जल्दी से विकसित और विकसित हुआ। उस समय, हमारे पास लगभग 70 डेवलपर्स बड़े (लगभग अखंड) जावा प्रोजेक्ट पर काम कर रहे थे, उनमें से प्रत्येक को स्थानीय रूप से प्रोजेक्ट के लॉन्च को कॉन्फ़िगर करने के लिए 1 से 2 दिन खर्च करने की आवश्यकता थी। हम दोहराए जाने वाले कार्यों पर समय बर्बाद करने से नफरत करते हैं! इसलिए, हमारे स्थानीय विकास वातावरण की तैनाती को स्वचालित करने के लिए वैग्रैंट और शेफ का उपयोग करके इस प्रक्रिया में सुधार करने का निर्णय लिया गया। इसने हमारे पहले सैंडबॉक्स प्रोजेक्ट (सैंडबॉक्स, लगभग) की शुरुआत को चिह्नित किया।

हम हल्के, प्रतिलिपि प्रस्तुत करने योग्य, पृथक और पोर्टेबल विकास और परीक्षण वातावरण साझा करना चाहते हैं।

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

इसके बाद, इन बड़े अनुप्रयोगों पर काम करना इस तथ्य के कारण और अधिक कठिन हो गया कि व्यावसायिक तर्क अधिक जटिल हो गए (हमारे ट्रेडिंग प्लेटफॉर्म का व्हाइट-लेबलिंग)। और हमने यह करने का फैसला किया कि 2014 में अधिकांश संगठनों ने क्या किया: तर्क को माइक्रोसर्विस में तोड़ दिया।

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



हमें इसे ठीक करना था।

हमारे सैंडबॉक्स की निम्न कमजोरियों की पहचान की गई:

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

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

हमने केवल डॉकटर-कंपोज़ का उपयोग करने पर भी विचार किया। यह बहुत ही आशाजनक लग रहा था, लेकिन इसके नाम के बावजूद, इसमें रचना की संभावना के रूप में ऐसी चीजों का अभाव था, और, एक ही समय में, अमूर्त और पुन: उपयोग। यह वे पहलू हैं जिनकी हमें जरूरत थी। हमने मौजूदा विकास / परीक्षण वातावरण को लेने में सक्षम होने का सपना देखा, इसके लिए एक सेवा और वैकल्पिक रूप से इसके विन्यास के हिस्से को फिर से परिभाषित किया। हम इसे जोड़ा सेवा के कॉन्फ़िगरेशन की प्रतिलिपि बनाए बिना या सकर्मक निर्भरताओं और उनके कॉन्फ़िगरेशन के विवरण में तल्लीन करना चाहते थे।

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

कई प्रयासों के बाद, हम निम्नलिखित समाधान पर आए:

• प्रत्येक मावेन विरूपण साक्ष्य पूरी तरह कार्यात्मक वातावरण का प्रतिनिधित्व करता है जिसे अन्य वातावरणों में एक निर्भरता के रूप में इस्तेमाल किया जा सकता है। (न्यूनतम वातावरण को एक सेवा द्वारा दर्शाया जा सकता है, उदाहरण के लिए, एक डेटाबेस)
• JAR फ़ाइलों में कॉन्फ़िगरेशन होता है। पर्यावरण चर, अनुप्रयोग कॉन्फ़िगरेशन फ़ाइलें, छवि डॉकर नाम, आदि।
• यदि आवश्यक हो तो निर्भरता पदानुक्रम में उच्चतर स्थित मॉड्यूल में इस कॉन्फ़िगरेशन को ओवरराइड किया जा सकता है।
• जावा लाइब्रेरी एक मावेन मॉड्यूल (GAV या pom.xml) से पूरा वातावरण (हुड के नीचे docker- रचना का उपयोग करके) उठा सकती है

मावेन इन कलाकृतियों ("पर्यावरण कलाकृतियों") को वितरित और संस्करण करना संभव बनाता है और हम आसानी से टीमों के बीच स्रोत कोड साझा कर सकते हैं। प्रक्रिया सरल हो गई और डेवलपर्स ने अन्य टीमों के मॉड्यूल का उपयोग करना शुरू कर दिया। और अपना भी बनाए और बनाए रखें।

एक बोनस के रूप में, मावेन के साथ काम करने वाले सभी उपकरणों का उपयोग यहां किया जा सकता है। एक उदाहरण के रूप में, IntelliJ IDEA का उपयोग करके उत्पन्न निर्भरता ग्राफ अब हमें हमारे आश्रित की बातचीत के लिए वास्तुकला का एक चित्र दिखाता है :)


डॉकटर-कंपोज़ से एक वोटिंग एप्लिकेशन उदाहरण का आर्किटेक्चर

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

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

हम वर्तमान में इस तकनीक का पुन: उपयोग करने के तरीके का अध्ययन कर रहे हैं कि हमारे यूएटी / एकीकरण वातावरण को प्रबंधित करने के लिए कुबेरनेट्स में डॉकटर-कम्पोज़ के बजाय कंटेनर लॉन्च करके, और इस तरह रोलिंग-अपडेट और कंप्यूटिंग लोच को काफी बड़े वातावरण पर सुनिश्चित करें।

मुझे आशा है कि आपको यह जानकर खुशी होगी कि हमारी परियोजना Apache 2.0 लाइसेंस के तहत खोली गई थी और यह Github पर उपलब्ध है: github.com/swissquote/carnotzet

उपयोग :)