Let nemmere at administrere mikroservices konfigurationer med microconfig.io

En af de største udfordringer ved udvikling og efterfølgende drift af mikrotjenester er en korrekt og omhyggelig opsætning af deres instanser. Dette, mener jeg, kan hjælpe med et nyt framework microconfig.io. Det giver en ganske elegant løsning på nogle rutineopgaver i opsætningen af applikationer.

Hvis du har mange mikrotjenester, og hver af dem leveres med sin egen konfigurationsfil/-filer, er der en stor risiko for at lave en fejl i én af dem, som uden den rette snilde og logningssystem kan være meget vanskeligt at opdage. Den primære opgave, som frameworket har, er at minimere de duplikerende opsætningsparametre for instanser, hvilket dermed reducerer sandsynligheden for at tilføje en fejl.

Lad os se på et eksempel. Antag, at der er en simpel applikation med en konfigurationsfil yaml. Dette kan være enhver mikrotjeneste skrevet i ethvert sprog. Lad os se, hvordan frameworket kan anvendes på denne tjeneste.

Men først, for større bekvemmelighed, skaber vi et tomt projekt i Idea IDE, efter først at have installeret microconfig.io-plugin.

Vi konfigurerer plugin'ets opstartskonfiguration; du kan bruge standardkonfigurationen som på skærmbilledet ovenfor.

Vores tjeneste hedder order, så i det nye projekt opretter vi en lignende struktur:

I mappen med tjenestens navn placerer vi konfigurationsfilen — application.yaml. Alle mikrotjenester kører i et eller andet miljø, så udover at oprette konfigen for selve tjenesten, skal vi beskrive selve miljøet: til dette opretter vi en mappe envs og tilføjer en fil med navnet på vores arbejds miljø. Dermed vil frameworket skabe konfigurationsfiler for tjenesterne i miljøet dev, da denne parameter er indstillet i plugin'ets indstillinger.

Strukturen af filen dev.yaml vil være ret simpel:

mainorder:
    components:
         - order

Frameworket arbejder med konfigurationer, der er samlet i grupper. For vores tjeneste vælger vi et navn til gruppen mainorder. Frameworket finder hver sådan gruppe af applikationer i miljøfilen og genererer konfigurationer for alle af dem, som det finder i de tilsvarende mapper.

I selve tjenestens indstillingsfil order vil vi indtil videre angive kun ét parameter:

spring.application.name: order

Nu starter vi plugin'et, og det vil generere den nødvendige konfiguration for vores tjeneste i henhold til den angivne sti i egenskaberne:

Du kan klare dig uden og uden at installere en plugin, blot ved at downloade distributionspakken af rammeværket og starte det fra kommandolinjen.
Denne løsning er velegnet til brug på en build-server.

Det skal bemærkes, at rammeværket forstår property syntaks, altså almindelige property-filer, som kan bruges sammen med yaml konfigurationer.

Lad os tilføje endnu en tjeneste payment og samtidig komplicere den eksisterende.
I 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

I 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

Det største problem med disse konfigurationer er mængden af copy-paste i tjenesteindstillingerne. Lad os se, hvordan rammeværket kan hjælpe med at klare dette. Vi starter med den mest indlysende — eksistensen af konfigurationen eureka i beskrivelsen af hver mikrotjeneste. Vi opretter et nyt katalog med en konfigurationsfil og tilføjer den nye konfiguration til det:

Og i hver af vores projekter tilføjer vi nu linjen #include eureka.

Rammeværket finder automatisk konfigurationen eureka og kopierer den til tjenesternes konfigurationsfiler, samtidig med at en separat eureka-konfiguration ikke vil blive oprettet, da vi ikke angiver den i miljøfilen. dev.yaml. Tjeneste order:

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

Vi kan også flytte databaseindstillinger til en separat konfiguration ved at ændre importlinjen til #include eureka, oracle.

Det skal bemærkes, at rammeværket registrerer hver ændring ved regenerering af konfigurationsfilerne og placerer dem i en særlig fil ved siden af den primære konfigurationsfil. Posten i dens log ser således ud: “Lagreret 1 property-ændringer til order/diff-application.yaml”. Dette muliggør hurtig opsporing af ændringer i store konfigurationsfiler.

At udtrække fælles dele af konfigurationen reducerer mængden af unødvendig copy-paste, men tillader ikke fleksibel oprettelse af konfiguration til forskellige miljøer — slutpunkterne for vores tjenester er unikke og hardcodede, hvilket er en ulempe. Lad os prøve at fjerne dette.

En god løsning vil være at holde alle slutpunkter i en enkelt konfiguration, som de andre kan referere til. Til dette er der indbygget støtte for pladsholdere i rammeværket. Her er, hvordan konfigurationsfilen vil ændre sig eureka:

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

Lad os nu se, hvordan denne pladsholder fungerer. Systemet finder komponenten med navnet endpoints og søger i den efter værdien eurekaip, hvorefter det indsættes i vores konfiguration. Men hvordan håndterer vi forskellige miljøer? For dette skaber vi en konfigurationsfil i endpoints følgende format application.dev.yaml. Rammeværket tager selvstændigt beslutning om, til hvilket miljø denne konfiguration hører, baseret på filens udvidelse og indlæser den:

Indholdet af dev-filen:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Vi kan oprette en lignende konfiguration for vores tjenesters porte:

server.port: ${ports@order}.

Alle vigtige indstillinger er samlet ét sted, hvilket reducerer risikoen for fejl på grund af spredte parametre i konfigurationsfilerne.

Rammeværket tilbyder mange færdige pladsholdere; for eksempel kan man få navnet på den mappe, hvor konfigurationsfilen ligger, og tildele det:

#include eureka, oracle
server.port: ${ports@order}
spring.application.name: ${this@name}

Takket være dette er det ikke nødvendigt at angive applikationens navn i konfigurationen, og det kan også flyttes til et fælles modul, som i.e. eureka:

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

Konfigurationsfilen order forkortes til én linje:

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

Hvis en indstilling fra den overordnede konfiguration ikke er nødvendig, kan vi angive den i vores konfiguration, og netop denne vil blive anvendt ved generation. Det vil sige, hvis vi af en eller anden grund har brug for et unikt navn til tjenesten order, lader vi blot parameteren være spring.application.name.

Lad os antage, at der skal tilføjes tilpassede logningsindstillinger til tjenesten, som gemmes i en separat fil, for eksempel logback.xml. Vi opretter en særskilt gruppe af indstillinger til den:

I den grundlæggende konfiguration angiver vi til rammeværket, hvor vi skal placere den nødvendige konfigurationsfil til logning ved hjælp af pladsholderen @ConfigDir:

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

I filen logback.xml vi konfigurerer standard appendere, der også kan indeholde pladsholdere, som rammeværket ændrer under genereringen af konfigurerede filer, for eksempel:

logs/${this@name}.log

Ved at tilføje import af logback til konfigurationerne for tjenesterne logback, får vi automatisk konfigureret logning for hver tjeneste:

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

Det er tid til at få et nærmere indblik i alle de tilgængelige pladsholdere i rammeværket:

${this@env} — returnerer navnet på det aktuelle miljø.
${…@name} — returnerer navnet på komponenten.
${…@configDir} — returnerer den fulde sti til konfigurationskataloget for komponenten.
${…@resultDir} — returnerer den fulde sti til destinationskatalogen for komponenten (de modtagne filer vil blive placeret i dette katalog).
${this@configRoot} — returnerer den fulde sti til rodkatalogen for konfigurationslageret.

Systemet giver også mulighed for at hente miljøvariabler, for eksempel stien til java:
${env@JAVA_HOME}
Eller, da rammeværket er skrevet i JAVA, kan vi hente systemvariabler svarende til kaldet System::getProperty ved hjælp af en konstruktion af denne type:
${system@os.name}
Det er værd at nævne understøttelsen af udvidelsessprog Spring EL. I konfigurationen kan lignende udtryk anvendes:

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

og man kan bruge lokale variabler i konfigurationsfiler med hjælp fra udtrykket. #var:

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

Dermed er rammeværket en ret kraftfuld værktøj til finjustering og fleksibel tilpasning af konfigurationerne for mikrotjenester. Rammeværket udfører perfekt sin hovedopgave — at fjerne kopiering af indstillinger, konsolidere indstillinger og dermed minimere de mulige fejl, samtidig med at det gør det nemt at kombinere konfigurationer og ændre dem til forskellige miljøer.

Hvis du er interesseret i dette rammeværk, anbefaler jeg at besøge dets officielle side og læse den fulde dokumentation, eller undersøge kildekoden. her.

Kilde: habr.com