introduction
L’un des principes de l’application 12 Facteur stipule que nous devons séparer la configuration de notre application du code. La configuration varie en fonction de l’environnement et il est préférable de les organiser en fonction de l’environnement dans lequel votre application s’exécute.
Dans cet article, nous verrons donc comment externaliser les configurations avec Spring Cloud Config.
Configuration du nuage de printemps
La configuration du cloud Spring se compose de deux parties :
- Un serveur pour fournir la configuration.
- Un client pour récupérer la configuration.
Voyons comment nous pouvons configurer le serveur de configuration Spring Cloud pour fournir une configuration à n’importe quelle application.
Serveur de configuration Spring Cloud
Allons sur https://start.spring.io et créons un projet avec les dépendances suivantes.
- Serveur de configuration Spring Cloud
Une fois le projet ouvert, vous devez configurer l’application pour lui permettre de servir la configuration. Maintenant, le serveur peut être configuré avec plusieurs backends avec lesquels vous pouvez organiser la configuration de n’importe quel client.
Voici une liste de certains des backends pris en charge.
- Aller à l’URL
- Compartiment AWS S3
- Redis
- Emplacement du système de fichiers
- Coffre HashiCorp
- CredHub de Cloudfoundary
Ce sont quelques-uns des plus populaires que j’ai répertoriés, mais quelques autres backends peuvent également être intégrés que vous pouvez trouver ici. Aujourd’hui, nous allons explorer comment configurer le serveur Spring Cloud Config avec l’URL Git comme backend.
Configurer Spring Cloud Config avec Git
Pour configurer cela, nous allons sauter au fichier de propriétés.
Commençons par la configuration la plus basique.
server:
port: 8888
spring:
cloud:
config:
server:
git:
uri: https://github.com/amrutprabhu/spring-boot-external-configuration-options
Il s’agit de la configuration la plus minimaliste requise pour utiliser un référentiel git comme magasin pour nos configurations client. Maintenant, créons quelques fichiers de configuration, dans le dépôt git.
Ici, nous devons organiser les noms des fichiers de propriétés de l’application dans le format {client.application.name}-{profile}.yaml (or .properties) . Pour cet exemple, nous définirons uniquement le server.port property dans les fichiers de propriétés, afin que le serveur démarre sur un port différent selon le profil.
Tout au long de cet exemple, nous considérerons un client dont le nom d’application est « config-client ».
Avec ceci Commençons l’application.
Nous pouvons tester le serveur pour vérifier la configuration qu’il récupère pour différents profils. Pour vérifier cela, nous pouvons accéder au serveur avec le format d’URL suivant :
http://localhost:8888/{client.application.name}/{profile}
e.g http://localhost:8888/config-client/dev
En cliquant sur l’URL ci-dessus, nous obtenons le résultat suivant :
Comme vous pouvez le voir, il récupère la configuration par défaut ainsi que la configuration de développement ici. Cela signifie que lorsque le client démarre avec le profil dev , il utilisera les propriétés du fichier dev YAML, en remplaçant les propriétés du fichier par défaut comme si les fichiers devaient être disponibles localement pour le client. Par conséquent, nous obtenons à la fois le fichier de propriétés par défaut ainsi que le fichier de propriétés spécifique au développeur.
Personnalisation de l’emplacement de configuration avec différents référentiels
Maintenant, que se passe-t-il si vous souhaitez organiser les fichiers de propriétés dans différents emplacements de référentiel ? Par exemple, nous voulons avoir un référentiel différent pour chaque environnement. Pour ce faire, nous allons étendre les propriétés comme suit :
server:
port: 8888
spring:
cloud:
config:
server:
git:
uri: https://github.com/amrutprabhu/spring-boot-external-configuration-options
repos:
staging-properties-repo:
pattern : config-client/staging
uri: https://github.com/amrutprabhu/spring-boot-external-configuration-options
search-paths:
- spring-cloud-config-server-setup/configs-location
Maintenant, ici, j’ai spécifié un nom de dépôt staging-properties-repo avec un URI de dépôt, un chemin de recherche et un modèle. Pour cet exemple, j’utilise le même référentiel git, mais vous pouvez utiliser un référentiel git complètement différent de celui que vous souhaitez.
Maintenant, ici nous pouvons spécifier un motif qui est du format suivant : {client's application name}/{client's application profile} . Comme il s’agit d’un modèle, vous pouvez utiliser des modèles de caractères génériques. par exemple
config-client*/* config-client/dev-* config-*/dev*
Ensuite, le search-paths La propriété vous aide à définir les emplacements sous lesquels la configuration peut être recherchée. Depuis que j’ai déplacé les propriétés sous deux sous-dossiers, j’ai mentionné l’emplacement du sous-dossier dans le search-paths.
Lors du redémarrage de l’application et de l’accès à l’URL, nous obtenons la sortie suivante pour le profil de transfert.
Personnalisation des modèles de recherche
Nous pouvons personnaliser la configuration en utilisant des espaces réservés réservés, notamment :
- {application} — pour faire référence au nom de l’application du client.
- {profile} — pour faire référence au profil d’application du client.
Utilisons ces espaces réservés pour ajouter d’autres repos.
prod-properies-repo:
uri: https://github.com/amrutprabhu/spring-boot-external-configuration-options
pattern: config-client/prod
search-paths:
- spring-cloud-config-server-setup/configs-location/{profile}
any-request-repo:
uri: https://github.com/amrutprabhu/spring-boot-external-configuration-options
pattern: config-client*/*
search-paths:
- spring-cloud-config-server-setup/configs-location/{application}/{profile}
Maintenant, ici, le premier dépôt a le nom du profil comme sous-répertoire à rechercher lorsque la demande arrive pour leprod profil.
Dans le second, si une autre demande arrive, elle utilisera le nom de l’application cliente et l’arborescence du sous-répertoire du profil. Voici comment les dossiers sont organisés :
Maintenant, avec les nouveaux dépôts ajoutés, redémarrons l’application et testons la sortie.
Ce ne sont là que quelques façons d’organiser votre configuration.
Maintenant, vous devez vous demander :
Que se passe-t-il si la configuration est modifiée sur git lorsque le serveur de configuration est en cours d’exécution ?
Dans ce cas, le serveur de configuration extraira automatiquement la nouvelle configuration et la transmettra au client demandeur lors des demandes suivantes. Pas besoin de redémarrer le serveur de configuration.
Que se passe-t-il s’il existe un modèle correspondant mais qu’aucune propriété pour ce profil particulier n’est trouvée ?
Dans ce cas, il essaierait de trouver les propriétés du référentiel par défaut, c’est-à-dire de la propriété spring.cloud.config.server.git.uri . S’il n’y a pas de propriétés disponibles dans le référentiel par défaut, il renverra des sources de propriété JSON vides.
Avec cela, nous sommes prêts avec notre serveur de configuration cloud de printemps.
Créons un client pour cela.
Création du client Spring Cloud Config.
Pour cela, nous allons créer une application en utilisant https://start.spring.io avec les dépendances suivantes.
- Configuration de démarrage Spring Cloud
- Spring Boot Web Starter (requis uniquement pour le serveur Tomcat)
Maintenant, ajoutons quelques propriétés au application.yaml déposer.
spring:
application:
name: config-client
config:
import: "configserver:"
Maintenant, depuis la version Spring Cloud 2020.0, nous devons spécifier d’où nous voulons que les configurations soient chargées. Puisque nous utilisons un serveur de configuration, nous devons spécifier la propriété spring.config.import="configserver:"
L’emplacement à partir duquel les configurations seront récupérées est ajouté aubootstrap.yaml déposer.
spring:
cloud:
config:
uri: http://localhost:8888
Avec cela, construisons l’application et exécutons-la à l’aide de la commande suivante avec un argument de profil :
java -jar target/config-client-service-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod
Le client démarre avec le port 9090, qui est ce qui a été défini dans le fichier de propriétés du profil prod.
Au démarrage du service client avec le profil de transfert, il démarre au port 6060
Conseil utile
Maintenant, pour tester votre configuration à partir du serveur de configuration, il peut devenir fastidieux de modifier la configuration, de transmettre les modifications à git, puis de tester la sortie.
Vous pouvez rendre cela facile en remplaçant l’URL git par un emplacement de répertoire local où le dépôt de configuration est extrait. Par exemple:
prod-properies-repo:
uri: file:///home/user/spring-boot-external-configuration-options
pattern: config-client/prod
search-paths:
- spring-cloud-config-server-setup/configs-location/{profile}
Vous pouvez ensuite modifier les fichiers localement et tester votre serveur de configuration.
Conclusion
Nous venons de voir comment configurer un serveur de configuration Spring Cloud avec un backend de référentiel git et l’utiliser pour démarrer une application cliente. Il y a eu quelques changements depuis la version Spring Cloud 2020.0 et cet exemple illustre l’intégration.
Comme d’habitude, j’ai téléchargé le code sur GitHub.
Prendre plaisir!!