Gemakkelijke configuratiebeheer van microservices met microconfig.io

Een van de belangrijkste problemen bij de ontwikkeling en het latere onderhoud van microservices is de juiste en zorgvuldige configuratie van hun instanties. Dit kan, naar mijn mening, worden opgelost met behulp van een nieuw framework. microconfig.io. Het stelt ons in staat om enkele routinetaken van applicatieconfiguratie op een elegante manier op te lossen.

Als je veel microservices hebt, en elke service komt met zijn eigen configuratiebestand/-bestanden, is de kans groot dat je een fout maakt in een van hen. Deze fout kan zonder de juiste ervaring en een logsysteem moeilijk te traceren zijn. De belangrijkste taak die het framework zich stelt, is het minimaliseren van de duplicerende configuratieparameters van de instantie, waardoor de kans op fouten vermindert.

Laten we dit aan de hand van een voorbeeld bekijken. Stel, we hebben een eenvoudige applicatie met een configuratiebestand. yaml. Dit kan elke microservice in elke programmeertaal zijn. Laten we kijken hoe we het framework op deze service kunnen toepassen.

Maar eerst, voor het gemak, laten we een leeg project aanmaken in IDEA IDE, waarbij we eerst de microconfig.io-plugin installeren:

We configureren de plugin-opstartinstellingen; je kunt de standaardconfiguratie gebruiken, zoals op de bovenstaande schermafdruk.

Onze service heet order, dus in het nieuwe project creëren we een soortgelijke structuur:

In de map met de naam van de service plaatsen we het configuratiebestand — application.yaml. Alle microservices worden uitgevoerd in een bepaalde omgeving, dus naast het maken van de configuratie voor de service, moeten we ook de omgeving zelf beschrijven: daarvoor maken we een map aan. envs en voegen we daar een bestand toe met de naam van onze werkelijke omgeving. Op deze manier zal het framework configuratiebestanden voor de diensten in de omgeving creëren, aangezien deze parameter in de plugin-instellingen is ingesteld. , maar volgt geen wijzigingen), gebruikmakend van een andere configuratie.De structuur van het bestand

dev.yaml zal vrij eenvoudig zijn: mainorder: components: - order

Het framework werkt met configuraties die in groepen zijn samengevoegd. Voor onze service kiezen we een naam voor de groep.

mainorder . Het framework vindt elke dergelijke groep applicaties in het omgevingsbestand en genereert configuraties voor al deze applicaties, die het in de overeenkomstige mappen vindt.In het configuratiebestand van de service

order geven we voorlopig alleen één parameter aan: spring.application.name: order

Laten we nu de plugin starten, en deze zal de benodigde configuratie voor onze service genereren volgens het opgegeven pad in de eigenschappen:

Je kunt

het eenvoudig houden. afkomen en zonder een plugin te installeren, gewoon door het framework distributief bestand te downloaden en het vanuit de opdrachtregel te starten.
Dit type oplossing is geschikt voor gebruik op de buildserver.

Het is vermeldenswaard dat het framework uitstekend begrijpt property syntax, dat wil zeggen normale property-bestanden die samen gebruikt kunnen worden in yaml configuraties.

Laten we een andere service toevoegen payment en tegelijkertijd het bestaande ingewikkeld maken.
In geven we voorlopig alleen één parameter aan::

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

In 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

Het belangrijkste probleem van deze configuraties is de aanwezigheid van veel copy-paste in de service-instellingen. Laten we eens kijken hoe het framework helpt om hiervan af te komen. Laten we beginnen met de meest voor de hand liggende — de aanwezigheid van configuratie eureka in de beschrijving van elke microservice. Laten we een nieuwe map maken met een configuratiebestand en daar een nieuwe configuratie aan toevoegen:

En in elk van onze projecten voegen we nu de regel toe #include eureka.

Het framework vindt automatisch de eureka-configuratie en kopieert deze naar de configuratiebestanden van de services, terwijl er geen aparte eureka-configuratie zal worden gemaakt, omdat we deze niet in het omgevingsbestand zullen opgeven. zal vrij eenvoudig zijn:. De service geven we voorlopig alleen één parameter aan::

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

Daarnaast kunnen we de database-instellingen in een aparte configuratie plaatsen door de importregel te wijzigen in #include eureka, oracle.

Het moet worden opgemerkt dat het framework elke wijziging bij het regenereren van configuratiebestanden volgt en plaatst in een speciaal bestand naast het hoofdbestand van de configuratie. De notitie in zijn log ziet er als volgt uit: “Opslag 1 wijziging in eigenschap naar order/diff-application.yaml”. Dit maakt het gemakkelijk om wijzigingen in grote configuratiebestanden te detecteren.

Het verplaatsen van gemeenschappelijke configuratieonderdelen stelt ons in staat om veel onnodige copy-paste te vermijden, maar maakt het niet flexibel om configuraties voor verschillende omgevingen te creëren - de eindpunten van onze services zijn uniek en hard gecodeerd, wat slecht is. Laten we proberen dit te verwijderen.

Een goede oplossing zou zijn om alle eindpunten in één enkele configuratie te houden, waarnaar de anderen kunnen verwijzen. Hiervoor is er ondersteuning voor placeholders in het framework ingebouwd. Zo zal het configuratiebestand veranderen eureka:

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

Laten we nu kijken hoe deze placeholder werkt. Het systeem vindt de component met de naam endpoints en zoekt daarin de waarde eurekaip, waarna we deze in onze configuratie kunnen invoegen. Maar hoe gaan we om met verschillende omgevingen? Hiervoor creëren we een instellingenbestand in endpoints de volgende indeling application.dev.yaml. Het framework beslist zelf, op basis van de bestandsextensie, tot welke omgeving deze configuratie behoort en laadt deze:

Inhoud van het dev-bestand:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Een vergelijkbare configuratie kunnen we ook maken voor de poorten van onze diensten:

server.port: ${ports@order}.

Alle belangrijke instellingen bevinden zich op één plek, waardoor de kans op fouten door verspreide parameters over configuratiebestanden vermindert.

Het framework biedt veel vooraf gedefinieerde placeholders, bijvoorbeeld, we kunnen de naam van de directory waar het configuratiebestand zich bevindt verkrijgen en deze toewijzen:

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

Hierdoor hoeft de naam van de applicatie niet apart in de configuratie te worden vermeld en kan deze ook in een gemeenschappelijk module worden geplaatst, bijvoorbeeld in dezelfde eureka:

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

Configuratiebestand geven we voorlopig alleen één parameter aan: wordt ingekort tot één regel:

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

Als een instelling uit de bovenliggende configuratie niet nodig is, kunnen we deze in onze configuratie opgeven en zal deze worden toegepast tijdens de generatie. Dus als we om wat voor reden dan ook een unieke naam voor de service order nodig hebben, laten we gewoon de parameter spring.application.name.

Stel, we moeten gepersonaliseerde logginginstellingen toevoegen die in een apart bestand worden bewaard, bijvoorbeeld, logback.xml. Laten we hiervoor een aparte groep instellingen maken:

In de basisconfiguratie geven we het framework aan waar het het benodigde logginginstellingenbestand moet plaatsen met behulp van de placeholder @ConfigDir:

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

In het bestand logback.xml we configureren de standaard appenders, die ook placeholders kunnen bevatten die het framework tijdens de generatie van configuraties zal aanpassen, bijvoorbeeld:

logs/${this@name}.log

Door in de configuraties van diensten import logback, krijgen we automatisch geconfigureerde logging voor elke dienst:

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

Het is tijd om meer gedetailleerd kennis te maken met alle beschikbare placeholders van het framework:

${this@env} — retourneert de naam van de huidige omgeving.
${…@name} — retourneert de naam van de component.
${…@configDir} — retourneert het volledige pad naar de config directory van de component.
${…@resultDir} — retourneert het volledige pad naar de doeldirectory van de component (de verkregen bestanden worden in deze directory geplaatst).
${this@configRoot} — retourneert het volledige pad naar de hoofdmap van de configuratieopslag.

Daarnaast stelt het systeem je in staat om omgevingsvariabelen te verkrijgen, zoals het pad naar java:
${env@JAVA_HOME}
Of, omdat het framework is geschreven in JAVA, kunnen we systeemvariabelen verkrijgen, vergelijkbaar met de oproep System::getProperty met behulp van een constructie van dit type:
${system@os.name}
Het is vermeldenswaard dat er ondersteuning is voor de extensietaal Spring EL. In de configuratie zijn dergelijke uitdrukkingen toepasbaar:

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

en lokale variabelen kunnen in configuratiebestanden worden gebruikt met behulp van de uitdrukking #var:

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

Dus, het framework is een behoorlijk krachtig hulpmiddel voor de fijne en flexibele configuratie van microservices. Het framework vervult perfect zijn belangrijkste taak — het elimineren van copy-paste in instellingen, het consolideren van instellingen en daardoor het tot een minimum beperken van mogelijke fouten, terwijl het eenvoudig mogelijk is om configuraties te combineren en voor verschillende omgevingen te wijzigen.

Als je geïnteresseerd bent in dit framework, raad ik aan om de officiële pagina te bezoeken en de volledige de documentatie, of om in de bronbestanden te duiken here.

Bron: habr.com