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

Еден од главните проблеми во развојот и последователното работење на микросервисите е компетентната и точна конфигурација на нивните примероци. Според мене, нова рамка може да помогне во ова microconfig.io. Ви овозможува доста елегантно да решавате некои рутински задачи за конфигурација на апликации.

Ако имате многу микроуслуги, а секоја од нив доаѓа со своја конфигурациска датотека/датотеки, тогаш постои голема веројатност да се направи грешка во една од нив, што може да биде многу тешко да се фати без соодветна вештина и систем за логирање. Главната задача што рамката ја поставува за себе е да ги минимизира параметрите за конфигурација на дупликат пример, со што се намалува веројатноста за додавање грешка.

Ајде да погледнеме на пример. Да речеме дека имаме едноставна апликација со конфигурациска датотека ѓамл. Ова може да биде било кој микросервис на кој било јазик. Ајде да видиме како рамката може да се примени на оваа услуга.

Но, прво, за поголема погодност, ајде да создадеме празен проект во Idea IDE, откако ќе го инсталираме приклучокот microconfig.io во него:

Ја поставивме конфигурацијата за стартување на приклучокот; можете да ја користите стандардната конфигурација, како на сликата од екранот погоре.

Нашата услуга се нарекува ред, тогаш во нов проект ќе создадеме слична структура:

Ставете ја конфигурациската датотека во папката со име на услугата - апликација.yaml. Сите микросервиси се лансирани во некаква средина, така што, покрај создавањето конфигурација за самата услуга, неопходно е да се опише и самата околина: за ова ќе создадеме папка завидно и додадете датотека во неа со името на нашата работна средина. Така, рамката ќе создаде конфигурациски датотеки за услугите во околината dev, бидејќи овој параметар е поставен во поставките на приклучокот.

Структура на датотека 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

Главниот проблем со овие конфигурации е присуството на голема количина на copy-paste во поставките на услугата. Ајде да видиме како рамката ќе помогне да се ослободиме од неа. Да почнеме со најочигледното - присуството на конфигурација еурека во описот на секоја микросервис. Ајде да создадеме нов директориум со датотеката за поставки и да додадеме нова конфигурација на него:

И сега да ја додадеме линијата на секој наш проект #вклучи еурека.

Рамката автоматски ќе ја пронајде конфигурацијата на еурека и ќе ја копира во датотеките за конфигурација на услугата, додека посебна конфигурација на еурека нема да се создаде, бидејќи нема да ја наведеме во датотеката на околината dev.yaml. Сервис цел:

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

Ние исто така можеме да ги преместиме поставките на базата на податоци во посебна конфигурација со менување на линијата за увоз во #вклучи еурека, пророштво.

Вреди да се напомене дека рамката ја следи секоја промена при регенерирање на конфигурациските датотеки и ја става во посебна датотека веднаш до главната конфигурациска датотека. Влезот во неговиот дневник изгледа вака: „Зачувано 1 својство се менува во order/diff-application.yaml" Ова ви овозможува брзо да откриете промени во големи конфигурациски датотеки.

Отстранувањето на заедничките делови од конфигурацијата ви овозможува да се ослободите од многу непотребни copy-paste, но не ви дозволува флексибилно да креирате конфигурација за различни средини - крајните точки на нашите услуги се единствени и тврдокодирани, ова е лошо. Ајде да се обидеме да го отстраниме ова.

Добро решение би било да се задржат сите крајни точки во една конфигурација на која другите можат да се повикуваат. За таа цел, во рамката е воведена поддршка за носители на места. Вака ќе се промени конфигурациската датотека еурека:

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

Сега да видиме како функционира ова место. Системот наоѓа компонента со име крајни точки и бара значење во него еурекаип, а потоа го заменува во нашата конфигурација. Но, што е со различните средини? За да го направите ова, креирајте датотека со поставки во крајни точки следниот тип апликација.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}

Благодарение на ова, нема потреба дополнително да го наведете името на апликацијата во конфигурацијата и исто така може да се стави во заеднички модул, на пример, во истата еурека:

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

Конфигурациската датотека цел ќе се намали на една линија:

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

Ако не ни треба поставка од матичната конфигурација, можеме да ја наведеме во нашата конфигурација и таа ќе се примени за време на генерирањето. Односно, ако поради некоја причина ни треба единствено име за услугата за нарачка, само ќе го оставиме параметарот пролет.примена.име.

Да речеме дека треба да додадете сопствени поставки за евиденција на услугата, кои се зачувани во посебна датотека, на пример, враќање назад.xml. Ајде да создадеме посебна група на поставки за тоа:

Во основната конфигурација, ќе ѝ кажеме на рамката каде да ја поставиме датотеката со поставки за евиденција што ни треба со помош на држач за место @ConfigDir:

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

Во датотека враќање назад.xml ние ги конфигурираме стандардните додатоци, кои за возврат исто така може да содржат поставки кои рамката ќе ги промени за време на генерирањето на конфигурации, на пример:

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

Со додавање на увоз во конфигурациите на услугата најава, ние автоматски добиваме конфигурирана евиденција за секоја услуга:

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

Време е подетално да се запознаете со сите расположливи поставки на рамката:

${this@env} - го враќа името на моменталната околина.
${…@name} — го враќа името на компонентата.
${…@configDir} — ја враќа целосната патека до директориумот за конфигурација на компонентата.
${…@resultDir} — ја враќа целосната патека до одредишниот директориум на компонентата (добиените датотеки ќе бидат ставени во овој директориум).
${this@configRoot} — ја враќа целосната патека до root директориумот на продавницата за конфигурации.

Системот исто така ви овозможува да добиете променливи на околината, на пример патеката до Java:
${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

Така, рамката е прилично моќна алатка за фино подесување и флексибилна конфигурација на микросервисите. Рамката совршено ја исполнува својата главна задача - елиминирање на copy-paste во поставките, консолидирање на поставките и, како резултат на тоа, минимизирање на можните грешки, додека ви овозможува лесно да ги комбинирате конфигурациите и да ги менувате за различни средини.

Ако сте заинтересирани за оваа рамка, препорачувам да ја посетите нејзината официјална страница и да се запознаете со целосната документација, или копаат во изворите тука.

Извор: www.habr.com