
Serveur de configuration centralisé pour systèmes distribués avec API HTTP, stockage basé sur Git, chiffrement/déchiffrement de propriétés, et intégration avec Vault, JDBC et systèmes de fichiers locaux.
// // NE PAS MODIFIER CE FICHIER. IL A ÉTÉ GÉNÉRÉ. // Les modifications manuelles de ce fichier seront perdues lors de sa régénération. // Modifiez plutôt les fichiers dans le répertoire src/main/asciidoc/. //
image::https://circleci.com/gh/spring-cloud/spring-cloud-config/tree/master.svg?style=svg["CircleCI", link="https://circleci.com/gh/spring-cloud/spring-cloud-config/tree/master"] image::https://codecov.io/gh/spring-cloud/spring-cloud-config/branch/master/graph/badge.svg["Codecov", link="https://codecov.io/gh/spring-cloud/spring-cloud-config/branch/master"] image::https://api.codacy.com/project/badge/Grade/f064024a072c477e97dca6ed5a70fccd?branch=master["Qualité de code Codacy", link="https://www.codacy.com/app/Spring-Cloud/spring-cloud-config?branch=master&utm_source=github.com&utm_medium=referral&utm_content=spring-cloud/spring-cloud-config&utm_campaign=Badge_Grade"]
Spring Cloud Config fournit un support côté serveur et côté client pour une configuration externalisée dans un système distribué. Avec le serveur de configuration, vous disposez d'un emplacement central pour gérer les propriétés externes des applications dans tous les environnements.
Les concepts, tant côté client que côté serveur, correspondent parfaitement aux abstractions Environment et PropertySource de Spring, ils s'intègrent donc très bien avec les applications Spring, mais peuvent être utilisés avec n'importe quelle application fonctionnant dans n'importe quel langage.
Lorsqu'une application parcourt le pipeline de déploiement du développement vers les tests puis la production, vous pouvez gérer la configuration entre ces environnements et être certain que les applications disposent de tout ce dont elles ont besoin pour fonctionner lors de la migration.
L'implémentation par défaut du backend de stockage du serveur utilise git, ce qui facilite la prise en charge de versions étiquetées des environnements de configuration et permet également d'être accessible à un large éventail d'outils pour gérer le contenu.
Il est facile d'ajouter des implémentations alternatives et de les brancher avec la configuration Spring.
== Fonctionnalités
=== Serveur de configuration Spring Cloud Config
Le serveur de configuration Spring Cloud Config offre les avantages suivants :
@EnableConfigServer=== Client Spring Cloud Config Client
Spécifiquement pour les applications Spring, le client Spring Cloud Config Client vous permet de :
Environment Spring avec des sources de propriétés distantes.@RefreshScope pour les @Beans Spring qui souhaitent être réinitialisés lors d'un changement de configuration./env pour mettre à jour l'Environment et relier les @ConfigurationProperties et les niveaux de log.
** /refresh pour rafraîchir 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 sur l').== Démarrage rapide
Ce démarrage rapide vous guide pour utiliser à la fois le serveur et le client de Spring Cloud Config Server.
Tout d'abord, démarrez le serveur, comme suit :
Le serveur est une application Spring Boot, vous pouvez donc l'exécuter depuis votre IDE si vous le préférez (la classe principale est ConfigServerApplication).
Ensuite, essayez un client, comme suit :
La stratégie par défaut pour localiser les sources de propriétés consiste à cloner un dépôt git (à spring.cloud.config.server.git.uri) et à l'utiliser pour initialiser une mini SpringApplication.
L'Environment de la mini-application est utilisée pour énumérer les sources de propriétés et les publier sur un endpoint JSON.
Le service HTTP dispose de ressources sous la forme suivante :
où application est injecté comme spring.config.name dans la SpringApplication (ce qui est normalement application dans une application Spring Boot classique), profile est un profil actif (ou une liste de propriétés séparées par des virgules), et label est une étiquette git facultative (par défaut master).
Le serveur de configuration Spring Cloud Config extrait la configuration des clients distants à partir de diverses sources. L'exemple suivant obtient la configuration à partir d'un dépôt git (qui doit être fourni), comme illustré dans l'exemple suivant :
D'autres sources sont toute base de données compatible JDBC, Subversion, Hashicorp Vault, Credhub et les systèmes de fichiers locaux.
=== Utilisation côté client
Pour utiliser ces fonctionnalités dans une application, vous pouvez la construire comme une application Spring Boot qui dépend de spring-cloud-config-client (pour un exemple, voir les cas de test pour le config-client ou l'application exemple).
La manière la plus pratique d'ajouter la dépendance est avec un starter Spring Boot org.springframework.cloud:spring-cloud-starter-config.
Il existe également un parent pom et BOM (spring-cloud-starter-parent) pour les utilisateurs de Maven et un fichier de propriétés de gestion de version Spring IO pour les utilisateurs de Gradle et Spring CLI. L'exemple suivant montre une configuration Maven typique :
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>{spring-boot-docs-version}</version>
<relativePath /> <!-- lookup parent from repository -->
</parent>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>{spring-cloud-version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
<!-- repositories also needed for snapshots and milestones -->
Vous pouvez maintenant créer une application Spring Boot standard, comme le serveur HTTP suivant :
@SpringBootApplication @RestController public class Application {
@RequestMapping("/")
public String home() {
return "Hello World!";
}
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
Lorsque ce serveur HTTP s'exécute, il récupère la configuration externe à partir du serveur de configuration local par défaut (s'il est en cours d'exécution) sur le port 8888.
Pour modifier le comportement de démarrage, vous pouvez changer l'emplacement du serveur de configuration en utilisant bootstrap.properties (similaire à application.properties mais pour la phase bootstrap d'un contexte d'application), comme illustré dans l'exemple suivant :
Par défaut, si aucun nom d'application n'est défini, application sera utilisé. Pour modifier le nom, la propriété suivante peut être ajoutée au fichier bootstrap.properties :
REMARQUE : lorsque vous définissez la propriété ${spring.application.name}, ne préfixez pas le nom de votre application avec le mot réservé application- pour éviter des problèmes de résolution de la source de propriétés correcte.
Les propriétés bootstrap apparaissent dans l'endpoint /env comme une source de propriétés de haute priorité, comme illustré dans l'exemple suivant.
Une source de propriétés appelée ```configService:<URL du dépôt distant>/contient la propriétéfooavec une valeur debar` et a la plus haute priorité.
REMARQUE : L'URL dans le nom de la source de propriétés est le dépôt git, pas l'URL du serveur de configuration.
=== Application exemple
Vous pouvez trouver une application exemple https://github.com/spring-cloud/spring-cloud-config/tree/master/spring-cloud-config-sample[ici].
C'est une application Spring Boot, vous pouvez donc l'exécuter en utilisant les mécanismes habituels (par exemple, mvn spring-boot:run).
Lorsqu'elle s'exécute, elle recherche le serveur de configuration sur http://localhost:8888 (une valeur par défaut configurable), vous pouvez donc également exécuter le serveur pour voir le tout fonctionner ensemble.
L'exemple comprend un cas de test où le serveur de configuration est également démarré dans le même JVM (avec un port différent), et le test vérifie qu'une
propriété d'environnement du dépôt de configuration git est présente.
Pour changer 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 autres endroits).
Le cas de test a une méthode main() qui exécute le serveur de la même manière (regardez les logs pour son port), vous pouvez donc exécuter tout le système dans un seul processus et jouer avec (par exemple, vous pouvez exécuter la méthode main() dans votre IDE).
La méthode main() utilise target/config comme répertoire de travail du dépôt git, vous pouvez donc y faire 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 cas de test :
L'endpoint refresh signale que la propriété "sample" a changé.
== Construction
:jdkversion: 1.7
=== Compilation et test de base
Pour construire la source, vous devrez installer JDK {jdkversion}.
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
REMARQUE : 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
pourrez également avoir besoin d'ajouter -P spring si vos paramètres Maven locaux ne
contiennent pas de déclarations de dépôt pour les artefacts de pré-version Spring.
REMARQUE : Soyez conscient que vous pourriez avoir besoin d'augmenter la quantité de mémoire
disponible pour Maven en définissant une variable d'environnement MAVEN_OPTS avec
une valeur comme -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
construction, veuillez soumettre un ticket pour que les paramètres soient ajoutés au
contrôle de source.
Pour des conseils sur la façon de construire le projet, regardez dans .travis.yml s'il y en a
un. Il devrait y avoir une commande "script" et peut-être "install". Regardez également
la section "services" pour voir si des services doivent être exécutés localement (par exemple mongo ou rabbit). Ignorez les parties liées à git que
vous pourriez trouver dans "before_install" car elles concernent la configuration des identifiants git
et vous les avez déjà.
Les projets qui nécessitent un middleware incluent généralement un
docker-compose.yml, envisagez donc d'utiliser
https://docs.docker.com/compose/[Docker Compose] pour exécuter les serveurs middleware
dans des conteneurs Docker. Voir le README dans le
https://github.com/spring-cloud-samples/scripts[dépôt de démonstration de scripts]
pour des instructions spécifiques concernant les cas courants de mongo,
rabbit et redis.
REMARQUE : Si tout le reste échoue, construisez avec la commande de .travis.yml (généralement
./mvnw install).
=== Documentation
Le module spring-cloud-build a un profil "docs", et si vous l'activez,
il essaiera de construire les sources asciidoc à partir de
src/main/asciidoc. Dans le cadre de ce processus, il recherchera un
README.adoc et le traitera en chargeant toutes les inclusions, mais sans
l'analyser ni le rendre, simplement en le copiant vers ${main.basedir}
(par défaut ${basedir}, c'est-à-dire la racine du projet). S'il y a
des changements dans le README, ils apparaîtront ensuite après une construction Maven comme
un fichier modifié au bon endroit. Commitez-le simplement et poussez le changement.
=== Travailler avec le code Si vous n'avez pas de préférence pour un IDE, nous vous recommandons d'utiliser https://www.springsource.com/developer/sts[Spring Tools Suite] ou https://eclipse.org[Eclipse] lorsque vous travaillez avec le code. Nous utilisons le plugin https://eclipse.org/m2e/[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.
==== Importation dans Eclipse avec m2eclipse Nous recommandons le plugin https://eclipse.org/m2e/[m2eclipse] eclipse lorsque vous travaillez avec Eclipse. Si vous n'avez pas encore installé m2eclipse, il est disponible depuis le "marché Eclipse".
REMARQUE : 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 dire à
m2eclipse d'utiliser le bon profil pour les projets. Si vous voyez
de nombreuses erreurs différentes liées aux POMs dans les projets, vérifiez
que vous avez une installation à jour. Si vous ne pouvez pas mettre à niveau m2e,
ajoutez le profil "spring" à votre settings.xml. Alternativement, vous pouvez
copier les paramètres du dépôt du profil "spring" du pom parent
dans votre settings.xml.
==== Importation dans Eclipse sans m2eclipse Si vous préférez ne pas utiliser m2eclipse, vous pouvez générer les métadonnées du projet Eclipse en utilisant la commande suivante :
$ ./mvnw eclipse:eclipse
Les projets Eclipse générés peuvent être importés en sélectionnant importer des projets existants
depuis le menu fichier.
=== JCE
Si vous obtenez une exception due à "Illegal key size" et que vous utilisez le JDK de Sun, vous devez installer les fichiers de politique de juridiction de force illimitée de l'extension de cryptographie Java (JCE). Consultez les liens suivants pour plus d'informations :
https://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html[Java 6 JCE]
https://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html[Java 7 JCE]
https://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html[Java 8 JCE]
Extrayez les fichiers JCE dans le dossier JDK/jre/lib/security pour la version de JRE/JDK x64/x86 que vous utilisez.
== Contribuer
:spring-cloud-build-branch: master
Spring Cloud est publié sous la licence Apache 2.0 non restrictive, et suit un processus de développement Github très standard, en utilisant le suivi Github pour les problèmes et la fusion des pull requests dans master. Si vous souhaitez contribuer, même quelque chose de trivial, n'hésitez pas, mais suivez les directives ci-dessous.
=== Signer le contrat de licence du contributeur Avant d'accepter un correctif ou une pull request non trivial, nous aurons besoin que vous signiez le https://cla.pivotal.io/sign/spring[Contrat de licence du contributeur (Contributor License Agreement)]. La signature du contrat du contributeur ne donne à personne des droits de commit sur le dépôt 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 pourraient être invités à rejoindre l'équipe principale, et obtenir la capacité de fusionner les pull requests.
=== Code de conduite Ce projet adhère au https://github.com/spring-cloud/spring-cloud-build/blob/master/docs/src/main/asciidoc/code-of-conduct.adoc[code de conduite] du Contributor Covenant. En participant, vous êtes censé respecter ce code. Veuillez signaler tout comportement inacceptable à [email protected].
=== Conventions de code et entretien ménager Aucun de ces points n'est essentiel pour une pull request, mais ils aideront tous. Ils peuvent également être ajoutés après la pull request originale mais avant une fusion.
eclipse-code-formatter.xml du
https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/spring-cloud-dependencies-parent/eclipse-code-formatter.xml[projet Spring
Cloud Build]. Si vous utilisez IntelliJ, vous pouvez utiliser le
https://plugins.jetbrains.com/plugin/6546[plugin Eclipse Code Formatter]
pour importer le même fichier..java ont un commentaire de classe Javadoc simple avec au moins une
balise @author vous identifiant, et de préférence au moins un paragraphe sur ce que la classe
fait..java (copiez à partir des fichiers existants
dans le projet)@author dans les fichiers .java que vous modifiez substantiellement (plus
que des modifications cosmétiques).Fixes gh-XXXX à la fin du message
de commit (où XXXX est le numéro du problème).=== Checkstyle
Spring Cloud Build est livré avec un ensemble de règles checkstyle. Vous pouvez les trouver dans le module spring-cloud-build-tools. Les fichiers les plus notables du module sont :
<1> Règles Checkstyle par défaut <2> Configuration de l'en-tête de fichier <3> Règles de suppression par défaut
==== Configuration de Checkstyle
Les règles Checkstyle sont désactivées par défaut. Pour ajouter checkstyle à votre projet, définissez simplement les propriétés et plugins suivants.
<reporting>
<plugins>
<plugin> <5>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
</plugin>
</plugins>
</reporting>
${project.root}/src/checkstyle/checkstyle-suppressions.xml avec vos suppressions. Exemple :.projectRoot/src/checkstyle/checkstyle-suppresions.xmlIl est conseillé de copier ${spring-cloud-build.rootFolder}/.editorconfig et ${spring-cloud-build.rootFolder}/.springformat dans votre projet. Ainsi, certaines règles de formatage par défaut seront appliquées. Vous pouvez le faire en exécutant ce script :```bash
$ curl https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/.editorconfig -o .editorconfig
$ touch .springformat
=== Configuration de l'IDE
==== Intellij IDEA
Pour 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 https://github.com/spring-cloud/spring-cloud-build/tree/master/spring-cloud-build-tools[Spring Cloud Build].
.spring-cloud-build-tools/
----
└── src
├── checkstyle
│ └── checkstyle-suppressions.xml <3>
└── main
└── resources
├── checkstyle-header.txt <2>
├── checkstyle.xml <1>
└── intellij
├── Intellij_Project_Defaults.xml <4>
└── Intellij_Spring_Boot_Java_Conventions.xml <5>
----
<1> Règles Checkstyle par défaut
<2> Configuration de l'en-tête de fichier
<3> Règles de suppression par défaut
<4> Paramètres par défaut du projet pour Intellij qui appliquent la plupart des règles Checkstyle
<5> Conventions de style de projet pour Intellij qui appliquent la plupart des règles Checkstyle
.Style de code
image::https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/{spring-cloud-build-branch}/docs/src/main/asciidoc/images/intellij-code-style.png[Code style]
Allez dans `Fichier` -> `Paramètres` -> `Éditeur` -> `Style de code`. Cliquez sur l'icône à côté de la section `Schéma`. Ensuite, cliquez sur la valeur `Importer un schéma` et choisissez l'option `XML du style de code Intellij IDEA`. Importez le fichier `spring-cloud-build-tools/src/main/resources/intellij/Intellij_Spring_Boot_Java_Conventions.xml`.
.Profils d'inspection
image::https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/{spring-cloud-build-branch}/docs/src/main/asciidoc/images/intellij-inspections.png[Code style]
Allez dans `Fichier` -> `Paramètres` -> `Éditeur` -> `Inspections`. Cliquez sur l'icône à côté de la section `Profil`. Ensuite, cliquez sur `Importer un profil` et importez le fichier `spring-cloud-build-tools/src/main/resources/intellij/Intellij_Project_Defaults.xml`.
.Checkstyle
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.
image::https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/{spring-cloud-build-branch}/docs/src/main/asciidoc/images/intellij-checkstyle.png[Checkstyle]
Allez dans `Fichier` -> `Paramètres` -> `Autres paramètres` -> `Checkstyle`. Cliquez sur l'icône `+` dans la section `Fichier de configuration`. Vous devrez définir d'où les règles checkstyle doivent être chargées. Dans l'image ci-dessus, nous avons choisi les règles à partir du dépôt cloné de Spring Cloud Build. Cependant, vous pouvez pointer vers le dépôt GitHub de Spring Cloud Build (par exemple, pour `checkstyle.xml` : `https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/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-tools/src/main/resources/checkstyle-header.txt` de Spring Cloud Build, que ce soit dans votre dépôt cloné ou via l'URL `https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/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-tools/src/checkstyle/checkstyle-suppressions.xml` de Spring Cloud Build, que ce soit dans votre dépôt cloné ou via l'URL `https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/spring-cloud-build-tools/src/checkstyle/checkstyle-suppressions.xml`.
- `checkstyle.additional.suppressions.file` - cette variable correspond aux suppressions dans votre projet local. Par exemple, vous travaillez sur `spring-cloud-contract`. Pointez alors vers le dossier `project-root/src/checkstyle/checkstyle-suppressions.xml`. Un exemple pour `spring-cloud-contract` serait : `/home/username/spring-cloud-contract/src/checkstyle/checkstyle-suppressions.xml`.
IMPORTANT : N'oubliez pas de définir la `Portée d'analyse` sur `Toutes les sources` car nous appliquons les règles checkstyle aux sources de production et de test.
start()ApplicationContext