Лесно управление на конфигурациите на микросервизите с помощта на 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 , синтаксиса, т.е. обикновените файлове с свойства, които могат да се използват заедно с 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.

Трябва да се отбележи, че всяка промяна при генериране на конфигурационните файлове, фреймворкът проследява и записва в специален файл до основния конфигурационен файл. Записът в неговия лог изглежда така: “Stored 1 property changes to 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