Лёгкае кіраванне канфігурацыямі мікрасэрвісаў з дапамогай microconfig.io

Адной з асноўных праблем пры распрацоўцы і наступнай эксплуатацыі мікрасэрвісаў з'яўляецца пісьменная і акуратная настройка іх інстансаў. У гэтым, на мой погляд, можа дапамагчы новы фрэймворк. microconfig.io. Ён дазваляе даволі элегантна вырашыць некаторыя руцінныя задачы наладкі прыкладанняў.

Калі ў вас шмат мікрасэрвісаў, і кожны з іх пастаўляецца разам са сваім файлам/файламі налад, то вялікая верагоднасць здзейсніць памылку ў адным з іх, якую без належнага спрыту і сістэмы лагавання можа быць вельмі не проста адлавіць. Асноўная задача, якую перад сабой ставіць фрэймворк - звесці да мінімуму дублюючыя параметры налады інстанса, тым самым паменшыць верагоднасць дадання памылкі.

Разгледзім на прыкладзе. Дапусцім, што ёсць простае дадатак з файлам канфігурацыі ямл. Гэта можа быць любы мікрасэрвіс на любой мове. Паглядзім, як фрэймворк можна прымяніць да гэтага сэрвісу.

Але перш, для большай выгоды, створым пусты праект у Idea IDE, папярэдне ўсталяваўшы ў ёй убудова microconfig.io:

Наладжваем канфігурацыю запуску плагіна, можна выкарыстоўваць канфігурацыю па змаўчанні, як на скрыншоце зверху.

Наш сэрвіс завецца order, тады ў новым праекце створым падобную структуру:

У тэчку з імем сэрвісу змяшчаем файл канфігурацыі — application.yaml. Усе мікрасэрвісы запускаюцца ў нейкім асяроддзі, так што, акрамя стварэння канфіга самога сэрвісу, неабходна апісаць само асяроддзе: для гэтага створым тэчку envs і дадамо ў яе файл з імем нашага працоўнага асяроддзя. Такім чынам, фрэймворк створыць канфігурацыйныя файлы для сэрвісаў у асяроддзі. DEV, бо ў наладах у плагіна ўсталяваны менавіта гэты параметр.

Структура файла dev.yaml будзе даволі простая:

mainorder:
    components:
         - order

Фрэймворк працуе з канфігурацыямі, якія аб'яднаны ў групы. Для нашага сэрвісу выберам імя для групы mainorder. Фрэймворк знаходзіць кожную такую ​​групу прыкладанняў у файле асяродкаў і стварае для ўсіх з іх канфігурацыі, якія знаходзіць у адпаведных тэчках.

У самім файле налад сэрвісу парадак укажам пакуль толькі адзін параметр:

spring.application.name: order

Зараз запусцім убудову, і ён згенеруе нам патрэбную канфігурацыю нашага сэрвісу па паказаным ва ўласцівасцях шляху:

Можна абысціся і без усталёўкі плагіна, проста запампаваўшы дыстрыбутыў фреймворка і запусціўшы яго з каманднага радка.
Такое рашэнне падыдзе для выкарыстання на сэрвэры зборкі.

Варта адзначыць, што фрэймворк выдатна разумее ўласнасць сінтаксіс, гэта значыць звычайныя property файлы, якія можна выкарыстоўваць разам у ямл канфігурацыямі.

Дадамо яшчэ адзін сэрвіс аплата і ўскладнім адначасова існуючы.
В парадак:

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.

Фрэймворк аўтаматычна сам знойдзе канфігурацыю eureka і скапіюе яе ў канфігурацыйныя файлы сэрвісаў, пры гэтым асобная канфігурацыя eureka не будзе створана, бо мы не пакажам яе ў файле асяроддзя dev.yaml. Сэрвіс парадак:

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

Таксама мы можам вынесці наладкі базы дадзеных у асобную канфігурацыю, змяніўшы радок імпарту на #include eureka, oracle.

Варта адзначыць, што кожная змена пры перагенерацыі канфігурацыйных файлаў фрэймворк адсочвае і змяшчае ў адмысловы файл побач з асноўным файлам канфігурацыі. Запіс у яго логу выглядае так: “Stored 1 property changes to order/diff-application.yaml”. Гэта дазваляе хутка выявіць змены ў вялікіх канфігурацыйных файлах.

Вынас агульных частак канфігурацыі дазваляе пазбавіцца ад мноства непатрэбнага капіпаста, але не дазваляе гнутка ствараць канфігурацыю для розных асяроддзяў - эндпаінты нашых сэрвісаў адзіныя і захардкожены, гэта дрэнна. Паспрабуем гэта прыбраць.

Добрым рашэннем будзе трымаць усе эндпаінты ў нейкай адной канфігурацыі, на якую маглі б спасылацца астатнія. Для гэтага ў фрэймворк укаранёна падтрымка плэйсхолдэраў. Вось як зменіцца файл канфігурацыі эўрыка:

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

Цяпер паглядзім, як працуе гэты плейсхолдэр. Сістэма знаходзіць кампанент з імем канчатковыя кропкі і шукае ў ім значэнне eurekaip, пасля чаго падстаўляе ў нашу канфігурацыю. Але што рабіць з рознымі асяроддзямі? Для гэтага створым файл налад у канчатковыя кропкі наступнага выгляду application.dev.yaml. Фрэймворк самастойна, па пашырэнні файла прымае рашэнне да якога асяроддзя ставіцца дадзеная канфігурацыя і падгружае яе:

Змесціва dev файла:

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}

Дзякуючы гэтаму, не трэба дадаткова паказваць імя прыкладання ў канфігурацыі і яго можна таксама вынесці ў агульны модуль, напрыклад, у тую ж eureka:

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

Файл канфігурацыі парадак скароціцца да аднаго радка:

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

У выпадку, калі якая-небудзь настройка з бацькоўскай канфігурацыі нам не патрэбна, мы можам паказаць яе ў нашай канфігурацыі і менавіта яна будзе прыменена пры генерацыі. Гэта значыць калі па нейкім чынніку нам трэба ўнікальнае імя для сэрвісу order, проста пакінем параметр spring.application.name.

Дапушчальны, у сэрвіс неабходна дадаць кастамізаваныя налады лагавання, якія захоўваюцца ў асобным файле, напрыклад, logback.xml. Створым для яго асобную групу налад:

У базавай канфігурацыі пакажам фрэймворку куды размяшчаць патрэбны нам файл налад лагавання з дапамогай плейсхолдэра @ConfigDir:

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

У файле logback.xml наладжваем стандартныя апендэры, якія гэтак жа ў сваю чаргу могуць утрымоўваць плэйсхолдэры, якія фреймворк зменіць падчас генерацыі канфігаў, напрыклад:

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

Дадаючы ў канфігурацыі сэрвісаў імпарт logback, мы аўтаматычна атрымліваем настроенае лагіраванне для кожнага сэрвісу:

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

Надышоў час больш падрабязна азнаёміцца ​​са ўсімі даступнымі плейсхолдэрамі фрэймворка:

${this@env} - вяртае імя бягучага асяроддзя.
${…@name} - вяртае імя кампанента.
${…@configDir} - вяртае поўны шлях да каталога config кампанента.
${…@resultDir} - вяртае поўны шлях да каталога прызначэння кампанента (атрыманыя файлы будуць змешчаныя ў гэты каталог).
${this@configRoot} - вяртае поўны шлях да каранёвага каталога сховішчы канфігурацый.

Таксама сістэма дазваляе атрымаць зменныя асяроддзі, напрыклад шлях да java:
${env@JAVA_HOME}
Альбо, бо фрэймворк напісаны на JAVA, можам атрымаць сістэмныя зменныя аналагічныя выкліку System::getProperty з дапамогай канструкцыі такога віду:
${[электронная пошта абаронена]}
Варта згадаць пра падтрымку мовы пашырэнняў. Spring EL. У канфігурацыі дастасавальныя падобныя выразы:

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

Такім чынам, фрэймворк уяўляе з сябе даволі магутная прылада для тонкай і гнуткай налады канфігурацый мікрасэрвісаў. Фрэймворк выдатна выконвае сваю асноўную задачу - ухіленне капіпаста ў наладах, кансалідацыю налад і як следства звядзенне да мінімуму магчымых памылак, пры гэтым дазваляючы лёгка камбінаваць канфігурацыі і змяняць для розных асяроддзяў.

Калі вас зацікавіў дадзены фрэймворк, то рэкамендую наведаць яго афіцыйную старонку і азнаёміцца ​​з поўнай дакументацыяй, альбо пакапацца ў зыходніках тут.

Крыніца: habr.com