Gestion facile des configurations de microservices avec microconfig.io

L'un des principaux problèmes lors du développement et de l'exploitation ultérieure des microservices est la configuration correcte et soignée de leurs instances. À mon avis, un nouveau framework peut aider à ce sujet. microconfig.io. Il permet de résoudre de manière assez élégante certaines tâches routinières de configuration des applications.

Si vous avez beaucoup de microservices, et que chacun d'eux est livré avec son fichier(s) de configuration, il est très probable qu'une erreur soit commise dans l'un d'eux, une erreur qui peut être difficile à détecter sans une certaine expérience et un système de journalisation. La principale tâche que se fixe le framework est de minimiser les paramètres de configuration d'instance en double, réduisant ainsi le risque d'erreurs.

Prenons un exemple. Supposons qu'il existe une application simple avec un fichier de configuration yaml. Cela peut être n'importe quel microservice dans n'importe quel langage. Voyons comment le framework peut être appliqué à ce service.

Mais avant tout, pour plus de commodité, créons un projet vide dans l'IDE Idea, après avoir installé le plugin microconfig.io :

Configurons la configuration de lancement du plugin, on peut utiliser la configuration par défaut, comme sur la capture d'écran ci-dessus.

Notre service s'appelle order, alors dans le nouveau projet, créons une structure similaire :

Dans le dossier avec le nom du service, plaçons le fichier de configuration — application.yaml. Tous les microservices s'exécutent dans un certain environnement, donc, en plus de créer la configuration du service lui-même, il est nécessaire de décrire l'environnement lui-même : pour cela, créons un dossier envs et ajoutons-y un fichier avec le nom de notre environnement de travail. Ainsi, le framework créera des fichiers de configuration pour les services dans l'environnement dev, car dans les paramètres du plugin, ce paramètre est exactement celui qui est défini.

Structure du fichier dev.yaml sera assez simple :

mainorder:
    components:
         - order

Le framework fonctionne avec des configurations qui sont regroupées. Pour notre service, choisissons un nom pour le groupe mainorder. Le framework trouve chaque groupe d'applications dans le fichier d'environnement et crée des configurations pour toutes celles-ci, qu'il trouve dans les dossiers respectifs.

Dans le fichier de configuration du service order nous allons pour l'instant indiquer seulement un paramètre :

spring.application.name: order

Maintenant, lançons le plugin, et il nous générera la configuration requise de notre service selon le chemin spécifié dans les propriétés :

On peut s'en passer et sans installation de plugin, simplement en téléchargeant la distribution du framework et en l'exécutant à partir de la ligne de commande.
Cette solution est adaptée à une utilisation sur un serveur de compilation.

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

Ajoutons un autre service payment et compliquons simultanément l'existant.
Dans 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

Dans 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

Le principal problème de ces configurations est la présence d'un grand nombre de copiés-collés dans les paramètres des services. Voyons comment le framework peut aider à s'en débarrasser. Commençons par le plus évident — la présence de la configuration eureka dans la description de chaque microservice. Créons un nouveau répertoire avec un fichier de paramètres et ajoutons-y une nouvelle configuration :

Et dans chacun de nos projets, ajoutons maintenant la ligne #include eureka.

Le framework trouvera automatiquement la configuration eureka et la copiera dans les fichiers de configuration des services, sans créer de configuration eureka distincte, car nous ne l'indiquerons pas dans le fichier d'environnement dev.yaml. Service order:

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

Nous pouvons également extraire les paramètres de la base de données dans une configuration distincte, en modifiant la ligne d'importation en #include eureka, oracle.

Il convient de noter que chaque changement lors de la régénération des fichiers de configuration est suivi par le framework et enregistré dans un fichier spécial à côté du fichier de configuration principal. L'entrée dans son journal ressemble à ceci : « Stocké 1 changement de propriété à order/diff-application.yaml». Cela permet de rapidement détecter les changements dans de grands fichiers de configuration.

L'extraction des parties communes de la configuration permet de se débarrasser de nombreux copiés-collés inutiles, mais ne permet pas de créer de manière flexible des configurations pour différents environnements — les points de terminaison de nos services sont uniques et hardcodés, ce qui est problématique. Essayons de l'éliminer.

Une bonne solution serait de conserver tous les points de terminaison dans une seule configuration, à laquelle les autres pourraient faire référence. Pour cela, le framework intègre la prise en charge des espaces réservés. Voici comment le fichier de configuration eureka:

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

Maintenant, voyons comment fonctionne cet espace réservé. Le système trouve le composant nommé endpoints et y cherche la valeur eurekaip, puis il l'intègre dans notre configuration. Mais qu'en est-il des différents environnements ? Pour cela, créons un fichier de configuration dans endpoints le format suivant application.dev.yaml. Le framework, en fonction de l'extension du fichier, détermine à quel environnement cette configuration appartient et la charge :

Le contenu du fichier dev :

eurekaip: 192.89.89.111
dbip: 192.168.0.100

Nous pouvons également créer une configuration similaire pour les ports de nos services :

server.port: ${ports@order}.

Tous les paramètres importants se trouvent à un seul endroit, réduisant ainsi le risque d'erreur dû à des paramètres dispersés dans plusieurs fichiers de configuration.

Le framework fournit de nombreux placeholders déjà prêts, par exemple, il est possible d'obtenir le nom du répertoire dans lequel se trouve le fichier de configuration et de l'assigner :

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

Grâce à cela, il n'est plus nécessaire de spécifier le nom de l'application dans la configuration, et il peut également être déplacé 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 order sera réduit à une seule ligne :

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

Dans le cas où un paramètre de la configuration parent ne serait pas nécessaire, nous pouvons l'indiquer dans notre configuration et c'est celui-ci qui sera appliqué lors de la génération. Cela signifie que si pour une raison quelconque nous avons besoin d'un nom unique pour le service order, il suffit de laisser le paramètre spring.application.name.

Supposons qu'un service doive ajouter des paramètres de journalisation personnalisés, qui sont stockés dans un fichier séparé, par exemple, logback.xml. Créons un groupe de paramètres distinct pour cela :

Dans la configuration de base, nous indiquerons au framework où placer le fichier de paramètres de journalisation requis à l'aide du placeholder @ConfigDir:

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

Dans le fichier logback.xml nous configurons les appenders standards, qui peuvent également contenir des placeholders que le framework modifiera lors de la génération des configs, par exemple :

logs/${this@name}.log

En ajoutant dans la configuration des services l'import logback, nous obtenons automatiquement une 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 placeholders disponibles du framework :

${this@env} — renvoie le nom de l'environnement actuel.
${…@name} — 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 obtenus seront placés dans ce répertoire).
${this@configRoot} — renvoie le chemin complet vers le répertoire racine du stockage des configurations.

De plus, le système permet d'obtenir des variables d'environnement, par exemple le chemin vers java :
${env@JAVA_HOME}
Ou, puisque le framework est écrit en JAVA, nous pouvons obtenir des variables système similaires à l'appel System::getProperty avec une construction de ce type :
${system@os.name}
Il convient de mentionner le support du langage d'expression Spring EL. Dans la configuration, des expressions similaires peuvent être appliquées :

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

et il est possible d'utiliser des variables locales dans les fichiers de configuration à l'aide de l'expression #var:

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

Ainsi, le framework constitue un outil puissant pour un réglage fin et flexible des configurations des microservices. Le framework remplit parfaitement sa mission principale : éliminer le copier-coller dans les réglages, consolider les paramètres et, par conséquent, minimiser les erreurs potentielles, tout en permettant de combiner facilement les configurations et de les modifier pour différents environnements.

Si ce framework vous intéresse, je vous recommande de visiter sa page officielle et de consulter l'intégralité de la documentation, ou d'explorer le code source ici.

Source : habr.com