Könnyű mikroszolgáltatások konfigurációinak kezelése a microconfig.io segítségével

A mikroszolgáltatások fejlesztésének és további üzemeltetésének egyik fő problémája a megfelelő és precíz beállításuk. Ezen a téren véleményem szerint segíthet egy új keretrendszer microconfig.io. Ez viszonylag elegánsan old meg néhány rutinszerű alkalmazáskonfigurációs feladatot.

Ha sok mikroszolgáltatása van, és mindegyik saját konfigurációs fájljával rendelkezik, akkor nagy a valószínűsége, hogy hibázik az egyikben, amelyet megfelelő tapasztalat és naplózási rendszer nélkül nagyon nehéz lehet nyomon követni. A keretrendszer fő célja a konfigurációs paraméterek duplikálásának minimalizálása, így csökkentve a hiba hozzáadásának valószínűségét.

Vizsgáljuk meg egy példa segítségével. Tegyük fel, hogy van egy egyszerű alkalmazás egy konfigurációs fájllal yaml. Ez lehet bármilyen mikroszolgáltatás bármilyen nyelven. Nézzük meg, hogyan alkalmazhatjuk a keretrendszert erre a szolgáltatásra.

De először, a kényelem kedvéért, hozzunk létre egy üres projektet az Idea IDE-ben, miután telepítettük a microconfig.io plugint:

Állítsuk be a plugin indítási konfigurációját, használhatjuk az alapértelmezett beállítást, ahogyan a fenti képernyőképen látható.

A szolgáltatásunk neve order, így új projektben létrehozunk egy hasonló struktúrát:

A szolgáltatás nevével ellátott mappába helyezzük a konfigurációs fájlt — application.yaml. Minden mikroszolgáltatás valamilyen környezetben fut, így a szolgáltatás konfigurációjának létrehozása mellett le kell írni a környezetet is: ehhez létrehozunk egy mappát envs és hozzáadunk egy fájlt a munkakörnyezetünk nevével. Így a keretrendszer létrehozza a konfigurációs fájlokat a szolgáltatások számára a környezetben dev, mivel a plugin beállításaiban pontosan ez a paraméter van megadva.

A fájl struktúrája dev.yaml meglehetősen egyszerű lesz:

mainorder:
    components:
         - order

A keretrendszer olyan konfigurációkkal dolgozik, amelyek csoportosítva vannak. Szolgáltatásunk számára válasszunk egy nevet a csoporthoz mainorder. A keretrendszer megtalálja az ilyen alkalmazáscsoportokat a környezeti fájlban, és létrehozza számukra a konfigurációkat, amelyeket a megfelelő mappákban talál.

A szolgáltatás konfigurációs fájljában order ideiglenesen csak egy paramétert adunk meg:

spring.application.name: order

Most már futtatjuk a plugint, és az generál nekünk egy szükséges konfigurációt a szolgáltatásunkhoz a megadott útvonal szerint:

Lehet úgy is megoldani, hogy nem telepítjük a plugint, csak letöltjük a keretrendszer disztribúcióját és parancssorból indítjuk el.
Ez a megoldás építési szerveren való használatra alkalmas.

Érdemes megjegyezni, hogy a keretrendszer remekül érti property szintaxist, vagyis a szokásos property fájlokat, amelyeket együtt lehet használni yaml a konfigurációkkal.

Hozzáadunk még egy szolgáltatást payment és egyszerre bonyolítjuk az meglévőt.
A 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

A 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

Ezeknek a konfigurációknak a fő problémája a szolgáltatások beállításaiban lévő rengeteg másolás-beillesztés. Nézzük meg, hogyan segít a keretrendszer megszabadulni tőle. Kezdjük a legnyilvánvalóbbal — a konfiguráció meglétét eureka minden mikroszolgáltatás leírásában. Hozzunk létre egy új könyvtárat beállítási fájllal, és adjuk hozzá az új konfigurációt:

És most minden projektünkhöz hozzáadjuk a sort #include eureka.

A keretrendszer automatikusan megtalálja az eureka konfigurációt, és átmásolja azt a szolgáltatások konfigurációs fájljaiba, miközben külön eureka konfiguráció nem jön létre, mivel nem jelöljük meg a környezeti fájlban. dev.yaml. A szolgáltatás order:

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

Emellett a database beállításait külön konfigurációba is kiemelhetjük, megváltoztatva az import sorát #include eureka, oracle.

Érdemes megjegyezni, hogy minden módosítást a keretrendszer nyomon követ, amikor a konfigurációs fájlokat újragenerálja, és külön fájlba helyezi a fő konfigurációs fájl mellett. A logbejegyzés így néz ki: "Tárolva 1 property változás a order/diff-application.yaml”. Ez lehetővé teszi az egyszerű észlelést a nagy konfigurációs fájlokban bekövetkezett változásokhoz.

A közös konfigurációs részek kiemelése lehetővé teszi a rengeteg felesleges másolás-beillesztés eltávolítását, de nem engedi meg, hogy rugalmasan hozzunk létre konfigurációt különböző környezetekhez — a szolgáltatásaink végpontjai egyediek és hardkódoltak, ez rossz. Próbáljuk meg ezt eltüntetni.

Jó megoldás lenne, ha minden végpontot egyetlen konfigurációban tartanánk, amelyre a többi hivatkozhatna. Erre a keretrendszerbe beépítették a helyettesítők támogatását. Így fog kinézni a konfigurációs fájl eureka:

 ügyfél:
   szolgáltatásUrl:
     alapértelmezettZóna: http://${endpoints@eurekaip}:6782/eureka/

Most nézzük meg, hogyan működik ez a helyettesítő. A rendszer megkeresi a nevű komponenst végpontok és megkeresi benne az értéket eurekaip, majd behelyettesíti a konfigurációnkba. De mi a helyzet a különböző környezetekkel? Erre létrehozunk egy beállítási fájlt a végpontok következő formátumban application.dev.yaml. A keretrendszer automatikusan, a fájl kiterjesztése alapján meghatározza, hogy melyik környezethez tartozik ez a konfiguráció, és betölti azt:

A dev fájl tartalma:

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Ugyanezt a konfigurációt létrehozhatjuk a szolgáltatásaink portjaihoz is:

server.port: ${ports@order}.

Minden fontos beállítás egy helyen található, ezzel csökkentve a hibák valószínűségét a konfigurációs fájlok szétszórt paraméterei miatt.

A keretrendszer számos kész helyettesítőt biztosít, például megkaphatjuk a konfigurációs fájl mappájának nevét és hozzárendelhetjük:

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

Ennek köszönhetően nincs szükség külön megadni az alkalmazás nevét a konfigurációban, ezt is ki lehet vinni egy közös modulba, például a következőbe: eureka:

ügyfél:
   szolgáltatásUrl:
     alapértelmezettZóna: http://${endpoints@eurekaip}:6782/eureka/
 spring.application.name: ${this@name}

A konfigurációs fájl order egy sorra csökken:

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

Ha a szülő konfiguráció közül bármely beállításra nincs szükségünk, azt megadhatjuk a saját konfigurációnkban, és pontosan az fog érvényesülni generáláskor. Tehát, ha valamilyen okból egyedi nevet kell adni a rendelés szolgáltatásnak, hagyjuk meg a paramétert spring.application.name.

Tegyük fel, hogy a szolgáltatáshoz testreszabott naplózási beállításokat kell hozzáadni, amelyek külön fájlban találhatók, például logback.xml. Hozzuk létre számára egy külön beállítási csoportot:

Az alap konfigurációban adjuk meg a keretrendszernek, hová helyezze el a szükséges naplózási beállítási fájlt a helyettesítő segítségével @ConfigDir:

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

A fájlban logback.xml beállítjuk a standard apendereket, amelyek szintén tartalmazhatnak helyettesítőket, amelyeket a keretrendszer a konfigurációk generálása során megváltoztat, például:

logs/${this@name}.log

A szolgáltatások konfigurációjában a logback importálásával logback, automatikusan beállított naplózást kapunk minden szolgáltatásra:

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

Itt az idő, hogy részletesebben megismerkedjünk a keretrendszer összes elérhető helyettesítőjével:

${this@env} — visszaadja a jelenlegi környezet nevét.
${…@name} — visszaadja az összetevő nevét.
${…@configDir} — visszaadja az összetevő konfigurációs könyvtárának teljes elérési útját.
${…@resultDir} — visszaadja az összetevő célkönyvtárának teljes elérési útját (a kapott fájlok ebbe a könyvtárba kerülnek).
${this@configRoot} — visszaadja a konfigurációs tároló gyökérkönyvtárának teljes elérési útját.

A rendszer lehetővé teszi környezeti változók, például a java elérési útvonalának megszerzését:
${env@JAVA_HOME}
Vagy mivel a keretrendszer egy JAVAnyelvben íródott, a rendszer változóit a System::getProperty hívásához hasonlóan kaphatjuk meg az alábbi szintaxis használatával:
${system@os.name}
Érdemes megemlíteni a kiterjesztési nyelv támogatását, Spring EL. A konfigurációban alkalmazható hasonló kifejezések:

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

és a helyi változók használatához a konfigurációs fájlokban kifejezések útján, #var:

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

Így a keretrendszer egy meglehetősen erőteljes eszközzé válik a mikroszolgáltatások konfigurációinak finomhangolására és rugalmassá tételére. A keretrendszer jól végzi az alapvető feladatát – eliminálja a beállítások duplikálását, konszolidálja a beállításokat és ezzel minimalizálja a lehetséges hibák előfordulását, miközben lehetővé teszi a konfigurációk egyszerű kombinálását és a különböző környezetekhez való módosítást.

Ha érdeklik ezek a keretrendszerek, ajánlom, hogy látogasson el a hivatalos oldalára, és ismerkedjen meg a teljes Microsoft dokumentációjával összhangban konfiguráljuk. Az egyetlen megjegyzés az, hogy az Ubuntu disztribúciót már letöltöttük, és a következő lépésben fogjuk telepíteni. A fő konfigurálás az "Windows alrendszer Linuxhoz" és a "Virtuális gép platform" kiegészítő komponenseinek aktiválására, valamint a beállítások alkalmazásához szükséges újraindításra korlátozódik:, vagy mélyedjen el a forráskódban. itt.

Forrás: habr.com