Spring Cloud Config Server offre les avantages suivants :
API basée sur les ressources HTTP pour la configuration externe (paires nom-valeur ou contenu YAML équivalent)
Chiffrer et déchiffrer les valeurs de propriété (symétriques ou asymétriques)
Facilement intégrable dans une application Spring Boot à l'aide de @EnableConfigServer
Spécifiquement pour les applications Spring, Spring Cloud Config Client vous permet :
Liez-vous au serveur de configuration et initialisez Spring Environment
avec des sources de propriétés distantes.
Chiffrez et déchiffrez les valeurs de propriété (symétriques ou asymétriques).
@RefreshScope
pour Spring @Beans
qui souhaitent être réinitialisés lorsque la configuration change.
Utiliser les points de terminaison de gestion :
/env
pour mettre à jour Environment
et relier @ConfigurationProperties
et les niveaux de journalisation.
/refresh
pour actualiser les beans @RefreshScope
.
/restart
pour redémarrer le contexte Spring (désactivé par défaut).
/pause
et /resume
pour appeler les méthodes Lifecycle
( stop()
et start()
sur ApplicationContext
).
Contexte d'application Bootstrap : un contexte parent pour l'application principale qui peut être entraîné à faire n'importe quoi (par défaut, il se lie au serveur de configuration et déchiffre les valeurs des propriétés).
Vous pouvez trouver un exemple d’application ici. Il s'agit d'une application Spring Boot, vous pouvez donc l'exécuter en utilisant les mécanismes habituels (par exemple, mvn spring-boot:run
). Lorsqu'il s'exécute, il recherche le serveur de configuration sur http://localhost:8888
(une valeur par défaut configurable), afin que vous puissiez également exécuter le serveur pour voir tout fonctionner ensemble.
L'exemple comporte un scénario de test dans lequel le serveur de configuration est également démarré dans la même JVM (avec un port différent) et le test affirme qu'une propriété d'environnement du référentiel de configuration git est présente. Pour modifier l'emplacement du serveur de configuration, vous pouvez définir spring.cloud.config.uri
dans bootstrap.yml
(ou dans les propriétés système et à d'autres endroits).
Le scénario de test a une méthode main()
qui exécute le serveur de la même manière (surveillez les journaux pour son port), vous pouvez donc exécuter l'ensemble du système en un seul processus et jouer avec (par exemple, vous pouvez exécuter la main()
dans votre IDE). La méthode main()
utilise target/config
pour le répertoire de travail du référentiel git, vous pouvez donc y apporter des modifications locales et les voir reflétées dans l'application en cours d'exécution. L'exemple suivant montre une session de bricolage avec le scénario de test :
$ curl localhost:8080/env/sample montest $ vi cible/config/mytest.properties .. changer la valeur de "sample", éventuellement valider $ curl -X POST localhost:8080/rafraîchir ["échantillon"] $ curl localhost:8080/env/sample valeuréchantillon
Le point de terminaison d’actualisation signale que la propriété « exemple » a été modifiée.
Pour créer la source, vous devrez installer JDK 17.
Spring Cloud utilise Maven pour la plupart des activités liées à la construction, et vous devriez pouvoir démarrer assez rapidement en clonant le projet qui vous intéresse et en tapant
$ ./mvnw installer
Note | Vous pouvez également installer Maven (>=3.3.3) vous-même et exécuter la commande mvn à la place de ./mvnw dans les exemples ci-dessous. Si vous faites cela, vous devrez peut-être également ajouter -P spring si vos paramètres Maven locaux ne contiennent pas de déclarations de référentiel pour les artefacts de pré-version Spring. |
Note | Sachez que vous devrez peut-être augmenter la quantité de mémoire disponible pour Maven en définissant une variable d'environnement MAVEN_OPTS avec une valeur telle que -Xmx512m -XX:MaxPermSize=128m . Nous essayons de couvrir cela dans la configuration .mvn , donc si vous constatez que vous devez le faire pour réussir une build, veuillez créer un ticket pour que les paramètres soient ajoutés au contrôle de code source. |
Les projets qui nécessitent un middleware (c'est-à-dire Redis) pour les tests nécessitent généralement qu'une instance locale de [Docker](https://www.docker.com/get-started) soit installée et exécutée.
Le module spring-cloud-build a un profil "docs", et si vous l'activez, il essaiera de créer des sources asciidoc en utilisant Antora à partir de modules/ROOT/
.
Dans le cadre de ce processus, il recherchera un docs/src/main/asciidoc/README.adoc
et le traitera en chargeant toutes les inclusions, mais sans l'analyser ni le rendre, il le copiera simplement dans ${main.basedir}
(par défaut : ${basedir}
, c'est à dire la racine du projet). S'il y a des modifications dans le fichier README, il apparaîtra alors après une construction Maven en tant que fichier modifié au bon endroit. Validez-le simplement et poussez le changement.
Si vous n'avez pas de préférence IDE, nous vous recommandons d'utiliser Spring Tools Suite ou Eclipse lorsque vous travaillez avec le code. Nous utilisons le plugin m2eclipse Eclipse pour le support Maven. D'autres IDE et outils devraient également fonctionner sans problème tant qu'ils utilisent Maven 3.3.3 ou supérieur.
Les projets Spring Cloud nécessitent que le profil Maven « spring » soit activé pour résoudre les référentiels de jalons et d'instantanés Spring. Utilisez votre IDE préféré pour définir ce profil comme étant actif, sinon vous risquez de rencontrer des erreurs de build.
Nous recommandons le plugin m2eclipse Eclipse lorsque vous travaillez avec Eclipse. Si vous n'avez pas encore installé m2eclipse, il est disponible sur le "marché Eclipse".
Note | Les anciennes versions de m2e ne prennent pas en charge Maven 3.3, donc une fois les projets importés dans Eclipse, vous devrez également indiquer à m2eclipse d'utiliser le bon profil pour les projets. Si vous voyez de nombreuses erreurs différentes liées aux POM dans les projets, vérifiez que vous disposez d'une installation à jour. Si vous ne pouvez pas mettre à niveau m2e, ajoutez le profil "spring" à votre settings.xml . Vous pouvez également copier les paramètres du référentiel du profil "spring" du pom parent dans votre settings.xml . |
Si vous préférez ne pas utiliser m2eclipse, vous pouvez générer les métadonnées du projet Eclipse à l'aide de la commande suivante :
$ ./mvnw éclipse:éclipse
Les projets Eclipse générés peuvent être importés en sélectionnant import existing projects
dans le menu file
.
Si vous obtenez une exception en raison d'une « taille de clé illégale » et que vous utilisez le JDK de Sun, vous devez installer les fichiers de politique de juridiction à force illimitée Java Cryptography Extension (JCE). Consultez les liens suivants pour plus d’informations :
Java 6JCE
Java 7JCE
Java 8JCE
Extrayez les fichiers JCE dans le dossier JDK/jre/lib/security
pour la version de JRE/JDK x64/x86 que vous utilisez.
Spring Cloud est publié sous la licence non restrictive Apache 2.0 et suit un processus de développement Github très standard, utilisant le tracker Github pour les problèmes et fusionnant les demandes d'extraction dans main. Si vous souhaitez contribuer, même quelque chose de trivial, n'hésitez pas, mais suivez les directives ci-dessous.
Avant d'accepter un correctif non trivial ou une pull request, nous aurons besoin que vous signiez le contrat de licence de contributeur. La signature de l'accord de contributeur n'accorde à personne de droits d'engagement sur le référentiel principal, mais cela signifie que nous pouvons accepter vos contributions, et vous obtiendrez un crédit d'auteur si nous le faisons. Les contributeurs actifs peuvent être invités à rejoindre l'équipe principale et avoir la possibilité de fusionner les demandes d'extraction.
Ce projet adhère au code de conduite Contributor Covenant. En participant, vous êtes censé respecter ce code. Veuillez signaler tout comportement inacceptable à [email protected].
Aucun de ces éléments n’est essentiel pour une pull request, mais ils seront tous utiles. Ils peuvent également être ajoutés après la pull request d'origine mais avant une fusion.
Utilisez les conventions de format de code Spring Framework. Si vous utilisez Eclipse, vous pouvez importer les paramètres du formateur à l'aide du fichier eclipse-code-formatter.xml
du projet Spring Cloud Build. Si vous utilisez IntelliJ, vous pouvez utiliser le plugin Eclipse Code Formatter pour importer le même fichier.
Assurez-vous que tous les nouveaux fichiers .java
contiennent un simple commentaire de classe Javadoc avec au moins une balise @author
vous identifiant, et de préférence au moins un paragraphe expliquant à quoi sert la classe.
Ajoutez le commentaire d'en-tête de licence ASF à tous les nouveaux fichiers .java
(copie à partir des fichiers existants dans le projet)
Ajoutez-vous en tant que @author
aux fichiers .java que vous modifiez de manière substantielle (plus que des modifications cosmétiques).
Ajoutez des Javadocs et, si vous modifiez l'espace de noms, des éléments de documentation XSD.
Quelques tests unitaires seraient également très utiles : quelqu'un doit le faire.
Si personne d'autre n'utilise votre branche, veuillez la rebaser par rapport à la branche principale actuelle (ou à une autre branche cible du projet principal).
Lorsque vous rédigez un message de validation, veuillez suivre ces conventions. Si vous résolvez un problème existant, veuillez ajouter Fixes gh-XXXX
à la fin du message de validation (où XXXX est le numéro du problème).
Spring Cloud Build est livré avec un ensemble de règles de style de contrôle. Vous pouvez les trouver dans le module spring-cloud-build-tools
. Les fichiers les plus notables du module sont :
└──src ├── style de contrôle │ └── checkstyle-suppressions.xml (3) └── principal └── ressources ├── checkstyle-header.txt (2) └── checkstyle.xml (1)
Règles de style de contrôle par défaut
Configuration de l'en-tête de fichier
Règles de suppression par défaut
Les règles de style de contrôle sont désactivées par défaut . Pour ajouter un style de contrôle à votre projet, définissez simplement les propriétés et plugins suivants.
<propriétés> <maven-checkstyle-plugin.failsOnError>true</maven-checkstyle-plugin.failsOnError> (1) <maven-checkstyle-plugin.failsOnViolation>true </maven-checkstyle-plugin.failsOnViolation> (2) <maven-checkstyle-plugin.includeTestSourceDirectory>true </maven-checkstyle-plugin.includeTestSourceDirectory> (3) </propriétés> <construire> <plugins> <plugin> (4) <groupId>io.spring.javaformat</groupId> <artifactId>spring-javaformat-maven-plugin</artifactId> </plugin> <plugin> (5) <groupId>org.apache.maven.plugins</groupId> <artifactId>plugin-maven-checkstyle-plugin</artifactId> </plugin> </plugins> <rapport> <plugins> <plugin> (5) <groupId>org.apache.maven.plugins</groupId> <artifactId>plugin-maven-checkstyle-plugin</artifactId> </plugin> </plugins> </rapport> </build>
Échec de la construction en cas d'erreurs Checkstyle
Échec de la construction en cas de violations de Checkstyle
Checkstyle analyse également les sources de test
Ajoutez le plugin Spring Java Format qui reformatera votre code pour passer la plupart des règles de formatage Checkstyle
Ajoutez le plugin checkstyle à vos phases de construction et de reporting
Si vous devez supprimer certaines règles (par exemple, la longueur de ligne doit être plus longue), alors il vous suffit de définir un fichier sous ${project.root}/src/checkstyle/checkstyle-suppressions.xml
avec vos suppressions. Exemple:
<?xml version="1.0"?> <!DOCTYPE suppressions PUBLIC "-//Puppy Crawl//DTD Suppressions 1.1//EN" "https://www.puppycrawl.com/dtds/suppressions_1_1.dtd"> <suppressions> <suppress files=".*ConfigServerApplication.java" checks="HideUtilityClassConstructor"/> <suppress files=".*ConfigClientWatch.java" checks="LineLengthCheck"/> </suppressions>
Il est conseillé de copier les ${spring-cloud-build.rootFolder}/.editorconfig
et ${spring-cloud-build.rootFolder}/.springformat
dans votre projet. De cette façon, certaines règles de formatage par défaut seront appliquées. Vous pouvez le faire en exécutant ce script :
$ curl https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/.editorconfig -o .editorconfig
$ touch .springformat
Afin de configurer Intellij, vous devez importer nos conventions de codage, nos profils d'inspection et configurer le plugin checkstyle. Les fichiers suivants se trouvent dans le projet Spring Cloud Build.
└──src ├── style de contrôle │ └── checkstyle-suppressions.xml (3) └── principal └── ressources ├── checkstyle-header.txt (2) ├── checkstyle.xml (1) └── intelligence ├── Intellij_Project_Defaults.xml (4) └── Intellij_Spring_Boot_Java_Conventions.xml (5)
Règles de style de contrôle par défaut
Configuration de l'en-tête de fichier
Règles de suppression par défaut
Valeurs par défaut du projet pour Intellij qui appliquent la plupart des règles Checkstyle
Conventions de style de projet pour Intellij qui appliquent la plupart des règles Checkstyle
Allez dans File
→ Settings
→ Editor
→ Code style
. Là, cliquez sur l'icône à côté de la section Scheme
. Là, cliquez sur la valeur Import Scheme
et choisissez l’option Intellij IDEA code style XML
. Importez le fichier spring-cloud-build-tools/src/main/resources/intellij/Intellij_Spring_Boot_Java_Conventions.xml
.
Accédez à File
→ Settings
→ Editor
→ Inspections
. Là, cliquez sur l'icône à côté de la section Profile
. Là, cliquez sur le Import Profile
et importez le fichier spring-cloud-build-tools/src/main/resources/intellij/Intellij_Project_Defaults.xml
.
Pour qu'Intellij fonctionne avec Checkstyle, vous devez installer le plugin Checkstyle
. Il est conseillé d'installer également Assertions2Assertj
pour convertir automatiquement les assertions JUnit
Accédez à File
→ Settings
→ Other settings
→ Checkstyle
. Cliquez là sur l'icône +
dans la section Configuration file
. Là, vous devrez définir où les règles de style de contrôle doivent être sélectionnées. Dans l'image ci-dessus, nous avons sélectionné les règles du référentiel Spring Cloud Build cloné. Cependant, vous pouvez pointer vers le référentiel GitHub de Spring Cloud Build (par exemple pour le checkstyle.xml
: https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/main/resources/checkstyle.xml
). Nous devons fournir les variables suivantes :
checkstyle.header.file
- veuillez le pointer vers le fichier Spring Cloud Build, spring-cloud-build-tools/src/main/resources/checkstyle-header.txt
soit dans votre dépôt cloné, soit via https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/main/resources/checkstyle-header.txt
URL https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/main/resources/checkstyle-header.txt
.
checkstyle.suppressions.file
- suppressions par défaut. Veuillez le pointer vers le fichier Spring Cloud Build, spring-cloud-build-tools/src/checkstyle/checkstyle-suppressions.xml
soit dans votre dépôt cloné, soit via https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/main/spring-cloud-build-tools/src/checkstyle/checkstyle-suppressions.xml
URL.
checkstyle.additional.suppressions.file
- cette variable correspond aux suppressions dans votre projet local. Par exemple, vous travaillez sur spring-cloud-contract
. Pointez ensuite sur le dossier project-root/src/checkstyle/checkstyle-suppressions.xml
. Un exemple de spring-cloud-contract
serait : /home/username/spring-cloud-contract/src/checkstyle/checkstyle-suppressions.xml
.
Important | N'oubliez pas de définir la Scan Scope sur All sources car nous appliquons des règles de style de contrôle pour les sources de production et de test. |
Spring Cloud Build apporte le basepom:duplicate-finder-maven-plugin
, qui permet de signaler les classes et ressources en double et en conflit sur le chemin de classe Java.
Le chercheur de doublons est activé par défaut et s'exécutera lors de la phase verify
de votre build Maven, mais il ne prendra effet dans votre projet que si vous ajoutez le duplicate-finder-maven-plugin
à la section build
du pom.xml
du projet.
< build >
< plugins >
< plugin >
< groupId >org.basepom.maven</ groupId >
< artifactId >duplicate-finder-maven-plugin</ artifactId >
</ plugin >
</ plugins >
</ build >
Pour les autres propriétés, nous avons défini les valeurs par défaut comme indiqué dans la documentation du plugin.
Vous pouvez facilement les remplacer, mais en définissant la valeur de la propriété sélectionnée avec le préfixe duplicate-finder-maven-plugin
. Par exemple, définissez duplicate-finder-maven-plugin.skip
sur true
afin d'ignorer la vérification des doublons dans votre build.
Si vous devez ajouter ignoredClassPatterns
ou ignoredResourcePatterns
à votre configuration, assurez-vous de les ajouter dans la section de configuration du plugin de votre projet :
< build >
< plugins >
< plugin >
< groupId >org.basepom.maven</ groupId >
< artifactId >duplicate-finder-maven-plugin</ artifactId >
< configuration >
< ignoredClassPatterns >
< ignoredClassPattern >org.joda.time.base.BaseDateTime</ ignoredClassPattern >
< ignoredClassPattern >.*module-info</ ignoredClassPattern >
</ ignoredClassPatterns >
< ignoredResourcePatterns >
< ignoredResourcePattern >changelog.txt</ ignoredResourcePattern >
</ ignoredResourcePatterns >
</ configuration >
</ plugin >
</ plugins >
</ build >