आसानी से microconfig.io के साथ माइक्रोसॉर्फ़ कॉन्फ़िगरेशन का प्रबंधन करें

माइक्रोसर्विस के विकास और उसके बाद के संचालन में मुख्य समस्याओं में से एक उनके उदाहरणों की सक्षम और सटीक ट्यूनिंग है। मेरी राय में, नया microconfig.io ढांचा मदद कर सकता है। यह आपको अनुप्रयोगों को स्थापित करने के कुछ नियमित कार्यों को काफी शान्ति से हल करने की अनुमति देता है।

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

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

लेकिन पहले, अधिक सुविधा के लिए, हम पहले से microconfig.io प्लगइन स्थापित करके Idea IDE में एक खाली प्रोजेक्ट बनाएंगे:



हम प्लगइन लॉन्च कॉन्फ़िगरेशन को कॉन्फ़िगर करते हैं, आप डिफ़ॉल्ट कॉन्फ़िगरेशन का उपयोग कर सकते हैं, जैसा कि ऊपर दिए गए स्क्रीनशॉट में है।

हमारी सेवा को ऑर्डर कहा जाता है, फिर एक नई परियोजना में हम एक समान संरचना बनाएंगे:



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

Dev.yaml फ़ाइल की संरचना काफी सरल होगी:

mainorder: components: - order 

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

आदेश सेवा सेटिंग्स में ही फ़ाइल, हम संकेत करेंगे कि अब तक केवल एक पैरामीटर:

 spring.application.name: order 

अब प्लगइन चलाएं और यह गुणों में निर्दिष्ट पथ के अनुसार हमारे लिए हमारी सेवा का वांछित कॉन्फ़िगरेशन उत्पन्न करेगा:



आप प्लगइन के वितरण किट को डाउनलोड करके और कमांड लाइन से इसे चलाने के बिना प्लगइन स्थापित किए बिना कर सकते हैं ।
यह समाधान बिल्ड सर्वर पर उपयोग के लिए उपयुक्त है।

यह ध्यान देने योग्य है कि रूपरेखा पूरी तरह से संपत्ति सिंटैक्स को समझती है, अर्थात, साधारण संपत्ति फाइलें जो यमल कॉन्फ़िगरेशन में एक साथ उपयोग की जा सकती हैं।

एक और भुगतान सेवा जोड़ें और एक ही समय में मौजूदा को जटिल करें।
क्रम में :

 eureka: instance.preferIpAddress: true client: serviceUrl: defaultZone: http://192.89.89.111:6782/eureka/ server.port: 9999 spring.application.name: order db.url: 192.168.0.100 

भुगतान में :

 eureka: instance.preferIpAddress: true client: serviceUrl: defaultZone: http://192.89.89.111:6782/eureka/ server.port: 9998 spring.application.name: payments db.url: 192.168.0.100 

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



और हमारे प्रत्येक प्रोजेक्ट में अब हम #include eureka लाइन जोड़ेंगे।

फ़्रेमवर्क स्वचालित रूप से यूरेका कॉन्फ़िगरेशन को खोज लेगा और इसे सेवा कॉन्फ़िगरेशन फ़ाइलों में कॉपी कर देगा, जबकि एक अलग यूरेका कॉन्फ़िगरेशन नहीं बनाया जाएगा, क्योंकि हम इसे dev.yaml वातावरण फ़ाइल में निर्दिष्ट नहीं करेंगे। सेवा क्रम :

 #include eureka server.port: 9999 spring.application.name: order db.url: 192.168.0.100 

हम आयात लाइन को #include eureka, oracle में बदलकर डेटाबेस सेटिंग्स को एक अलग कॉन्फ़िगरेशन में भी बना सकते हैं।

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

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

एक अच्छा समाधान सभी कॉन्फ़िगरेशन को एक कॉन्फ़िगरेशन में रखना होगा जो अन्य संदर्भ दे सकते हैं। ऐसा करने के लिए, प्लेसहोल्डर्स के समर्थन को फ्रेमवर्क में पेश किया गया है। यहां बताया गया है कि यूरेका कॉन्फ़िगरेशन फ़ाइल कैसे बदलती है:

  client: serviceUrl: defaultZone: http://${endpoints@eurekaip}:6782/eureka/ 

अब देखते हैं कि यह प्लेसहोल्डर कैसे काम करता है। सिस्टम एंडपॉइंट्स नामक एक घटक को खोजता है और इसमें यूरेकाॅप की तलाश करता है, और फिर इसे हमारे कॉन्फ़िगरेशन में स्थानापन्न करता है। लेकिन विभिन्न वातावरण के बारे में क्या? ऐसा करने के लिए, निम्न प्रकार के application.dev.yaml के समापन बिंदु में सेटिंग फ़ाइल बनाएँ। फ़ाइल एक्सटेंशन द्वारा स्वतंत्र रूप से फ्रेमवर्क, तय करता है कि यह कॉन्फ़िगरेशन किस वातावरण से संबंधित है और इसे लोड करता है:



देव फ़ाइल की सामग्री:

 eurekaip: 192.89.89.111 dbip: 192.168.0.100 

हम अपनी सेवाओं के बंदरगाहों के लिए समान विन्यास बना सकते हैं:

 server.port: ${ports@order}. 

सभी महत्वपूर्ण सेटिंग्स एक ही स्थान पर हैं, जिससे कॉन्फ़िगरेशन फ़ाइलों में बिखरे मापदंडों के कारण त्रुटि की संभावना कम हो जाती है।

फ्रेमवर्क कई तैयार किए गए प्लेसहोल्डर्स प्रदान करता है, उदाहरण के लिए, आप उस निर्देशिका का नाम प्राप्त कर सकते हैं जिसमें कॉन्फ़िगरेशन फ़ाइल स्थित है और असाइन करें:

 #include eureka, oracle server.port: ${ports@order} spring.application.name: ${this@name} 

इसके कारण, कॉन्फ़िगरेशन में एप्लिकेशन के नाम को अतिरिक्त रूप से निर्दिष्ट करने की आवश्यकता नहीं है और इसे एक समान मॉड्यूल में भी ले जाया जा सकता है, उदाहरण के लिए:

 client: serviceUrl: defaultZone: http://${endpoints@eurekaip}:6782/eureka/ spring.application.name: ${this@name} 

ऑर्डर कॉन्फ़िगरेशन फ़ाइल एक पंक्ति में कम हो जाएगी:

 #include eureka, oracle server.port: ${ports@order} 

यदि हमें मूल कॉन्फ़िगरेशन से किसी सेटिंग की आवश्यकता नहीं है, तो हम इसे अपने कॉन्फ़िगरेशन में निर्दिष्ट कर सकते हैं और इसे पीढ़ी के दौरान लागू किया जाएगा। यही है, अगर किसी कारण से हमें ऑर्डर सेवा के लिए एक अद्वितीय नाम की आवश्यकता है, तो बस spring.application.name पैरामीटर छोड़ दें।

मान लें कि आपको सेवा में कस्टम लॉगिंग सेटिंग्स जोड़ने की आवश्यकता है, जो एक अलग फ़ाइल में संग्रहीत हैं, उदाहरण के लिए, logback.xml । इसके लिए सेटिंग्स का एक अलग समूह बनाएं:



मूल कॉन्फ़िगरेशन में, हम उस रूपरेखा को इंगित करेंगे जहां लॉगिंग सेटिंग फ़ाइल को रखने के लिए हमें @ConfigDir स्थान सेवाओं का उपयोग करने की आवश्यकता है:

 microconfig.template.logback.fromFile: ${logback@configDir}/logback.xml 

Logback.xml फ़ाइल में, हम मानक एपेंडरों को कॉन्फ़िगर करते हैं, जिसमें बदले में प्लेसहोल्डर भी हो सकते हैं, जो कि कॉन्फ़िगरेशन की पीढ़ी के दौरान बदल जाएगा, उदाहरण के लिए:

 <file>logs/${this@name}.log</file> 

सेवा कॉन्फ़िगरेशन में लॉगबैक आयात जोड़ना, हम स्वचालित रूप से प्रत्येक सेवा के लिए कॉन्फ़िगर किए गए लॉगिंग प्राप्त करते हैं:

 #include eureka, oracle, logback server.port: ${ports@order} 

यह अपने आप को सभी उपलब्ध रूपरेखा प्लेसहोल्डर्स के साथ और अधिक विस्तार से परिचित करने का समय है:

$ {यह @ env} - वर्तमान परिवेश का नाम लौटाता है।
$ {... @ नाम} - घटक का नाम लौटाता है।
$ {... @ configDir} - घटक के विन्यास निर्देशिका में पूर्ण पथ देता है।
$ {... @ resultDir} - घटक के गंतव्य निर्देशिका के लिए पूरा रास्ता देता है (प्राप्त फाइलें इस निर्देशिका में रखी जाएगी)।
$ {यह @ configRoot} - कॉन्फ़िगरेशन स्टोर के रूट डायरेक्टरी में पूरा रास्ता देता है।

सिस्टम आपको पर्यावरण चर प्राप्त करने की अनुमति देता है, उदाहरण के लिए, जावा का रास्ता:
$ {env @ JAVA_HOME}
या, JAVA में फ्रेमवर्क लिखे जाने के बाद से, हम सिस्टम वेरिएबल्स को कॉलिंग सिस्टम के समान प्राप्त कर सकते हैं :: getProperty इस तरह से एक निर्माण का उपयोग कर:
${system@os.name}
यह स्प्रिंग ईएल एक्सटेंशन भाषा के लिए समर्थन का उल्लेख करने योग्य है। कॉन्फ़िगरेशन में, समान अभिव्यक्तियाँ लागू होती हैं:

 connection.timeoutInMs: #{5 * 60 * 1000} datasource.maximum-pool-size: #{${this@datasource.minimum-pool-size} + 10} 

और आप #वर एक्सप्रेशन का उपयोग करके कॉन्फ़िगरेशन फ़ाइलों में स्थानीय चर का उपयोग कर सकते हैं:

 #var feedRoot: ${system@user.home}/feed folder: root: ${this@feedRoot} success: ${this@feedRoot}/archive error: ${this@feedRoot}/error 

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

यदि आप इस ढांचे में रुचि रखते हैं, तो मैं आपको इसके आधिकारिक पृष्ठ पर जाने और पूर्ण प्रलेखन पढ़ने, या यहां स्रोत में तल्लीन करने की सलाह देता हूं।