Лесно управление на конфигурациите на микросервизи с помощта на microconfig.io

Една от основните проблеми при разработването и последващата експлоатация на микросервизи е правилното и прецизно настройване на техните инстанции. На това, според мен, може да помогне новият фреймворк microconfig.io. Той позволява доста елегантно да се решат някои рутинни задачи за настройка на приложения.

Ако имате много микросервизи и всеки от тях идва със свой собствен файл/файлове за настройки, вероятността да допуснете грешка в някой от тях е голяма, и без необходимите умения и система за логване може да е много трудно да я хванете. Основната задача, която фреймворкът си поставя, е да минимизира дублиращите параметри на настройките на инстанцията, така намалявайки вероятността от добавяне на грешки.

Нека да разгледаме примера. Да предположим, че имаме просто приложение с конфигурационен файл yaml. Това може да бъде всеки микросервис на всеки език. Нека видим как фреймворкът може да се приложи към този сервис.

Но преди това, за по-голямо удобство, ще създадем празен проект в Idea IDE, след като предварително инсталираме плъгина microconfig.io:

Настройваме конфигурацията за стартиране на плъгина, можете да използвате конфигурацията по подразбиране, както е на екрана по-горе.

Нашият сервис се нарича order, така че в новия проект ще създадем подобна структура:

В папката с името на сървиса поставяме конфигурационния файл — application.yaml. Всички микросервизи се стартират в някаква среда, така че освен създаването на конфиг файла на самия сервис, трябва да опишем и самата среда: за това ще създадем папка envs и ще добавим в нея файл с името на нашата работна среда. По този начин фреймворкът ще създаде конфигурационни файлове за сервисите в средата dev, тъй като в настройките на плъгина е зададен именно този параметър.

Структурата на файла dev.yaml ще бъде доста простичка:

mainorder:
    components:
         - order

Фреймворкът работи с конфигурации, които са обединени в групи. За нашия сервис ще изберем име за групата mainorder. Фреймворкът намира всяка такава група приложения в файла за среди и създава конфигурации за всички тях, които намира в съответните папки.

В самия файл за настройки на сервиса order ще зададем засега само един параметър:

spring.application.name: order

Сега стартирайте плъгина, и той ще генерира необходимата конфигурация на нашия сервис по указаната в свойствата пътека:

Може да се справим и без инсталиране на плъгин, просто изтегляйки дистрибуцията на фреймворка и стартирайки я от командния ред.
Това решение е подходящо за ползване на сървър за изграждане.

Следва да се отбележи, че фреймворкът отлично разбира property синтаксиса, тоест обикновените property файлове, които могат да се използват заедно с yaml конфигурациите.

Нека добавим още една услуга payment и едновременно да усложним съществуващата.
В 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

В payment:

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

Основният проблем на тези конфигурации е наличието на голямо количество копипаста в настройките на услугите. Нека видим как фреймворъкът ще помогне да се отървем от него. Да започнем с най-очевидното — наличието на конфигурация eureka в описанието на всеки микросервис. Да създадем нова директория с файл за настройки и да добавим новата конфигурация в нея:

А в всеки от нашите проекти сега да добавим реда #include eureka.

Фреймворкът автоматично сам ще намери конфигурацията eureka и ще я копира в конфигурационните файлове на услугите, като същевременно отделната конфигурация eureka няма да бъде създадена, тъй като няма да я посочим във файла на средата dev.yaml. Услуга order:

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

Също така можем да изнесем настройките на базата данни в отделна конфигурация, като променим реда за импортиране на #include eureka, oracle.

Следва да се отбележи, че всяка промяна при регенерация на конфигурационните файлове се проследява от фреймворка и се записва в специален файл до основния конфигурационен файл. Записът в лог файла му изглежда така: “Запазени 1 промени на свойства в order/diff-application.yaml”. Това позволява бързо откриване на промени в големи конфигурационни файлове.

Изнасянето на общите части от конфигурацията позволява да се избавим от много ненужен копипаста, но не позволява гъвкаво създаване на конфигурация за различни среди — ендпоинтите на нашите услуги са единствени и хардкоднати, което е проблем. Нека опитаме да го премахнем.

Добро решение би било да се държат всички ендпоинти в някаква една конфигурация, на която да могат да се позоват останалите. За това в фреймворка е внедрена поддръжка за плейсхолдъри. Ето как ще изглежда файла за конфигурация eureka:

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

Сега да видим как работи този плейсхолдър. Системата намира компонента с името endpoints и търси в него стойността eurekaip, след което го вмъкваме в нашата конфигурация. Но как да се справим с различните среди? Затова ще създадем файл с настройки в endpoints следния вид 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}

Файлът с конфигурация order ще се съкрати до един ред:

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

Ако някоя настройка от родителската конфигурация не е необходима, можем да я посочим в нашата конфигурация и именно тя ще бъде приложена при генерирането. Тоест, ако по някаква причина ни е нужно уникално име за услугата order, просто ще оставим параметъра spring.application.name.

Да кажем, че в услугата е необходимо да добавим персонализирани настройки за логване, които се съхраняват в отделен файл, например, logback.xml. Създаваме за него отделна група с настройки:

В основната конфигурация посочваме на фреймуърка къде да постави нужния ни файл с настройки за логване с помощта на плейсхолдера @ConfigDir:

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

В файла logback.xml настройваме стандартните аппендери, които също могат да съдържат плейсхолдърите, които фреймуъркът ще промени по време на генерирането на конфигурации, например:

logs/${this@name}.log

Като добавим в конфигурациите на услугите импорт logback, автоматично получаваме настроено логване за всяка услуга:

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

Време е да се запознаем по-подробно със всички налични плейсхолдери на фреймуърка:

${this@env} — връща името на текущата среда.
${…@name} — връща името на компонента.
${…@configDir} — връща пълния път до каталога config на компонента.
${…@resultDir} — връща пълния път към директорията на компонента (получените файлове ще бъдат поставени в тази директория).
${this@configRoot} — връща пълния път към коренната директория на хранилището за конфигурации.

Системата също така позволява получаване на променливи на средата, например пътя към java:
${env@JAVA_HOME}
Или, тъй като фреймворкът е написан на JAVA, можем да получим системни променливи подобно на извикването на System::getProperty чрез конструкция от този вид:
${system@os.name}
Струва си да се спомене поддръжката на езика за разширения Spring EL. В конфигурацията се прилагат подобни изрази:

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

и можете да използвате локални променливи в конфигурационните файлове с помощта на израз: #var:

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

По този начин фреймворкът представлява доста мощен инструмент за фина и гъвкава настройка на конфигурациите на микросервисите. Фреймворкът успешно изпълнява основната си задача — премахване на повторенията в настройките, консолидиране на настройките и, в резултат, минимизиране на възможните грешки, като в същото време позволява лесно комбиниране на конфигурации и промяна за различни среди.

Ако сте заинтересовани от този фреймворк, препоръчвам да посетите официалната му страница и да се запознаете с пълната документацията, или да разгледате изходния код тук.

Източник: habr.com