shoucheng3/spring-cloud__spring-cloud-config_cve-2020-5405_2-1-6-releaseServeur de configuration centralisé pour systèmes distribués avec API HTTP, chiffrement/déchiffrement des propriétés, et prise en charge des backends Git, Vault, JDBC et système de fichiers local.
//// NE MODIFIEZ PAS CE FICHIER. IL A ÉTÉ GÉNÉRÉ. Les modifications manuelles de ce fichier seront perdues lorsqu'il sera regénéré. 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["Codacy code quality", 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 offre un support côté serveur et côté client pour la configuration externalisée dans un système distribué. Avec le serveur de configuration, vous disposez d'un endroit central pour gérer les propriétés externes des applications dans tous les environnements. Les concepts des deux côtés (client et serveur) correspondent exactement aux abstractions Environment et PropertySource de Spring, donc ils s'intègrent très bien avec les applications Spring mais peuvent être utilisés avec n'importe quelle application, quel que soit le langage. Lorsqu'une application progresse dans 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 stockage backend du serveur utilise git, ce qui permet de gérer facilement des versions étiquetées des environnements de configuration, tout en étant accessible à un large éventail d'outils de gestion du contenu. Il est facile d'ajouter des implémentations alternatives et de les intégrer via la configuration Spring.
== Fonctionnalités
=== Serveur de configuration Spring Cloud Config
Spring Cloud Config Server offre les avantages suivants :
@EnableConfigServer=== Client Spring Cloud Config
Plus spécifiquement pour les applications Spring, Spring Cloud Config Client vous permet de :
Environment Spring avec des sources de propriétés distantes.@RefreshScope pour les @Beans Spring qui doivent être réinitialisés lorsque la configuration change./env pour mettre à jour l'Environment et relier à nouveau 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 le ).== Démarrage rapide
Ce démarrage rapide vous guide à travers l'utilisation du serveur et du 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 est de cloner un dépôt git (à spring.cloud.config.server.git.uri) et de l'utiliser pour initialiser une mini SpringApplication. L'Environment de la mini-application est utilisé pour énumérer les sources de propriétés et les publier sur un point de terminaison JSON.
Le service HTTP possède des 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 optionnelle (par défaut master).
Spring Cloud Config Server tire la configuration pour les clients distants de diverses sources. L'exemple suivant obtient la configuration 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 de config-client ou l'application exemple). Le moyen le plus pratique d'ajouter la dépendance est d'utiliser 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 Maven et un fichier de propriétés de gestion de version Spring IO pour les utilisateurs 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 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 :
NOTE : 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 les problèmes de résolution de la source de propriétés correcte.
Les propriétés bootstrap apparaissent dans le point de terminaison /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>/<nom du fichier> contient la propriété foo avec une valeur de bar et a la plus haute priorité.
NOTE : 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 l'ensemble fonctionner ensemble.
L'exemple comporte un cas de test où le serveur de configuration est également démarré dans la 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 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 cas de test :
Le point de terminaison refresh signale que la propriété « sample » a changé.
== Construction
:jdkversion: 1.7
=== Compilation et test de base
Pour construire le 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
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 le faites, vous devrez peut-être aussi 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.
NOTE : Soyez conscient 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 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 compilation, 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 que vous avez déjà.
Les projets qui nécessitent un intergiciel incluent généralement un fichier docker-compose.yml, donc envisagez d'utiliser https://docs.docker.com/compose/[Docker Compose] pour exécuter les serveurs intergiciels dans des conteneurs Docker. Voir le README dans le https://github.com/spring-cloud-samples/scripts[dépôt de démonstration scripts] pour des instructions spécifiques sur les cas courants de mongo, rabbit et redis.
NOTE : 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, il apparaîtra après une construction Maven comme un fichier modifié au bon endroit. Il suffit de le valider et de pousser 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] pour le support Maven. Les autres IDE et outils devraient également fonctionner sans problème tant qu'ils utilisent Maven 3.3.3 ou plus récent.
==== Importation dans Eclipse avec m2eclipse Nous recommandons le plugin https://eclipse.org/m2e/[m2eclipse] lorsque vous travaillez avec Eclipse. Si vous n'avez pas déjà installé m2eclipse, il est disponible depuis le "marché Eclipse".
NOTE : Les versions plus anciennes de m2e ne supportent pas 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 POM 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. Sinon, vous pouvez copier les paramètres de 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 import existing projects depuis le menu file.
=== 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 non restrictive Apache 2.0 et suit un processus de développement Github très standard, en utilisant le tracker Github pour les problèmes et en fusionnant les 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 vous demanderons de signer le https://cla.pivotal.io/sign/spring[Contrat de licence du contributeur]. La signature du contrat de contributeur n'accorde à personne le droit 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 Covenant du contributeur. En participant, vous vous engagez à respecter ce code. Veuillez signaler tout comportement inacceptable à [email protected].
=== Conventions de code et entretien ménager Aucune de ces choses n'est essentielle pour une pull request, mais elles aideront toutes. Elles peuvent également être ajoutées après la pull request originale mais avant une fusion.
eclipse-code-formatter.xml du projet https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/spring-cloud-dependencies-parent/eclipse-code-formatter.xml[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 simple commentaire de classe Javadoc avec au moins une balise @author vous identifiant, et de préférence au moins un paragraphe sur l'utilité de la classe..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 les fichiers ${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 IDE
==== Intellij IDEA
Pour configurer Intellij, vous devez importer nos conventions de codage, les profils d'inspection et configurer le plugin Checkstyle.
Les fichiers suivants sont disponibles 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 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 `File` -> `Settings` -> `Editor` -> `Code style`. Cliquez sur l'icône à côté de la section `Scheme`. Cliquez ensuite 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`.
.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 `File` -> `Settings` -> `Editor` -> `Inspections`. Cliquez sur l'icône à côté de la section `Profile`. Cliquez ensuite sur `Import Profile` 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 également conseillé d'installer `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 `File` -> `Settings` -> `Other settings` -> `Checkstyle`. Cliquez sur l'icône `+` dans la section `Configuration file`. Vous devrez ensuite définir d'où les règles Checkstyle doivent être récupérées. Dans l'image ci-dessus, nous avons sélectionné les règles depuis le 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, soit dans votre dépôt cloné, soit 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, soit dans votre dépôt cloné, soit 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, si vous travaillez sur `spring-cloud-contract`, pointez vers le dossier `project-root/src/checkstyle/checkstyle-suppressions.xml`. Exemple pour `spring-cloud-contract` : `/home/username/spring-cloud-contract/src/checkstyle/checkstyle-suppressions.xml`.
IMPORTANT : N'oubliez pas de définir le `Scan Scope` sur `All sources` car nous appliquons les règles Checkstyle pour les sources de production et de test.
start()ApplicationContext