Gérez facilement les configurations de microservices avec microconfig.io

L'un des principaux problèmes liés au développement et au fonctionnement ultérieur des microservices est la configuration compétente et précise de leurs instances. À mon avis, un nouveau cadre peut aider à cela microconfig.io. Il vous permet de résoudre certaines tâches de configuration d'application de routine avec beaucoup d'élégance.

Si vous disposez de nombreux microservices et que chacun d'entre eux est livré avec son(ses) propre(s) fichier(s) de configuration, il existe une forte probabilité de commettre une erreur dans l'un d'entre eux, ce qui peut être très difficile à détecter sans les compétences appropriées et un système de journalisation. La tâche principale que le framework se fixe est de minimiser les paramètres de configuration d'instance en double, réduisant ainsi la probabilité d'ajouter une erreur.

Regardons un exemple. Disons que nous avons une application simple avec un fichier de configuration yaml. Il peut s'agir de n'importe quel microservice dans n'importe quelle langue. Voyons comment le framework peut être appliqué à ce service.

Mais d’abord, pour plus de commodité, créons un projet vide dans Idea IDE, après y avoir installé le plugin microconfig.io :

Nous mettons en place la configuration de lancement du plugin, vous pouvez utiliser la configuration par défaut, comme dans la capture d'écran ci-dessus.

Notre service s'appelle commande, puis dans un nouveau projet nous créerons une structure similaire :

Placez le fichier de configuration dans le dossier portant le nom du service - application.yaml. Tous les microservices sont lancés dans une sorte d'environnement, donc, en plus de créer une configuration pour le service lui-même, il est nécessaire de décrire l'environnement lui-même : pour cela, nous allons créer un dossier environnements et ajoutez-y un fichier avec le nom de notre environnement de travail. Ainsi, le framework créera des fichiers de configuration pour les services de l'environnement dev, puisque ce paramètre est défini dans les paramètres du plugin.

Structure du fichier dev.yaml ce sera assez simple :

mainorder:
    components:
         - order

Le framework fonctionne avec des configurations regroupées. Pour notre service, choisissez un nom pour le groupe commande principale. Le framework trouve chacun de ces groupes d'applications dans le fichier d'environnement et crée des configurations pour chacun d'entre eux, qu'il trouve dans les dossiers correspondants.

Dans le fichier des paramètres du service lui-même de commander Spécifions un seul paramètre pour l'instant :

spring.application.name: order

Lançons maintenant le plugin, et il générera la configuration requise pour notre service selon le chemin spécifié dans les propriétés :

On peut s'entendre et sans installer de plugin, il suffit de télécharger la distribution du framework et de l'exécuter depuis la ligne de commande.
Cette solution peut être utilisée sur un serveur de build.

Il est à noter que le framework comprend parfaitement propriété syntaxe, c'est-à-dire des fichiers de propriétés ordinaires qui peuvent être utilisés ensemble dans yaml configurations.

Ajoutons un autre service Paiement et compliquer celui qui existe déjà.
В de commander:

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

В Paiement:

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

Le principal problème de ces configurations est la présence d'une grande quantité de copier-coller dans les paramètres du service. Voyons comment le framework aidera à s'en débarrasser. Commençons par le plus évident : la présence de configuration eureka dans la description de chaque microservice. Créons un nouveau répertoire avec le fichier de paramètres et ajoutons-y une nouvelle configuration :

Et maintenant ajoutons la ligne à chacun de nos projets #inclure eurêka.

Le framework trouvera automatiquement la configuration eureka et la copiera dans les fichiers de configuration du service, tandis qu'une configuration eureka distincte ne sera pas créée, puisque nous ne la spécifierons pas dans le fichier d'environnement. dev.yaml. Service de commander:

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

Nous pouvons également déplacer les paramètres de la base de données dans une configuration distincte en modifiant la ligne d'importation en #inclure eurêka, oracle.

Il convient de noter que le framework suit chaque modification lors de la régénération des fichiers de configuration et la place dans un fichier spécial à côté du fichier de configuration principal. L'entrée dans son journal ressemble à ceci : « 1 propriété stockée change en commande/diff-application.yaml" Cela vous permet de détecter rapidement les modifications apportées aux fichiers de configuration volumineux.

La suppression des parties communes de la configuration vous permet de vous débarrasser de nombreux copier-coller inutiles, mais ne vous permet pas de créer de manière flexible une configuration pour différents environnements - les points de terminaison de nos services sont uniques et codés en dur, c'est mauvais. Essayons de supprimer cela.

Une bonne solution serait de conserver tous les points de terminaison dans une configuration à laquelle d’autres peuvent faire référence. À cette fin, la prise en charge des espaces réservés a été introduite dans le cadre. Voici comment le fichier de configuration va changer eureka:

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

Voyons maintenant comment fonctionne cet espace réservé. Le système trouve un composant nommé critères et y cherche un sens eurekaip, puis le remplace dans notre configuration. Mais qu’en est-il des différents environnements ? Pour ce faire, créez un fichier de paramètres dans critères le type suivant application.dev.yaml. Le framework décide indépendamment, en fonction de l'extension du fichier, à quel environnement appartient cette configuration et la charge :

Contenu du fichier de développement :

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Nous pouvons créer la même configuration pour les ports de nos services :

server.port: ${ports@order}.

Tous les paramètres importants sont regroupés au même endroit, réduisant ainsi le risque d'erreurs dues à des paramètres dispersés dans les fichiers de configuration.

Le framework fournit de nombreux espaces réservés prêts à l'emploi, par exemple, vous pouvez obtenir le nom du répertoire dans lequel se trouve le fichier de configuration et l'attribuer :

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

Grâce à cela, il n'est pas nécessaire de spécifier en plus le nom de l'application dans la configuration et elle peut également être placée dans un module commun, par exemple dans le même eureka :

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

Le fichier de configuration de commander sera réduit à une seule ligne :

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

Si nous n'avons besoin d'aucun paramètre de la configuration parent, nous pouvons le spécifier dans notre configuration et il sera appliqué lors de la génération. Autrement dit, si pour une raison quelconque nous avons besoin d'un nom unique pour le service de commande, nous laisserons simplement le paramètre spring.application.name.

Supposons que vous deviez ajouter des paramètres de journalisation personnalisés au service, qui sont stockés dans un fichier séparé, par exemple : connexion.xml. Créons un groupe distinct de paramètres pour cela :

Dans la configuration de base, nous indiquerons au framework où placer le fichier de paramètres de journalisation dont nous avons besoin à l'aide d'un espace réservé. @RépConfig:

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

En fichier connexion.xml nous configurons des appenders standards, qui à leur tour peuvent également contenir des espaces réservés que le framework modifiera lors de la génération des configurations, par exemple :

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

En ajoutant l'importation aux configurations de service se connecter, nous obtenons automatiquement la journalisation configurée pour chaque service :

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

Il est temps de se familiariser plus en détail avec tous les espaces réservés disponibles du framework :

${this@env} - renvoie le nom de l'environnement actuel.
${…@nom} — renvoie le nom du composant.
${…@configDir} - renvoie le chemin complet vers le répertoire de configuration du composant.
${…@resultDir} — renvoie le chemin complet vers le répertoire de destination du composant (les fichiers résultants seront placés dans ce répertoire).
${this@configRoot} — renvoie le chemin complet vers le répertoire racine du magasin de configuration.

Le système permet également d'obtenir des variables d'environnement, par exemple le chemin vers java :
${env@JAVA_HOME}
Soit, puisque le framework est écrit en JAVA, nous pouvons obtenir des variables système similaires à l'appel Système ::getProperty en utilisant une structure comme celle-ci :
${[email protected]}
Il convient de mentionner la prise en charge du langage d'extension EL ressort. Les expressions suivantes sont applicables dans la configuration :

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

et vous pouvez utiliser des variables locales dans les fichiers de configuration en utilisant l'expression #var:

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

Ainsi, le framework est un outil assez puissant pour un réglage fin et une configuration flexible des microservices. Le framework remplit parfaitement sa tâche principale : éliminer le copier-coller dans les paramètres, consolider les paramètres et, par conséquent, minimiser les erreurs possibles, tout en vous permettant de combiner facilement les configurations et de les modifier pour différents environnements.

Si vous êtes intéressé par ce framework, je vous recommande de visiter sa page officielle et de vous familiariser avec l'intégralité Documentation, ou fouillez dans les sources ici.

Source: habr.com