Comment gérer la configuration des microservices

Configurer un système logiciel dans une approche monolithique ne pose pas de problèmes particuliers. Pour rendre les propriétés de configuration disponibles pour le système, nous pouvons les stocker dans un fichier à l’intérieur d’un dossier d’application, à un endroit quelconque du système de fichiers ou en tant que variables d’environnement du système d’exploitation. La configuration des microservices est un sujet plus complexe. Nous avons affaire à un nombre, qui peut être énorme, de services totalement indépendants, chacun avec sa propre configuration. Nous pourrions même faire face à un scénario dans lequel plusieurs instances du même service nécessitent des valeurs de configuration différentes.

Dans une telle situation, un moyen de centraliser et de simplifier la gestion de la configuration serait d’une grande importance. Spring Cloud a son propre module pour résoudre ces problèmes, nommé Spring Cloud Config. Ce module fournit une implémentation d’un serveur qui expose un API pour récupérer les informations de configuration, généralement stockées dans un référentiel distant comme Git, et, en même temps, cela nous donne les moyens d’implémenter le côté client destiné à consommer les services de ce API.

Dans la première partie de cet article, nous aborderons les fonctionnalités de base de ce module Spring Cloud et le stockage de la configuration dans le serveur de configuration chemin de classe. Dans la deuxième partie, nous montrerons comment utiliser d’autres options de référentiel plus efficaces, comme Git, et comment actualiser la configuration sans redémarrer les services. Ensuite, dans des articles ultérieurs, nous montrerons comment la configuration centralisée peut être couplée à des fonctionnalités de découverte de services pour établir une base solide pour l’ensemble du système de microservices.

Configuration du microservice—Spring Cloud Config côté serveur

Le premier composant dont nous avons besoin dans un scénario de configuration distribuée est un serveur destiné à fournir les informations de configuration pour les services. Pour implémenter un tel composant serveur par Spring Cloud Config, nous devons utiliser la bonne dépendance « starter » Spring Boot, comme dans le fragment de configuration suivant :

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-config-server</artifactId>
        </dependency>

Ensuite, nous devons annoter la classe principale Spring Boot avec le @EnableConfigServer annotation:

@SpringBootApplication
@EnableConfigServer
public class AppMain {

	public static void main(String[] args) {
		new SpringApplicationBuilder(Config.class).run(args);
	}
}

Le serveur Spring Cloud Config, selon les fonctionnalités de configuration automatique de Spring Boot, fonctionnerait sur le port 8080 par défaut comme toutes les applications Spring Boot. Si nous voulons le personnaliser, nous pouvons le faire par le application.properties or application.yml dossier:

server:  
  port: ${PORT:8888}
    
spring:
  application:
    name: config-server

Si nous exécutons l’application avec la configuration ci-dessus, elle utilisera le port 8888 par défaut. Nous pouvons remplacer la valeur par défaut en lançant l’application avec un port différent, par le PORT espace réservé :

java -jar -DPORT=8889 sample-server-1.0-SNAPSHOT.jar

Dans tous les cas, si nous lançons l’application avec le spring.config.name=configserver argument à la place, le port par défaut sera 8888. Cela est dû à un configserver.yml fichier par défaut intégré dans le spring-cloud-config-server une bibliothèque. En effet, il serait très pratique de lancer l’application de configuration du serveur sur le port 8888, soit en la configurant explicitement par le server.port paramètre, comme dans l’exemple ci-dessus, ou en passant spring.config.name=configserver dans la commande Java de démarrage car 8888 se trouve être le port par défaut utilisé par le côté client.

Note importante: Les spring.config.name=configserver L’option ne fonctionne que si elle est passée dans la commande de démarrage et semble être ignorée, pour une raison quelconque, si elle est définie dans le fichier de configuration. Nous pouvons voir ci-dessous un exemple de démarrage du serveur de configuration avec une commande Java :

java -jar -Dspring.config.name=configserver spring-cloud-config-native-server-1.0-SNAPSHOT.jar

Par défaut, le serveur Spring Cloud Config utilise Git comme référentiel distant pour stocker les données de configuration. Pour simplifier la discussion, nous nous concentrerons sur une approche plus basique basée sur des fichiers stockés sur le classpath de l’application. Nous décrirons cette option dans la section suivante. Il faut souligner que, dans un scénario réel, ce serait loin d’être idéal, et Git serait sûrement un meilleur choix.

Application de l’authentification de base côté serveur

Nous pouvons fournir au serveur une couche de sécurité de base sous la forme d’un mécanisme d’authentification basé sur l’utilisateur et le mot de passe. Pour ce faire, nous devons d’abord ajouter la sécurité suivante entrée à la POM:

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-security</artifactId>
        </dependency>

Et puis ajoutez le morceau de configuration suivant dans le application.yml dossier:

  security:
    user:
      name: myusername
      password: mypassword

Avec ce qui précède, le côté client doit être configuré en conséquence pour pouvoir se connecter au serveur, comme nous le verrons dans la section relative à la côté client. Nous aborderons des mécanismes de sécurisation plus avancés dans des articles ultérieurs.

Options de stockage du backend Spring Cloud Config

Le serveur Spring Cloud Config peut stocker les données de configuration de plusieurs manières :

Par un système Git distant, qui est la valeur par défaut.
Autres systèmes de contrôle de version (VCS) comme SVN.
VAULT : est un outil de Hashi Corp spécialisé dans le stockage de mots de passe, de certificats ou d’autres entités comme secrets.
En le stockant quelque part dans le système de fichiers ou le classpath.

Ci-dessous, nous décrirons l’option filesystem/classpath. Spring Cloud Config a un profil nommé originaire de qui couvre ce scénario. Afin d’exécuter le serveur de configuration avec un stockage backend de système de fichiers/classpath, nous devons le démarrer avec le spring.profiles.active=native option.

Dans le originaire de scénario, le serveur de configuration recherchera par défaut aux endroits suivants :

classpath:/
classpath:/config
file:./
file:./ config

Ainsi, nous pouvons simplement stocker les fichiers de configuration à l’intérieur de l’application pot dossier. Si nous voulons utiliser un répertoire de système de fichiers externe à la place ou personnaliser ce qui précède chemin de classe options, nous pouvons définir les spring.cloud.config.server.native.searchLocations propriété en conséquence.

API du serveur de configuration

Le serveur de configuration peut exposer les propriétés de configuration d’une application spécifique par une API HTTP avec les points de terminaison suivants :

/{ application}/{ profile}[/{ label}]: cela renvoie les données de configuration au format JSON avec l’application spécifique, le profil et un facultatif étiquette paramètre.
/{ label}/{ application}-{ profile}.yml: cela renvoie les données de configuration au format YAML, avec l’application spécifique, le profil et une option étiquette paramètre.
/{ label}/{ application}-{ profile}.properties: cela renvoie les données de configuration sous forme de texte brut, avec l’application spécifique, le profil et une option étiquette paramètre.

La partie application représente le nom de l’application configurée par le spring.application.name propriété et la partie de profil représente le profil actif. UN profil est une fonctionnalité permettant de séparer un ensemble de configurations liées à des environnements spécifiques, tels que développement, testet production. Les étiquette La partie est facultative et est utilisée lors de l’utilisation de Git en tant que référentiel principal pour identifier un bifurquer.

Configuration du microservice—Spring Cloud Config côté client

Si nous voulons que nos services obtiennent leur propre configuration du serveur, nous devons leur fournir une dépendance nommée spring-cloud-starter-config:

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-config</artifactId>
        </dependency>

En clair, la configuration doit être obtenue dans un premier temps lors de son démarrage. Pour faire face à cette exigence, Spring Cloud introduit une contexte d’amorçage. Les contexte d’amorçage peut être considéré comme le parent du contexte d’application. Il sert à charger les données de configuration récupérées à partir d’une source externe et à les mettre à la disposition du contexte d’application.

Dans les versions antérieures de Spring Cloud, nous pouvions fournir les propriétés de configuration pour le contexte d’amorçage par un bootstrap.yml dossier. Ceci est obsolète dans les nouvelles versions. Maintenant, nous devons simplement fournir un config.import property=optional:configserver: propriété dans la norme application.yml:

  config:
    import: "optional:configserver:"

Avec le optional:configserver valeur, le service client de configuration utilisera la valeur par défaut http://localhost:8888 adresse pour contacter le serveur de configuration. Si nous excluons les optionnel partie, une erreur sera déclenchée au démarrage si le serveur est inaccessible.

Si nous voulons définir une adresse et un port spécifiques, nous pouvons ajouter la partie adresse à la valeur comme ceci :

  config:
    import: "optional:configserver:http://myhost:myport"

Configuration de la sécurité côté client

Si nous avons sécurisé le serveur avec une authentification de base, nous devons fournir la configuration nécessaire au client. Ajout de l’élément de configuration suivant au application.yml sera suffisant:

  security:
    user:
      name: myusername
      password: mypassword

Rassembler les pièces dans une démo simple

En utilisant les notions décrites ci-dessus, nous pouvons réaliser une démo simple avec un serveur de configuration et un seul service client, comme le montre l’image ci-dessous :

Implémentation côté serveur

Pour implémenter le côté serveur, nous créons une application Spring Boot avec le train de versions Spring Cloud requis et le démarreur Spring Cloud Config :