Gestionați cu ușurință configurațiile de microservicii cu microconfig.io

Una dintre principalele probleme în dezvoltarea și funcționarea ulterioară a microserviciilor este configurarea competentă și precisă a instanțelor acestora. În opinia mea, un nou cadru poate ajuta în acest sens microconfig.io. Vă permite să rezolvați unele sarcini de rutină de configurare a aplicațiilor destul de elegant.

Dacă aveți multe microservicii, iar fiecare dintre ele vine cu propriul fișier/fișiere de configurare, atunci există o probabilitate mare de a face o eroare într-unul dintre ele, care poate fi foarte greu de prins fără abilitățile adecvate și un sistem de logare. Sarcina principală pe care și-o stabilește cadrul este de a minimiza parametrii de configurare a instanțelor duplicate, reducând astfel probabilitatea de a adăuga o eroare.

Să ne uităm la un exemplu. Să presupunem că avem o aplicație simplă cu un fișier de configurare yaml. Acesta poate fi orice microserviciu în orice limbă. Să vedem cum poate fi aplicat cadrul acestui serviciu.

Dar mai întâi, pentru o mai mare comoditate, să creăm un proiect gol în Idea IDE, după ce instalăm pluginul microconfig.io în el:

Am configurat configurația de lansare a pluginului, puteți utiliza configurația implicită, ca în captura de ecran de mai sus.

Serviciul nostru se numește comandă, apoi într-un nou proiect vom crea o structură similară:

Puneți fișierul de configurare în folderul cu numele serviciului - aplicare.yaml. Toate microserviciile sunt lansate într-un fel de mediu, așa că, pe lângă crearea unei configurații pentru serviciul în sine, este necesar să descriem mediul în sine: pentru aceasta vom crea un folder envs și adăugați un fișier cu numele mediului nostru de lucru. Astfel, cadrul va crea fișiere de configurare pentru serviciile din mediu dev, deoarece acest parametru este setat în setările pluginului.

Structura fișierului dev.yaml va fi destul de simplu:

mainorder:
    components:
         - order

Cadrul funcționează cu configurații care sunt grupate împreună. Pentru serviciul nostru, alegeți un nume pentru grup comandă principală. Cadrul găsește fiecare astfel de grup de aplicații în fișierul de mediu și creează configurații pentru toate, pe care le găsește în folderele corespunzătoare.

În fișierul de setări ale serviciului în sine comandă Să specificăm un singur parametru pentru moment:

spring.application.name: order

Acum să rulăm pluginul și acesta va genera configurația necesară pentru serviciul nostru, conform căii specificate în proprietăți:

putea se înțelege și fără a instala un plugin, pur și simplu descărcați distribuția cadrului și rulați-l din linia de comandă.
Această soluție este potrivită pentru utilizare pe un server de compilare.

Este demn de remarcat faptul că cadrul înțelege perfect proprietate sintaxă, adică fișiere de proprietăți obișnuite care pot fi utilizate împreună în yaml configuratii.

Să adăugăm un alt serviciu plată și complică pe cea existentă.
В comandă:

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

В plată:

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

Principala problemă cu aceste configurații este prezența unei cantități mari de copy-paste în setările serviciului. Să vedem cum va ajuta cadrul de a scăpa de el. Să începem cu cel mai evident - prezența configurației evrica în descrierea fiecărui microserviciu. Să creăm un nou director cu fișierul de setări și să adăugăm o nouă configurație la acesta:

Și acum să adăugăm linia fiecăruia dintre proiectele noastre #include eureka.

Cadrul va găsi automat configurația eureka și o va copia în fișierele de configurare a serviciului, în timp ce o configurație eureka separată nu va fi creată, deoarece nu o vom specifica în fișierul de mediu. dev.yaml. Serviciu comandă:

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

De asemenea, putem muta setările bazei de date într-o configurație separată prin schimbarea liniei de import în #include eureka, oracol.

Este de remarcat faptul că cadrul urmărește fiecare modificare atunci când regenerează fișierele de configurare și o plasează într-un fișier special lângă fișierul de configurare principal. Intrarea din jurnalul său arată astfel: „Stored 1 property changes to comanda/diff-application.yaml" Acest lucru vă permite să detectați rapid modificările la fișierele mari de configurare.

Eliminarea părților comune ale configurației vă permite să scăpați de o mulțime de copy-paste inutile, dar nu vă permite să creați în mod flexibil o configurație pentru diferite medii - punctele finale ale serviciilor noastre sunt unice și codificate, acest lucru este rău. Să încercăm să eliminăm asta.

O soluție bună ar fi păstrarea tuturor punctelor finale într-o singură configurație la care alții pot face referire. În acest scop, suportul pentru substituenți a fost introdus în cadru. Așa se va schimba fișierul de configurare evrica:

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

Acum să vedem cum funcționează acest substituent. Sistemul găsește o componentă numită Obiective și caută în ea sens eurekaip, și apoi îl înlocuiește în configurația noastră. Dar cum rămâne cu mediile diferite? Pentru a face acest lucru, creați un fișier de setări în Obiective următorul tip application.dev.yaml. Cadrul independent, pe baza extensiei de fișier, decide cărui mediu îi aparține această configurație și o încarcă:

Conținutul fișierului Dev:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Putem crea aceeași configurație pentru porturile serviciilor noastre:

server.port: ${ports@order}.

Toate setările importante sunt într-un singur loc, reducând astfel probabilitatea erorilor din cauza parametrilor împrăștiați în fișierele de configurare.

Cadrul oferă mulți substituenți gata pregătiți, de exemplu, puteți obține numele directorului în care se află fișierul de configurare și îl puteți atribui:

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

Datorită acestui fapt, nu este nevoie să specificați suplimentar numele aplicației în configurație și poate fi, de asemenea, plasat într-un modul comun, de exemplu, în același eureka:

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

Fișierul de configurare comandă se va reduce la o singură linie:

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

Dacă nu avem nevoie de nicio setare din configurația părinte, o putem specifica în configurația noastră și va fi aplicată în timpul generării. Adică, dacă dintr-un motiv oarecare avem nevoie de un nume unic pentru serviciul de comandă, vom lăsa doar parametrul primavara.aplicatie.nume.

Să presupunem că trebuie să adăugați setări personalizate de înregistrare la serviciu, care sunt stocate într-un fișier separat, de exemplu, logback.xml. Să creăm un grup separat de setări pentru acesta:

În configurația de bază, vom spune cadrului unde să plasăm fișierul de setări de înregistrare de care avem nevoie folosind un substituent @ConfigDir:

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

În dosar logback.xml configurăm anexe standard, care la rândul lor pot conține și substituenți pe care cadrul se va schimba în timpul generării configurațiilor, de exemplu:

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

Adăugând import la configurațiile serviciului logback, primim automat înregistrarea configurată pentru fiecare serviciu:

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

Este timpul să vă familiarizați mai în detaliu cu toți substituenții disponibili ai cadrului:

${this@env} - returnează numele mediului curent.
${…@name} — returnează numele componentei.
${…@configDir} — returnează calea completă către directorul de configurare al componentei.
${…@resultDir} — returnează calea completă către directorul de destinație al componentei (fișierele rezultate vor fi plasate în acest director).
${this@configRoot} — returnează calea completă către directorul rădăcină al depozitului de configurare.

De asemenea, sistemul vă permite să obțineți variabile de mediu, de exemplu calea către java:
${env@JAVA_HOME}
Ori, din moment ce cadrul este scris în JAVA, putem obține variabile de sistem similare cu apelul System::getProperty folosind o structură ca aceasta:
${[e-mail protejat]}
Merită menționat suportul pentru limbajul extensiei Spring EL. Următoarele expresii sunt aplicabile în configurație:

connection.timeoutInMs: #{5 * 60 * 1000}
datasource.maximum-pool-size: #{${[email protected]} + 10} 

și puteți utiliza variabile locale în fișierele de configurare folosind expresia #var:

#var feedRoot: ${[email protected]}/feed
folder:
 root: ${this@feedRoot}
 success: ${this@feedRoot}/archive
 error: ${this@feedRoot}/error

Astfel, cadrul este un instrument destul de puternic pentru reglarea fină și configurarea flexibilă a microserviciilor. Cadrul își îndeplinește perfect sarcina principală - eliminarea copy-paste în setări, consolidarea setărilor și, ca urmare, minimizarea posibilelor erori, permițându-vă în același timp să combinați cu ușurință configurațiile și să le schimbați pentru diferite medii.

Dacă sunteți interesat de acest cadru, vă recomand să vizitați pagina sa oficială și să vă familiarizați cu întregul documentație, sau săpați în surse aici.

Sursa: www.habr.com