microconfig.io-এর মাধ্যমে সহজেই মাইক্রোসার্ভিস কনফিগারেশন পরিচালনা করুন

মাইক্রোসার্ভিসগুলির বিকাশ এবং পরবর্তী অপারেশনের প্রধান সমস্যাগুলির মধ্যে একটি হল তাদের উদাহরণগুলির উপযুক্ত এবং সঠিক কনফিগারেশন। আমার মতে, একটি নতুন কাঠামো এটির সাথে সাহায্য করতে পারে microconfig.io. এটি আপনাকে কিছু রুটিন অ্যাপ্লিকেশন কনফিগারেশন কাজগুলিকে বেশ মার্জিতভাবে সমাধান করতে দেয়।

আপনার যদি অনেকগুলি মাইক্রোসার্ভিস থাকে, এবং সেগুলির প্রত্যেকটি নিজস্ব কনফিগারেশন ফাইল/ফাইল নিয়ে আসে, তবে তাদের মধ্যে একটিতে একটি ত্রুটি করার উচ্চ সম্ভাবনা রয়েছে, যা সঠিক দক্ষতা এবং একটি লগিং সিস্টেম ছাড়া ধরা খুব কঠিন হতে পারে। ফ্রেমওয়ার্ক নিজের জন্য যে প্রধান কাজটি সেট করে তা হল ডুপ্লিকেট ইনস্ট্যান্স কনফিগারেশন প্যারামিটারগুলিকে ন্যূনতম করা, যার ফলে একটি ত্রুটি যুক্ত করার সম্ভাবনা হ্রাস করা।

এর একটি উদাহরণ তাকান. ধরা যাক আমাদের কাছে একটি কনফিগারেশন ফাইল সহ একটি সাধারণ অ্যাপ্লিকেশন রয়েছে ইয়ামল. এটি যেকোনো ভাষায় যেকোনো মাইক্রোসার্ভিস হতে পারে। চলুন দেখে নেওয়া যাক কিভাবে এই সার্ভিসে ফ্রেমওয়ার্ক প্রয়োগ করা যায়।

তবে প্রথমে, আরও সুবিধার জন্য, আসুন আইডিয়া আইডিইতে একটি খালি প্রকল্প তৈরি করি, এতে microconfig.io প্লাগইন ইনস্টল করার পরে:

আমরা প্লাগইন লঞ্চ কনফিগারেশন সেট আপ, আপনি ডিফল্ট কনফিগারেশন ব্যবহার করতে পারেন, উপরের স্ক্রিনশট হিসাবে.

আমাদের পরিষেবাকে অর্ডার বলা হয়, তারপরে একটি নতুন প্রকল্পে আমরা একটি অনুরূপ কাঠামো তৈরি করব:

পরিষেবার নামের সাথে ফোল্ডারে কনফিগারেশন ফাইল রাখুন - application.yaml. সমস্ত মাইক্রোসার্ভিসগুলি এক ধরণের পরিবেশে চালু করা হয়, তাই, পরিষেবাটির জন্য একটি কনফিগারেশন তৈরি করার পাশাপাশি, পরিবেশ নিজেই বর্ণনা করা প্রয়োজন: এর জন্য আমরা একটি ফোল্ডার তৈরি করব envs এবং আমাদের কাজের পরিবেশের নামের সাথে এটিতে একটি ফাইল যুক্ত করুন। এইভাবে, কাঠামো পরিবেশে পরিষেবাগুলির জন্য কনফিগারেশন ফাইল তৈরি করবে দেব, যেহেতু এই প্যারামিটারটি প্লাগইন সেটিংসে সেট করা আছে।

ফাইল কাঠামো 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

এই কনফিগারেশনগুলির প্রধান সমস্যা হল পরিষেবা সেটিংসে প্রচুর পরিমাণে কপি-পেস্টের উপস্থিতি। এর পরিত্রাণ পেতে কিভাবে ফ্রেমওয়ার্ক সাহায্য করবে দেখুন. আসুন সবচেয়ে সুস্পষ্ট দিয়ে শুরু করি - কনফিগারেশনের উপস্থিতি ইউরেকা প্রতিটি মাইক্রোসার্ভিসের বর্ণনায়। আসুন সেটিংস ফাইলের সাথে একটি নতুন ডিরেক্টরি তৈরি করি এবং এতে একটি নতুন কনফিগারেশন যোগ করি:

এবং এখন আমাদের প্রতিটি প্রকল্পে লাইন যোগ করা যাক #ইউরেকা অন্তর্ভুক্ত.

ফ্রেমওয়ার্ক স্বয়ংক্রিয়ভাবে ইউরেকা কনফিগারেশন খুঁজে পাবে এবং পরিষেবা কনফিগারেশন ফাইলগুলিতে এটি অনুলিপি করবে, যখন একটি পৃথক ইউরেকা কনফিগারেশন তৈরি করা হবে না, যেহেতু আমরা এটি পরিবেশ ফাইলে নির্দিষ্ট করব না। dev.yaml. সার্ভিস ক্রম:

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

আমরা আমদানি লাইন পরিবর্তন করে ডাটাবেস সেটিংসকে একটি পৃথক কনফিগারেশনে স্থানান্তর করতে পারি #ইউরেকা, ওরাকল অন্তর্ভুক্ত করুন.

এটি লক্ষণীয় যে কনফিগারেশন ফাইলগুলি পুনরায় তৈরি করার সময় ফ্রেমওয়ার্ক প্রতিটি পরিবর্তনকে ট্র্যাক করে এবং এটিকে প্রধান কনফিগারেশন ফাইলের পাশে একটি বিশেষ ফাইলে রাখে। এর লগের এন্ট্রিটি এইরকম দেখাচ্ছে: “সংরক্ষিত 1টি সম্পত্তিতে পরিবর্তন হয় order/diff-application.yaml" এটি আপনাকে বড় কনফিগারেশন ফাইলগুলির পরিবর্তনগুলি দ্রুত সনাক্ত করতে দেয়।

কনফিগারেশনের সাধারণ অংশগুলি মুছে ফেলার ফলে আপনি প্রচুর অপ্রয়োজনীয় কপি-পেস্ট থেকে পরিত্রাণ পেতে পারেন, কিন্তু আপনাকে নমনীয়ভাবে বিভিন্ন পরিবেশের জন্য একটি কনফিগারেশন তৈরি করতে দেয় না - আমাদের পরিষেবাগুলির শেষ পয়েন্টগুলি অনন্য এবং হার্ড-কোডেড, এটি খারাপ। এর এই অপসারণ করার চেষ্টা করা যাক.

একটি ভাল সমাধান হল সমস্ত শেষ পয়েন্টগুলিকে একটি কনফিগারেশনে রাখা যা অন্যরা উল্লেখ করতে পারে। এই উদ্দেশ্যে, স্থানধারকদের জন্য সমর্থন কাঠামোর মধ্যে চালু করা হয়েছে। এইভাবে কনফিগারেশন ফাইল পরিবর্তন হবে ইউরেকা:

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

এখন দেখা যাক কিভাবে এই স্থানধারক কাজ করে। সিস্টেম নামের একটি উপাদান খুঁজে পায় এন্ড পয়েন্ট এবং এর অর্থ খোঁজে ইউরেকাইপ, এবং তারপর এটিকে আমাদের কনফিগারেশনে প্রতিস্থাপন করে। কিন্তু বিভিন্ন পরিবেশ সম্পর্কে কি? এটি করার জন্য, একটি সেটিংস ফাইল তৈরি করুন এন্ড পয়েন্ট নিম্নলিখিত প্রকার আবেদন.দেব.ইয়ামল. ফ্রেমওয়ার্ক স্বাধীনভাবে, ফাইল এক্সটেনশনের উপর ভিত্তি করে, এই কনফিগারেশনটি কোন পরিবেশের অন্তর্গত তা নির্ধারণ করে এবং এটি লোড করে:

ডেভ ফাইলের বিষয়বস্তু:

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. এর জন্য সেটিংসের একটি পৃথক গ্রুপ তৈরি করা যাক:

মৌলিক কনফিগারেশনে, আমরা একটি স্থানধারক ব্যবহার করে লগিং সেটিংস ফাইলটি কোথায় রাখতে হবে তা ফ্রেমওয়ার্ককে বলব। @ কনফিগডির:

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

ফাইলে logback.xml আমরা স্ট্যান্ডার্ড অ্যাপেন্ডার কনফিগার করি, যার ফলে প্লেসহোল্ডারও থাকতে পারে যে কনফিগারেশন তৈরির সময় কাঠামো পরিবর্তন হবে, উদাহরণস্বরূপ:

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

পরিষেবা কনফিগারেশনে আমদানি যোগ করে লগব্যাক, আমরা স্বয়ংক্রিয়ভাবে প্রতিটি পরিষেবার জন্য কনফিগার করা লগিং পাই:

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

ফ্রেমওয়ার্কের সমস্ত উপলব্ধ স্থানধারকগুলির সাথে আরও বিস্তারিতভাবে পরিচিত হওয়ার সময় এসেছে:

${this@env} - বর্তমান পরিবেশের নাম প্রদান করে।
${…@name} — উপাদানের নাম প্রদান করে।
${…@configDir} — কম্পোনেন্টের কনফিগার ডিরেক্টরিতে সম্পূর্ণ পাথ ফেরত দেয়।
${…@resultDir} — কম্পোনেন্টের গন্তব্য ডিরেক্টরিতে সম্পূর্ণ পাথ ফেরত দেয় (ফলে ফাইলগুলি এই ডিরেক্টরিতে স্থাপন করা হবে)।
${this@configRoot} — কনফিগারেশন স্টোরের রুট ডিরেক্টরিতে সম্পূর্ণ পাথ ফেরত দেয়।

সিস্টেমটি আপনাকে এনভায়রনমেন্ট ভেরিয়েবলগুলি পেতে দেয়, উদাহরণস্বরূপ জাভা যাওয়ার পথ:
${env@JAVA_HOME}
হয়, যেহেতু ফ্রেমওয়ার্ক লেখা আছে জাভা, আমরা কলের অনুরূপ সিস্টেম ভেরিয়েবল পেতে পারি সিস্টেম::getProperty এই মত একটি কাঠামো ব্যবহার করে:
${[ইমেল সুরক্ষিত]}
এটি এক্সটেনশন ভাষার জন্য সমর্থন উল্লেখ করার মতো বসন্ত ইএল. নিম্নলিখিত অভিব্যক্তিগুলি কনফিগারেশনে প্রযোজ্য:

connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${[email protected]} + 10} 

এবং আপনি এক্সপ্রেশন ব্যবহার করে কনফিগারেশন ফাইলগুলিতে স্থানীয় ভেরিয়েবল ব্যবহার করতে পারেন #var:

#var feedRoot: ${[email protected]}/feed
folder:
 root: ${this@feedRoot}
 success: ${this@feedRoot}/archive
 error: ${this@feedRoot}/error

সুতরাং, ফ্রেমওয়ার্কটি মাইক্রোসার্ভিসেসের সূক্ষ্ম-টিউনিং এবং নমনীয় কনফিগারেশনের জন্য একটি মোটামুটি শক্তিশালী হাতিয়ার। ফ্রেমওয়ার্কটি তার প্রধান কাজটি পুরোপুরিভাবে পূরণ করে - সেটিংসে কপি-পেস্ট বাদ দেওয়া, সেটিংস একত্রিত করা এবং ফলস্বরূপ, সম্ভাব্য ত্রুটিগুলি হ্রাস করা, যখন আপনি সহজেই কনফিগারেশনগুলিকে একত্রিত করতে এবং বিভিন্ন পরিবেশের জন্য তাদের পরিবর্তন করতে পারবেন।

আপনি যদি এই ফ্রেমওয়ার্কটিতে আগ্রহী হন তবে আমি এটির অফিসিয়াল পৃষ্ঠাটি দেখার এবং সম্পূর্ণরূপে পরিচিত হওয়ার পরামর্শ দিচ্ছি ডকুমেন্টেশন, বা উত্স মধ্যে খনন এখানে.

উত্স: www.habr.com