From 68f5496fe32e429cc6a0a7b858192fcb032f81b3 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Sat, 29 Sep 2018 11:21:16 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- multi/multi__embedding_the_config_server.html | 2 +- ...sh_notifications_and_spring_cloud_bus.html | 2 +- multi/multi__quick_start.html | 2 +- multi/multi__serving_alternative_formats.html | 2 +- multi/multi__serving_plain_text.html | 2 +- multi/multi__spring_cloud_config_client.html | 4 +-- multi/multi__spring_cloud_config_server.html | 32 ++++++++--------- multi/multi_pr01.html | 2 +- multi/multi_spring-cloud-config.html | 2 +- single/spring-cloud-config.html | 34 +++++++++---------- spring-cloud-config.html | 2 +- spring-cloud-config.xml | 24 ++++++------- 12 files changed, 55 insertions(+), 55 deletions(-) diff --git a/multi/multi__embedding_the_config_server.html b/multi/multi__embedding_the_config_server.html index b520a7ed..39187b6a 100644 --- a/multi/multi__embedding_the_config_server.html +++ b/multi/multi__embedding_the_config_server.html @@ -1,6 +1,6 @@ - 5. Embedding the Config Server
5. Embedding the Config Server
Prev   Next

5. Embedding the Config Server

The Config Server runs best as a standalone application. + 5. Embedding the Config Server

5. Embedding the Config Server
Prev   Next

5. Embedding the Config Server

The Config Server runs best as a standalone application. However, if need be, you can embed it in another application. To do so, use the @EnableConfigServer annotation. An optional property named spring.cloud.config.server.bootstrap can be useful in this case is. diff --git a/multi/multi__push_notifications_and_spring_cloud_bus.html b/multi/multi__push_notifications_and_spring_cloud_bus.html index 2e4df787..108bcafd 100644 --- a/multi/multi__push_notifications_and_spring_cloud_bus.html +++ b/multi/multi__push_notifications_and_spring_cloud_bus.html @@ -1,6 +1,6 @@ - 6. Push Notifications and Spring Cloud Bus

6. Push Notifications and Spring Cloud Bus
Prev   Next

6. Push Notifications and Spring Cloud Bus

Many source code repository providers (such as Github, Gitlab, Gitea, Gitee, Gogs, or Bitbucket) notify you of changes in a repository through a webhook. + 6. Push Notifications and Spring Cloud Bus

6. Push Notifications and Spring Cloud Bus
Prev   Next

6. Push Notifications and Spring Cloud Bus

Many source code repository providers (such as Github, Gitlab, Gitea, Gitee, Gogs, or Bitbucket) notify you of changes in a repository through a webhook. You can configure the webhook through the provider’s user interface as a URL and a set of events in which you are interested. For instance, Github uses a POST to the webhook with a JSON body containing a list of commits and a header (X-Github-Event) set to push. If you add a dependency on the spring-cloud-config-monitor library and activate the Spring Cloud Bus in your Config Server, then a /monitor endpoint is enabled.

When the webhook is activated, the Config Server sends a RefreshRemoteApplicationEvent targeted at the applications it thinks might have changed. diff --git a/multi/multi__quick_start.html b/multi/multi__quick_start.html index d04a722d..87429e57 100644 --- a/multi/multi__quick_start.html +++ b/multi/multi__quick_start.html @@ -1,6 +1,6 @@ - 1. Quick Start

1. Quick Start
Prev   Next

1. Quick Start

This quick start walks through using both the server and the client of Spring Cloud Config Server.

First, start the server, as follows:

$ cd spring-cloud-config-server
+   1. Quick Start
1. Quick Start
Prev   Next
1. Quick Start
This quick start walks through using both the server and the client of Spring Cloud Config Server.
First, start the server, as follows:
$ cd spring-cloud-config-server
 $ ../mvnw spring-boot:run
The server is a Spring Boot application, so you can run it from your IDE if you prefer to do so (the main class is ConfigServerApplication).
Next try out a client, as follows:
$ curl localhost:8888/foo/development
 {"name":"foo","label":"master","propertySources":[
   {"name":"https://github.com/scratches/config-repo/foo-development.properties","source":{"bar":"spam"}},
diff --git a/multi/multi__serving_alternative_formats.html b/multi/multi__serving_alternative_formats.html
index 1a0c399d..87c3556c 100644
--- a/multi/multi__serving_alternative_formats.html
+++ b/multi/multi__serving_alternative_formats.html
@@ -1,6 +1,6 @@
 
       
-   3. Serving Alternative Formats
3. Serving Alternative Formats
Prev   Next
3. Serving Alternative Formats
The default JSON format from the environment endpoints is perfect for consumption by Spring applications, because it maps directly onto the Environment abstraction.
+   3. Serving Alternative Formats
3. Serving Alternative Formats
Prev   Next
3. Serving Alternative Formats
The default JSON format from the environment endpoints is perfect for consumption by Spring applications, because it maps directly onto the Environment abstraction.
 If you prefer, you can consume the same data as YAML or Java properties by adding a suffix (".yml", ".yaml" or ".properties") to the resource path.
 This can be useful for consumption by applications that do not care about the structure of the JSON endpoints or the extra metadata they provide (for example, an application that is not using Spring might benefit from the simplicity of this approach).
The YAML and properties representations have an additional flag (provided as a boolean query parameter called resolvePlaceholders) to signal that placeholders in the source documents (in the standard Spring ${…​} form) should be resolved in the output before rendering, where possible.
 This is a useful feature for consumers that do not know about the Spring placeholder conventions.
[Note]Note
There are limitations in using the YAML or properties formats, mainly in relation to the loss of metadata.
diff --git a/multi/multi__serving_plain_text.html b/multi/multi__serving_plain_text.html
index 7892d605..2d3fa600 100644
--- a/multi/multi__serving_plain_text.html
+++ b/multi/multi__serving_plain_text.html
@@ -1,6 +1,6 @@
 
       
-   4. Serving Plain Text
4. Serving Plain Text
Prev   Next
4. Serving Plain Text
Instead of using the Environment abstraction (or one of the alternative representations of it in YAML or properties format), your applications might need generic plain-text configuration files that are tailored to their environment.
+   4. Serving Plain Text
4. Serving Plain Text
Prev   Next
4. Serving Plain Text
Instead of using the Environment abstraction (or one of the alternative representations of it in YAML or properties format), your applications might need generic plain-text configuration files that are tailored to their environment.
 The Config Server provides these through an additional endpoint at /{name}/{profile}/{label}/{path}, where name, profile, and label have the same meaning as the regular environment endpoint, but path is a file name (such as log.xml).
 The source files for this endpoint are located in the same way as for the environment endpoints.
 The same search path is used for properties and YAML files.
diff --git a/multi/multi__spring_cloud_config_client.html b/multi/multi__spring_cloud_config_client.html
index 3fbccbe3..3ac2ffad 100644
--- a/multi/multi__spring_cloud_config_client.html
+++ b/multi/multi__spring_cloud_config_client.html
@@ -1,9 +1,9 @@
 
       
-   7. Spring Cloud Config Client
7. Spring Cloud Config Client
Prev   
7. Spring Cloud Config Client
A Spring Boot application can take immediate advantage of the Spring Config Server (or other external property sources provided by the application developer).
+   7. Spring Cloud Config Client
7. Spring Cloud Config Client
Prev   
7. Spring Cloud Config Client
A Spring Boot application can take immediate advantage of the Spring Config Server (or other external property sources provided by the application developer).
 It also picks up some additional useful features related to Environment change events.
7.1 Config First Bootstrap
The default behavior for any application that has the Spring Cloud Config Client on the classpath is as follows:
 When a config client starts, it binds to the Config Server (through the spring.cloud.config.uri bootstrap configuration property) and initializes Spring Environment with remote property sources.
The net result of this behavior is that all client applciations that want to consume the Config Server need a bootstrap.yml (or an environment variable) with the server address set in spring.cloud.config.uri (it defaults to "http://localhost:8888").
7.2 Discovery First Bootstrap
If you use a `DiscoveryClient implementation, such as Spring Cloud Netflix and Eureka Service Discovery or Spring Cloud Consul, you can have the Config Server register with the Discovery Service.
-However, in the default “Config First” mode, clients cannot take advantage of the registration.
If you prefer to use DiscoveryClient to locate the Config Server, you can do so by setting spring.cloud.config.discovery.enabled=true (the default is false).
+However, in the default “Config First” mode, clients cannot take advantage of the registration.
If you prefer to use DiscoveryClient to locate the Config Server, you can do so by setting spring.cloud.config.discovery.enabled=true (the default is false).
 The net result of doing so is that client applications all need a bootstrap.yml (or an environment variable) with the appropriate discovery configuration.
 For example, with Spring Cloud Netflix, you need to define the Eureka server address (for example, in eureka.client.serviceUrl.defaultZone).
 The price for using this option is an extra network round trip on startup, to locate the service registration.
diff --git a/multi/multi__spring_cloud_config_server.html b/multi/multi__spring_cloud_config_server.html
index e9b15ce7..ce7a9bd8 100644
--- a/multi/multi__spring_cloud_config_server.html
+++ b/multi/multi__spring_cloud_config_server.html
@@ -1,6 +1,6 @@
 
       
-   2. Spring Cloud Config Server
2. Spring Cloud Config Server
Prev   Next
2. Spring Cloud Config Server
Spring Cloud Config Server provides an HTTP resource-based API for external configuration (name-value pairs or equivalent YAML content).
+   2. Spring Cloud Config Server
2. Spring Cloud Config Server
Prev   Next
2. Spring Cloud Config Server
Spring Cloud Config Server provides an HTTP resource-based API for external configuration (name-value pairs or equivalent YAML content).
 The server is embeddable in a Spring Boot application, by using the @EnableConfigServer annotation.
 Consequently, the following application is a config server:
ConfigServer.java. 
 
@SpringBootApplication
@@ -60,12 +60,12 @@ If you use a command-line client such as curl, be careful with the brackets in t
         git:
           uri: https://example.com/my/repo
           timeout: 4
Placeholders in Git URI
Spring Cloud Config Server supports a git repository URL with placeholders for the {application} and {profile} (and {label} if you need it, but remember that the label is applied as a git label anyway).
-So you can support a “one repository per application” policy by using a structure similar to the following:
spring:
+So you can support a “one repository per application” policy by using a structure similar to the following:
spring:
   cloud:
     config:
       server:
         git:
-          uri: https://github.com/myorg/{application}
You can also support a “one repository per profile” policy by using a similar pattern but with
+          uri: https://github.com/myorg/{application}
You can also support a “one repository per profile” policy by using a similar pattern but with
 {profile}.
Additionally, using the special string "(_)" within your {application} parameters can enable support for multiple
 organizations, as shown in the following example:
spring:
   cloud:
@@ -88,7 +88,7 @@ The pattern format is a comma-separated list of {applicati
             local:
               pattern: local*
               uri: file:/home/configsvc/config-repo
If {application}/{profile} does not match any of the patterns, it uses the default URI defined under spring.cloud.config.server.git.uri.
-In the above example, for the “simple” repository, the pattern is simple/* (it only matches one application named simple in all profiles). The “local” repository matches all application names beginning with local in all profiles (the /* suffix is added automatically to any pattern that does not have a profile matcher).
[Note]Note
The “one-liner” short cut used in the “simple” example can be used only if the only property to be set is the URI.
+In the above example, for the “simple” repository, the pattern is simple/* (it only matches one application named simple in all profiles). The “local” repository matches all application names beginning with local in all profiles (the /* suffix is added automatically to any pattern that does not have a profile matcher).
[Note]Note
The “one-liner” short cut used in the “simple” example can be used only if the only property to be set is the URI.
 If you need to set anything else (credentials, pattern, and so on) you need to use the full form.
The pattern property in the repo is actually an array, so you can use a YAML array (or [0], [1], etc. suffixes in properties files) to bind to multiple patterns.
 You may need to do so if you are going to run apps with multiple profiles, as shown in the following example:
spring:
   cloud:
@@ -107,7 +107,7 @@ You may need to do so if you are going to run apps with multiple profiles, as sh
                 - '*/qa'
                 - '*/production'
               uri: https://github.com/staging/config-repo
[Note]Note
Spring Cloud guesses that a pattern containing a profile that does not end in * implies that you actually want to match a list of profiles starting with this pattern (so */staging is a shortcut for ["*/staging", "*/staging,*"], and so on).
-This is common where, for instance, you need to run applications in the “development” profile locally but also the “cloud” profile remotely.
Every repository can also optionally store config files in sub-directories, and patterns to search for those directories can be specified as searchPaths.
+This is common where, for instance, you need to run applications in the “development” profile locally but also the “cloud” profile remotely.
Every repository can also optionally store config files in sub-directories, and patterns to search for those directories can be specified as searchPaths.
 The following example shows a config file at the top level:
spring:
   cloud:
     config:
@@ -195,7 +195,7 @@ In order to activate property-based SSH configuration, the 69pcVH/4rmLbXdcmNYGm6iu+MlPQk4BUZknHSmVHIFdJ0EPupVaQ8RHT
-                         -----END RSA PRIVATE KEY-----
The following table describes the SSH configuration properties.
Table 2.1. SSH Configuration Properties
Property NameRemarks
ignoreLocalSshSettings
If true, use property-based instead of file-based SSH config. Must be set at as spring.cloud.config.server.git.ignoreLocalSshSettings, not inside a repository definition.
privateKey
Valid SSH private key. Must be set if ignoreLocalSshSettings is true and Git URI is SSH format.
hostKey
Valid SSH host key. Must be set if hostKeyAlgorithm is also set.
hostKeyAlgorithm
One of ssh-dss, ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, or ecdsa-sha2-nistp521. Must be set if hostKey is also set.
strictHostKeyChecking
true or false. If false, ignore errors with host key.
knownHostsFile
Location of custom .known_hosts file.
preferredAuthentications
Override server authentication method order. This should allow for evading login prompts if server has keyboard-interactive authentication before the publickey method.

Placeholders in Git Search Paths
Spring Cloud Config Server also supports a search path with placeholders for the {application} and {profile} (and {label} if
+                         -----END RSA PRIVATE KEY-----
The following table describes the SSH configuration properties.
Table 2.1. SSH Configuration Properties
Property NameRemarks
ignoreLocalSshSettings
If true, use property-based instead of file-based SSH config. Must be set at as spring.cloud.config.server.git.ignoreLocalSshSettings, not inside a repository definition.
privateKey
Valid SSH private key. Must be set if ignoreLocalSshSettings is true and Git URI is SSH format.
hostKey
Valid SSH host key. Must be set if hostKeyAlgorithm is also set.
hostKeyAlgorithm
One of ssh-dss, ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, or ecdsa-sha2-nistp521. Must be set if hostKey is also set.
strictHostKeyChecking
true or false. If false, ignore errors with host key.
knownHostsFile
Location of custom .known_hosts file.
preferredAuthentications
Override server authentication method order. This should allow for evading login prompts if server has keyboard-interactive authentication before the publickey method.

Placeholders in Git Search Paths
Spring Cloud Config Server also supports a search path with placeholders for the {application} and {profile} (and {label} if
 you need it), as shown in the following example:
spring:
   cloud:
     config:
@@ -246,7 +246,7 @@ By default, they are put in the system temporary directory with a prefix of /tmp/config-repo-<randomid>.
 Some operating systems routinely clean out temporary directories.
 This can lead to unexpected behavior, such as missing properties.
-To avoid this problem, change the directory that Config Server uses by setting spring.cloud.config.server.git.basedir or spring.cloud.config.server.svn.basedir to a directory that does not reside in the system temp structure.
2.1.3 File System Backend
There is also a “native” profile in the Config Server that does not use Git but loads the config files from the local classpath or file system (any static URL you want to point to with spring.cloud.config.server.native.searchLocations).
+To avoid this problem, change the directory that Config Server uses by setting spring.cloud.config.server.git.basedir or spring.cloud.config.server.svn.basedir to a directory that does not reside in the system temp structure.
2.1.3 File System Backend
There is also a “native” profile in the Config Server that does not use Git but loads the config files from the local classpath or file system (any static URL you want to point to with spring.cloud.config.server.native.searchLocations).
 To use the native profile, launch the Config Server with spring.profiles.active=native.
[Note]Note
Remember to use the file: prefix for file resources (the default without a prefix is usually the classpath).
 As with any Spring Boot configuration, you can embed ${}-style environment placeholders, but remember that absolute paths in Windows require an extra / (for example, file:///${user.home}/config-repo).
[Warning]Warning
The default value of the searchLocations is identical to a local Spring Boot application (that is, [classpath:/, classpath:/config,
 file:./, file:./config]).
@@ -255,12 +255,12 @@ To use it in production, you need to be sure that the file system is reliable an
 In this way, you can segregate the directories in the path and choose a strategy that makes sense for you (such as subdirectory per application or subdirectory per profile).
If you do not use placeholders in the search locations, this repository also appends the {label} parameter of the HTTP resource to a suffix on the search path, so properties files are loaded from each search location and a subdirectory with the same name as the label (the labelled properties take precedence in the Spring Environment).
 Thus, the default behaviour with no placeholders is the same as adding a search location ending with /{label}/.
 For example, file:/tmp/config is the same as file:/tmp/config,file:/tmp/config/{label}.
-This behavior can be disabled by setting spring.cloud.config.server.native.addLabelLocations=false.
2.1.4 Vault Backend
Spring Cloud Config Server also supports Vault as a backend.
Vault is a tool for securely accessing secrets.
+This behavior can be disabled by setting spring.cloud.config.server.native.addLabelLocations=false.
2.1.4 Vault Backend
Spring Cloud Config Server also supports Vault as a backend.
Vault is a tool for securely accessing secrets.
 A secret is anything that to which you want to tightly control access, such as API keys, passwords, certificates, and other sensitive information. Vault provides a unified interface to any secret while providing tight access control and recording a detailed audit log.
For more information on Vault, see the Vault quick start guide.
To enable the config server to use a Vault backend, you can run your config server with the vault profile.
 For example, in your config server’s application.properties, you can add spring.profiles.active=vault.
By default, the config server assumes that your Vault server runs at http://127.0.0.1:8200.
 It also assumes that the name of backend is secret and the key is application.
 All of these defaults can be configured in your config server’s application.properties.
-The following table describes configurable Vault properties:
NameDefault Value
host
127.0.0.1
port
8200
scheme
http
backend
secret
defaultKey
application
profileSeparator
,
kvVersion
1
skipSslValidation
false
timeout
5
[Important]Important
All of the properties in the preceding table must be prefixed with spring.cloud.config.server.vault.
All configurable properties can be found in org.springframework.cloud.config.server.environment.VaultEnvironmentRepository.
Vault 0.10.0 introduced a versioned key-value backend (k/v backend version 2) that exposes a different API than earlier versions, it now requires a data/ between the mount path and the actual context path and wraps secrets in a data object. Setting kvVersion=2 will take this into account.
With your config server running, you can make HTTP requests to the server to retrieve
+The following table describes configurable Vault properties:
NameDefault Value
host
127.0.0.1
port
8200
scheme
http
backend
secret
defaultKey
application
profileSeparator
,
kvVersion
1
skipSslValidation
false
timeout
5
[Important]Important
All of the properties in the preceding table must be prefixed with spring.cloud.config.server.vault.
All configurable properties can be found in org.springframework.cloud.config.server.environment.VaultEnvironmentRepository.
Vault 0.10.0 introduced a versioned key-value backend (k/v backend version 2) that exposes a different API than earlier versions, it now requires a data/ between the mount path and the actual context path and wraps secrets in a data object. Setting kvVersion=2 will take this into account.
With your config server running, you can make HTTP requests to the server to retrieve
 values from the Vault backend.
 To do so, you need a token for your Vault server.
First, place some data in you Vault, as shown in the following example:
$ vault write secret/application foo=bar baz=bam
 $ vault write secret/myapp foo=myappsbar
Second, make an HTTP request to your config server to retrieve the values, as shown in the following example:
$ curl -X "GET" "http://localhost:8888/myapp/default" -H "X-Config-Token: yourtoken"
You should see a response similar to the following:
{
@@ -292,7 +292,7 @@ secret/myApp
 secret/application,dev
 secret/application
Properties written to secret/application are available to all applications using the Config Server.
 An application with the name, myApp, would have any properties written to secret/myApp and secret/application available to it.
-When myApp has the dev profile enabled, properties written to all of the above paths would be available to it, with properties in the first path in the list taking priority over the others.
2.1.5 Accessing Backends Through a Proxy
The configuration server can access a Git or Vault backend through an HTTP or HTTPS proxy. This behavior is controlled for either Git or Vault by settings under proxy.http and proxy.https. These settings are per repository, so if you are using a composite environment repository you must configure proxy settings for each backend in the composite individually. If using a network which requires separate proxy servers for HTTP and HTTPS URLs, you can configure both the HTTP and the HTTPS proxy settings for a single backend.
The following table describes the proxy configuration properties for both HTTP and HTTPS proxies. All of these properties must be prefixed by proxy.http or proxy.https.
Table 2.2. Proxy Configuration Properties
Property NameRemarks
host
The host of the proxy.
port
The port with which to access the proxy.
nonProxyHosts
Any hosts which the configuration server should access outside the proxy. If values are provided for both proxy.http.nonProxyHosts and proxy.https.nonProxyHosts, the proxy.http value will be used.
username
The username with which to authenticate to the proxy. If values are provided for both proxy.http.username and proxy.https.username, the proxy.http value will be used.
password
The password with which to authenticate to the proxy. If values are provided for both proxy.http.password and proxy.https.password, the proxy.http value will be used.

The following configuration uses an HTTPS proxy to access a Git repository.
spring:
+When myApp has the dev profile enabled, properties written to all of the above paths would be available to it, with properties in the first path in the list taking priority over the others.
2.1.5 Accessing Backends Through a Proxy
The configuration server can access a Git or Vault backend through an HTTP or HTTPS proxy. This behavior is controlled for either Git or Vault by settings under proxy.http and proxy.https. These settings are per repository, so if you are using a composite environment repository you must configure proxy settings for each backend in the composite individually. If using a network which requires separate proxy servers for HTTP and HTTPS URLs, you can configure both the HTTP and the HTTPS proxy settings for a single backend.
The following table describes the proxy configuration properties for both HTTP and HTTPS proxies. All of these properties must be prefixed by proxy.http or proxy.https.
Table 2.2. Proxy Configuration Properties
Property NameRemarks
host
The host of the proxy.
port
The port with which to access the proxy.
nonProxyHosts
Any hosts which the configuration server should access outside the proxy. If values are provided for both proxy.http.nonProxyHosts and proxy.https.nonProxyHosts, the proxy.http value will be used.
username
The username with which to authenticate to the proxy. If values are provided for both proxy.http.username and proxy.https.username, the proxy.http value will be used.
password
The password with which to authenticate to the proxy. If values are provided for both proxy.http.password and proxy.https.password, the proxy.http value will be used.

The following configuration uses an HTTPS proxy to access a Git repository.
spring:
   profiles:
     active: git
   cloud:
@@ -308,7 +308,7 @@ When myApp has the dev
               username: myproxyusername
               nonProxyHosts: example.com
2.1.6 Sharing Configuration With All Applications
Sharing configuration between all applications varies according to which approach you take, as described in the following topics:
File Based Repositories
With file-based (git, svn, and native) repositories, resources with file names in application* (application.properties, application.yml, application-*.properties, and so on) are shared between all client applications.
 You can use resources with these file names to configure global defaults and have them be overridden by application-specific files as necessary.
The #_property_overrides[property overrides] feature can also be used for setting global defaults, with placeholders applications
-allowed to override them locally.
[Tip]Tip
With the “native” profile (a local file system backend) , you should use an explicit search location that is not part of the server’s own configuration.
+allowed to override them locally.
[Tip]Tip
With the “native” profile (a local file system backend) , you should use an explicit search location that is not part of the server’s own configuration.
 Otherwise, the application* resources in the default search locations get removed because they are part of the server.
Vault Server
When using Vault as a backend, you can share configuration with all applications by placing configuration in secret/application.
 For example, if you run the following Vault command, all applications using the config server will have the properties foo and baz available to them:
$ vault write secret/application foo=bar baz=bam
2.1.7 JDBC Backend
Spring Cloud Config Server supports JDBC (relational database) as a backend for configuration properties.
 You can enable this feature by adding spring-jdbc to the classpath and using the jdbc profile or by adding a bean of type JdbcEnvironmentRepository.
@@ -353,7 +353,7 @@ The priority order of a repository helps resolve any potential conflicts between
 If you have an environment similar to those in the preceding examples and you request configuration data with the master label but the Subversion repository does not contain a branch called master, the entire request fails.
Custom Composite Environment Repositories
In addition to using one of the environment repositories from Spring Cloud, you can also provide your own EnvironmentRepository bean to be included as part of a composite environment.
 To do so, your bean must implement the EnvironmentRepository interface.
 If you want to control the priority of your custom EnvironmentRepository within the composite environment, you should also implement the Ordered interface and override the getOrdered method.
-If you do not implement the Ordered interface, your EnvironmentRepository is given the lowest priority.
2.1.9 Property Overrides
The Config Server has an “overrides” feature that lets the operator provide configuration properties to all applications.
+If you do not implement the Ordered interface, your EnvironmentRepository is given the lowest priority.
2.1.9 Property Overrides
The Config Server has an “overrides” feature that lets the operator provide configuration properties to all applications.
 The overridden properties cannot be accidentally changed by the application with the normal Spring Boot hooks.
 To declare overrides, add a map of name-value pairs to spring.cloud.config.server.overrides, as shown in the following example:
spring:
   cloud:
@@ -377,9 +377,9 @@ By default, it asks the EnvironmentRepository for a
               name: myservice
               profiles: development
You can disable the Health Indicator by setting spring.cloud.config.server.health.enabled=false.
2.3 Security
You can secure your Config Server in any way that makes sense to you (from physical network security to OAuth2 bearer tokens), because Spring Security and Spring Boot offer support for many security arrangements.
To use the default Spring Boot-configured HTTP Basic security, include Spring Security on the classpath (for example, through spring-boot-starter-security).
 The default is a username of user and a randomly generated password. A random password is not useful in practice, so we recommend you configure the password (by setting spring.security.user.password) and encrypt it (see below for instructions on how to do that).
2.4 Encryption and Decryption
[Important]Important
To use the encryption and decryption features you need the full-strength JCE installed in your JVM (it is not included by default).
-You can download the “Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files” from Oracle and follow the installation instructions (essentially, you need to replace the two policy files in the JRE lib/security directory with the ones that you downloaded).
If the remote property sources contain encrypted content (values starting with {cipher}), they are decrypted before sending to clients over HTTP.
-The main advantage of this setup is that the property values need not be in plain text when they are “at rest” (for example, in a git repository).
-If a value cannot be decrypted, it is removed from the property source and an additional property is added with the same key but prefixed with invalid and a value that means “not applicable” (usually <n/a>).
+You can download the “Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files” from Oracle and follow the installation instructions (essentially, you need to replace the two policy files in the JRE lib/security directory with the ones that you downloaded).
If the remote property sources contain encrypted content (values starting with {cipher}), they are decrypted before sending to clients over HTTP.
+The main advantage of this setup is that the property values need not be in plain text when they are “at rest” (for example, in a git repository).
+If a value cannot be decrypted, it is removed from the property source and an additional property is added with the same key but prefixed with invalid and a value that means “not applicable” (usually <n/a>).
 This is largely to prevent cipher text being used as a password and accidentally leaking.
If you set up a remote config repository for config client applications, it might contain an application.yml similar to the following:
application.yml. 
 
spring:
   datasource:
@@ -402,7 +402,7 @@ mysecret
To use a key in a file (such as an RSA public key for encryptio
 the key value with "@" and provide the file path, as shown in the following example:
$ spring encrypt mysecret --key @${HOME}/.ssh/id_rsa.pub
 AQAjPgt3eFZQXwt8tsHAVv/QHiY5sI2dRcR+...
[Note]Note
The --key argument is mandatory (despite having a -- prefix).
2.5 Key Management
The Config Server can use a symmetric (shared) key or an asymmetric one (RSA key pair).
 The asymmetric choice is superior in terms of security, but it is often more convenient to use a symmetric key since it is a single property value to configure in the bootstrap.properties.
To configure a symmetric key, you need to set encrypt.key to a secret String (or use the ENCRYPT_KEY environment variable to keep it out of plain-text configuration files).
To configure an asymmetric key, you can either set the key as a PEM-encoded text value (in encrypt.key) or use a keystore (such as the keystore created by the keytool utility that comes with the JDK).
-The following table describes the keystore properties:
PropertyDescription
encrypt.keyStore.location
Contains a Resource location
encrypt.keyStore.password
Holds the password that unlocks the keystore
encrypt.keyStore.alias
Identifies which key in the store to use
The encryption is done with the public key, and a private key is
+The following table describes the keystore properties:
PropertyDescription
encrypt.keyStore.location
Contains a Resource location
encrypt.keyStore.password
Holds the password that unlocks the keystore
encrypt.keyStore.alias
Identifies which key in the store to use
The encryption is done with the public key, and a private key is
 needed for decryption.
 Thus, in principle, you can configure only the public key in the server if you want to only encrypt (and are prepared to decrypt the values yourself locally with the private key).
 In practice, you might not want to do decrypt locally, because it spreads the key management process around all the clients, instead of
diff --git a/multi/multi_pr01.html b/multi/multi_pr01.html
index e8b650b3..431f0206 100644
--- a/multi/multi_pr01.html
+++ b/multi/multi_pr01.html
@@ -1,6 +1,6 @@
 
       
-   
Prev   Next
2.1.0.BUILD-SNAPSHOT
Spring Cloud Config provides server-side and client-side support for externalized configuration in a distributed system. With the Config Server, you have a central place to manage external properties for applications across all environments.
+   
Prev   Next
2.1.0.BUILD-SNAPSHOT
Spring Cloud Config provides server-side and client-side support for externalized configuration in a distributed system. With the Config Server, you have a central place to manage external properties for applications across all environments.
 The concepts on both client and server map identically to the Spring Environment and PropertySource abstractions, so they fit very well with Spring applications but can be used with any application running in any language.
 As an application moves through the deployment pipeline from dev to test and into production, you can manage the configuration between those environments and be certain that applications have everything they need to run when they migrate.
 The default implementation of the server storage backend uses git, so it easily supports labelled versions of configuration environments as well as being accessible to a wide range of tooling for managing the content.
diff --git a/multi/multi_spring-cloud-config.html b/multi/multi_spring-cloud-config.html
index 290fd3c5..ec1257db 100644
--- a/multi/multi_spring-cloud-config.html
+++ b/multi/multi_spring-cloud-config.html
@@ -1,3 +1,3 @@
 
       
-   Spring Cloud Config
Spring Cloud Config
   Next
Spring Cloud Config
Table of Contents
1. Quick Start
1.1. Client Side Usage
2. Spring Cloud Config Server
2.1. Environment Repository
2.1.1. Git Backend
Skipping SSL Certificate Validation
Setting HTTP Connection Timeout
Placeholders in Git URI
Pattern Matching and Multiple Repositories
Authentication
Authentication with AWS CodeCommit
Git SSH configuration using properties
Placeholders in Git Search Paths
Force pull in Git Repositories
Deleting untracked branches in Git Repositories
2.1.2. Version Control Backend Filesystem Use
2.1.3. File System Backend
2.1.4. Vault Backend
Multiple Properties Sources
2.1.5. Accessing Backends Through a Proxy
2.1.6. Sharing Configuration With All Applications
File Based Repositories
Vault Server
2.1.7. JDBC Backend
2.1.8. Composite Environment Repositories
Custom Composite Environment Repositories
2.1.9. Property Overrides
2.2. Health Indicator
2.3. Security
2.4. Encryption and Decryption
2.5. Key Management
2.6. Creating a Key Store for Testing
2.7. Using Multiple Keys and Key Rotation
2.8. Serving Encrypted Properties
3. Serving Alternative Formats
4. Serving Plain Text
5. Embedding the Config Server
6. Push Notifications and Spring Cloud Bus
7. Spring Cloud Config Client
7.1. Config First Bootstrap
7.2. Discovery First Bootstrap
7.3. Config Client Fail Fast
7.4. Config Client Retry
7.5. Locating Remote Configuration Resources
7.6. Specifying Multiple Urls for the Config Server
7.7. Configuring Read Timeouts
7.8. Security
7.8.1. Health Indicator
7.8.2. Providing A Custom RestTemplate
7.8.3. Vault
7.9. Nested Keys In Vault
   Next
   

\ No newline at end of file
+   Spring Cloud Config
Spring Cloud Config
   Next
Spring Cloud Config
Table of Contents
1. Quick Start
1.1. Client Side Usage
2. Spring Cloud Config Server
2.1. Environment Repository
2.1.1. Git Backend
Skipping SSL Certificate Validation
Setting HTTP Connection Timeout
Placeholders in Git URI
Pattern Matching and Multiple Repositories
Authentication
Authentication with AWS CodeCommit
Git SSH configuration using properties
Placeholders in Git Search Paths
Force pull in Git Repositories
Deleting untracked branches in Git Repositories
2.1.2. Version Control Backend Filesystem Use
2.1.3. File System Backend
2.1.4. Vault Backend
Multiple Properties Sources
2.1.5. Accessing Backends Through a Proxy
2.1.6. Sharing Configuration With All Applications
File Based Repositories
Vault Server
2.1.7. JDBC Backend
2.1.8. Composite Environment Repositories
Custom Composite Environment Repositories
2.1.9. Property Overrides
2.2. Health Indicator
2.3. Security
2.4. Encryption and Decryption
2.5. Key Management
2.6. Creating a Key Store for Testing
2.7. Using Multiple Keys and Key Rotation
2.8. Serving Encrypted Properties
3. Serving Alternative Formats
4. Serving Plain Text
5. Embedding the Config Server
6. Push Notifications and Spring Cloud Bus
7. Spring Cloud Config Client
7.1. Config First Bootstrap
7.2. Discovery First Bootstrap
7.3. Config Client Fail Fast
7.4. Config Client Retry
7.5. Locating Remote Configuration Resources
7.6. Specifying Multiple Urls for the Config Server
7.7. Configuring Read Timeouts
7.8. Security
7.8.1. Health Indicator
7.8.2. Providing A Custom RestTemplate
7.8.3. Vault
7.9. Nested Keys In Vault
   Next
   

\ No newline at end of file
diff --git a/single/spring-cloud-config.html b/single/spring-cloud-config.html
index 6785d9d8..680a5143 100644
--- a/single/spring-cloud-config.html
+++ b/single/spring-cloud-config.html
@@ -1,6 +1,6 @@
 
       
-   Spring Cloud Config
Spring Cloud Config
Table of Contents
1. Quick Start
1.1. Client Side Usage
2. Spring Cloud Config Server
2.1. Environment Repository
2.1.1. Git Backend
Skipping SSL Certificate Validation
Setting HTTP Connection Timeout
Placeholders in Git URI
Pattern Matching and Multiple Repositories
Authentication
Authentication with AWS CodeCommit
Git SSH configuration using properties
Placeholders in Git Search Paths
Force pull in Git Repositories
Deleting untracked branches in Git Repositories
2.1.2. Version Control Backend Filesystem Use
2.1.3. File System Backend
2.1.4. Vault Backend
Multiple Properties Sources
2.1.5. Accessing Backends Through a Proxy
2.1.6. Sharing Configuration With All Applications
File Based Repositories
Vault Server
2.1.7. JDBC Backend
2.1.8. Composite Environment Repositories
Custom Composite Environment Repositories
2.1.9. Property Overrides
2.2. Health Indicator
2.3. Security
2.4. Encryption and Decryption
2.5. Key Management
2.6. Creating a Key Store for Testing
2.7. Using Multiple Keys and Key Rotation
2.8. Serving Encrypted Properties
3. Serving Alternative Formats
4. Serving Plain Text
5. Embedding the Config Server
6. Push Notifications and Spring Cloud Bus
7. Spring Cloud Config Client
7.1. Config First Bootstrap
7.2. Discovery First Bootstrap
7.3. Config Client Fail Fast
7.4. Config Client Retry
7.5. Locating Remote Configuration Resources
7.6. Specifying Multiple Urls for the Config Server
7.7. Configuring Read Timeouts
7.8. Security
7.8.1. Health Indicator
7.8.2. Providing A Custom RestTemplate
7.8.3. Vault
7.9. Nested Keys In Vault
2.1.0.BUILD-SNAPSHOT
Spring Cloud Config provides server-side and client-side support for externalized configuration in a distributed system. With the Config Server, you have a central place to manage external properties for applications across all environments.
+   Spring Cloud Config
Spring Cloud Config
Table of Contents
1. Quick Start
1.1. Client Side Usage
2. Spring Cloud Config Server
2.1. Environment Repository
2.1.1. Git Backend
Skipping SSL Certificate Validation
Setting HTTP Connection Timeout
Placeholders in Git URI
Pattern Matching and Multiple Repositories
Authentication
Authentication with AWS CodeCommit
Git SSH configuration using properties
Placeholders in Git Search Paths
Force pull in Git Repositories
Deleting untracked branches in Git Repositories
2.1.2. Version Control Backend Filesystem Use
2.1.3. File System Backend
2.1.4. Vault Backend
Multiple Properties Sources
2.1.5. Accessing Backends Through a Proxy
2.1.6. Sharing Configuration With All Applications
File Based Repositories
Vault Server
2.1.7. JDBC Backend
2.1.8. Composite Environment Repositories
Custom Composite Environment Repositories
2.1.9. Property Overrides
2.2. Health Indicator
2.3. Security
2.4. Encryption and Decryption
2.5. Key Management
2.6. Creating a Key Store for Testing
2.7. Using Multiple Keys and Key Rotation
2.8. Serving Encrypted Properties
3. Serving Alternative Formats
4. Serving Plain Text
5. Embedding the Config Server
6. Push Notifications and Spring Cloud Bus
7. Spring Cloud Config Client
7.1. Config First Bootstrap
7.2. Discovery First Bootstrap
7.3. Config Client Fail Fast
7.4. Config Client Retry
7.5. Locating Remote Configuration Resources
7.6. Specifying Multiple Urls for the Config Server
7.7. Configuring Read Timeouts
7.8. Security
7.8.1. Health Indicator
7.8.2. Providing A Custom RestTemplate
7.8.3. Vault
7.9. Nested Keys In Vault
2.1.0.BUILD-SNAPSHOT
Spring Cloud Config provides server-side and client-side support for externalized configuration in a distributed system. With the Config Server, you have a central place to manage external properties for applications across all environments.
 The concepts on both client and server map identically to the Spring Environment and PropertySource abstractions, so they fit very well with Spring applications but can be used with any application running in any language.
 As an application moves through the deployment pipeline from dev to test and into production, you can manage the configuration between those environments and be certain that applications have everything they need to run when they migrate.
 The default implementation of the server storage backend uses git, so it easily supports labelled versions of configuration environments as well as being accessible to a wide range of tooling for managing the content.
@@ -144,12 +144,12 @@ If you use a command-line client such as curl, be careful with the brackets in t
         git:
           uri: https://example.com/my/repo
           timeout: 4
Placeholders in Git URI
Spring Cloud Config Server supports a git repository URL with placeholders for the {application} and {profile} (and {label} if you need it, but remember that the label is applied as a git label anyway).
-So you can support a “one repository per application” policy by using a structure similar to the following:
spring:
+So you can support a “one repository per application” policy by using a structure similar to the following:
spring:
   cloud:
     config:
       server:
         git:
-          uri: https://github.com/myorg/{application}
You can also support a “one repository per profile” policy by using a similar pattern but with
+          uri: https://github.com/myorg/{application}
You can also support a “one repository per profile” policy by using a similar pattern but with
 {profile}.
Additionally, using the special string "(_)" within your {application} parameters can enable support for multiple
 organizations, as shown in the following example:
spring:
   cloud:
@@ -172,7 +172,7 @@ The pattern format is a comma-separated list of {applicati
             local:
               pattern: local*
               uri: file:/home/configsvc/config-repo
If {application}/{profile} does not match any of the patterns, it uses the default URI defined under spring.cloud.config.server.git.uri.
-In the above example, for the “simple” repository, the pattern is simple/* (it only matches one application named simple in all profiles). The “local” repository matches all application names beginning with local in all profiles (the /* suffix is added automatically to any pattern that does not have a profile matcher).
[Note]Note
The “one-liner” short cut used in the “simple” example can be used only if the only property to be set is the URI.
+In the above example, for the “simple” repository, the pattern is simple/* (it only matches one application named simple in all profiles). The “local” repository matches all application names beginning with local in all profiles (the /* suffix is added automatically to any pattern that does not have a profile matcher).
[Note]Note
The “one-liner” short cut used in the “simple” example can be used only if the only property to be set is the URI.
 If you need to set anything else (credentials, pattern, and so on) you need to use the full form.
The pattern property in the repo is actually an array, so you can use a YAML array (or [0], [1], etc. suffixes in properties files) to bind to multiple patterns.
 You may need to do so if you are going to run apps with multiple profiles, as shown in the following example:
spring:
   cloud:
@@ -191,7 +191,7 @@ You may need to do so if you are going to run apps with multiple profiles, as sh
                 - '*/qa'
                 - '*/production'
               uri: https://github.com/staging/config-repo
[Note]Note
Spring Cloud guesses that a pattern containing a profile that does not end in * implies that you actually want to match a list of profiles starting with this pattern (so */staging is a shortcut for ["*/staging", "*/staging,*"], and so on).
-This is common where, for instance, you need to run applications in the “development” profile locally but also the “cloud” profile remotely.
Every repository can also optionally store config files in sub-directories, and patterns to search for those directories can be specified as searchPaths.
+This is common where, for instance, you need to run applications in the “development” profile locally but also the “cloud” profile remotely.
Every repository can also optionally store config files in sub-directories, and patterns to search for those directories can be specified as searchPaths.
 The following example shows a config file at the top level:
spring:
   cloud:
     config:
@@ -279,7 +279,7 @@ In order to activate property-based SSH configuration, the 69pcVH/4rmLbXdcmNYGm6iu+MlPQk4BUZknHSmVHIFdJ0EPupVaQ8RHT
-                         -----END RSA PRIVATE KEY-----
The following table describes the SSH configuration properties.
Table 2.1. SSH Configuration Properties
Property NameRemarks
ignoreLocalSshSettings
If true, use property-based instead of file-based SSH config. Must be set at as spring.cloud.config.server.git.ignoreLocalSshSettings, not inside a repository definition.
privateKey
Valid SSH private key. Must be set if ignoreLocalSshSettings is true and Git URI is SSH format.
hostKey
Valid SSH host key. Must be set if hostKeyAlgorithm is also set.
hostKeyAlgorithm
One of ssh-dss, ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, or ecdsa-sha2-nistp521. Must be set if hostKey is also set.
strictHostKeyChecking
true or false. If false, ignore errors with host key.
knownHostsFile
Location of custom .known_hosts file.
preferredAuthentications
Override server authentication method order. This should allow for evading login prompts if server has keyboard-interactive authentication before the publickey method.

Placeholders in Git Search Paths
Spring Cloud Config Server also supports a search path with placeholders for the {application} and {profile} (and {label} if
+                         -----END RSA PRIVATE KEY-----

The following table describes the SSH configuration properties.

Table 2.1. SSH Configuration Properties

Property NameRemarks

ignoreLocalSshSettings

If true, use property-based instead of file-based SSH config. Must be set at as spring.cloud.config.server.git.ignoreLocalSshSettings, not inside a repository definition.

privateKey

Valid SSH private key. Must be set if ignoreLocalSshSettings is true and Git URI is SSH format.

hostKey

Valid SSH host key. Must be set if hostKeyAlgorithm is also set.

hostKeyAlgorithm

One of ssh-dss, ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, or ecdsa-sha2-nistp521. Must be set if hostKey is also set.

strictHostKeyChecking

true or false. If false, ignore errors with host key.

knownHostsFile

Location of custom .known_hosts file.

preferredAuthentications

Override server authentication method order. This should allow for evading login prompts if server has keyboard-interactive authentication before the publickey method.


Placeholders in Git Search Paths

Spring Cloud Config Server also supports a search path with placeholders for the {application} and {profile} (and {label} if you need it), as shown in the following example:

spring:
   cloud:
     config:
@@ -330,7 +330,7 @@ By default, they are put in the system temporary directory with a prefix of /tmp/config-repo-<randomid>.
 Some operating systems routinely clean out temporary directories.
 This can lead to unexpected behavior, such as missing properties.
-To avoid this problem, change the directory that Config Server uses by setting spring.cloud.config.server.git.basedir or spring.cloud.config.server.svn.basedir to a directory that does not reside in the system temp structure.

2.1.3 File System Backend

There is also a “native” profile in the Config Server that does not use Git but loads the config files from the local classpath or file system (any static URL you want to point to with spring.cloud.config.server.native.searchLocations). +To avoid this problem, change the directory that Config Server uses by setting spring.cloud.config.server.git.basedir or spring.cloud.config.server.svn.basedir to a directory that does not reside in the system temp structure.

2.1.3 File System Backend

There is also a “native” profile in the Config Server that does not use Git but loads the config files from the local classpath or file system (any static URL you want to point to with spring.cloud.config.server.native.searchLocations). To use the native profile, launch the Config Server with spring.profiles.active=native.

[Note]Note

Remember to use the file: prefix for file resources (the default without a prefix is usually the classpath). As with any Spring Boot configuration, you can embed ${}-style environment placeholders, but remember that absolute paths in Windows require an extra / (for example, file:///${user.home}/config-repo).

[Warning]Warning

The default value of the searchLocations is identical to a local Spring Boot application (that is, [classpath:/, classpath:/config, file:./, file:./config]). @@ -339,12 +339,12 @@ To use it in production, you need to be sure that the file system is reliable an In this way, you can segregate the directories in the path and choose a strategy that makes sense for you (such as subdirectory per application or subdirectory per profile).

If you do not use placeholders in the search locations, this repository also appends the {label} parameter of the HTTP resource to a suffix on the search path, so properties files are loaded from each search location and a subdirectory with the same name as the label (the labelled properties take precedence in the Spring Environment). Thus, the default behaviour with no placeholders is the same as adding a search location ending with /{label}/. For example, file:/tmp/config is the same as file:/tmp/config,file:/tmp/config/{label}. -This behavior can be disabled by setting spring.cloud.config.server.native.addLabelLocations=false.

2.1.4 Vault Backend

Spring Cloud Config Server also supports Vault as a backend.

Vault is a tool for securely accessing secrets. +This behavior can be disabled by setting spring.cloud.config.server.native.addLabelLocations=false.

2.1.4 Vault Backend

Spring Cloud Config Server also supports Vault as a backend.

Vault is a tool for securely accessing secrets. A secret is anything that to which you want to tightly control access, such as API keys, passwords, certificates, and other sensitive information. Vault provides a unified interface to any secret while providing tight access control and recording a detailed audit log.

For more information on Vault, see the Vault quick start guide.

To enable the config server to use a Vault backend, you can run your config server with the vault profile. For example, in your config server’s application.properties, you can add spring.profiles.active=vault.

By default, the config server assumes that your Vault server runs at http://127.0.0.1:8200. It also assumes that the name of backend is secret and the key is application. All of these defaults can be configured in your config server’s application.properties. -The following table describes configurable Vault properties:

NameDefault Value

host

127.0.0.1

port

8200

scheme

http

backend

secret

defaultKey

application

profileSeparator

,

kvVersion

1

skipSslValidation

false

timeout

5

[Important]Important

All of the properties in the preceding table must be prefixed with spring.cloud.config.server.vault.

All configurable properties can be found in org.springframework.cloud.config.server.environment.VaultEnvironmentRepository.

Vault 0.10.0 introduced a versioned key-value backend (k/v backend version 2) that exposes a different API than earlier versions, it now requires a data/ between the mount path and the actual context path and wraps secrets in a data object. Setting kvVersion=2 will take this into account.

With your config server running, you can make HTTP requests to the server to retrieve +The following table describes configurable Vault properties:

NameDefault Value

host

127.0.0.1

port

8200

scheme

http

backend

secret

defaultKey

application

profileSeparator

,

kvVersion

1

skipSslValidation

false

timeout

5

[Important]Important

All of the properties in the preceding table must be prefixed with spring.cloud.config.server.vault.

All configurable properties can be found in org.springframework.cloud.config.server.environment.VaultEnvironmentRepository.

Vault 0.10.0 introduced a versioned key-value backend (k/v backend version 2) that exposes a different API than earlier versions, it now requires a data/ between the mount path and the actual context path and wraps secrets in a data object. Setting kvVersion=2 will take this into account.

With your config server running, you can make HTTP requests to the server to retrieve values from the Vault backend. To do so, you need a token for your Vault server.

First, place some data in you Vault, as shown in the following example:

$ vault write secret/application foo=bar baz=bam
 $ vault write secret/myapp foo=myappsbar

Second, make an HTTP request to your config server to retrieve the values, as shown in the following example:

$ curl -X "GET" "http://localhost:8888/myapp/default" -H "X-Config-Token: yourtoken"

You should see a response similar to the following:

{
@@ -376,7 +376,7 @@ secret/myApp
 secret/application,dev
 secret/application

Properties written to secret/application are available to all applications using the Config Server. An application with the name, myApp, would have any properties written to secret/myApp and secret/application available to it. -When myApp has the dev profile enabled, properties written to all of the above paths would be available to it, with properties in the first path in the list taking priority over the others.

2.1.5 Accessing Backends Through a Proxy

The configuration server can access a Git or Vault backend through an HTTP or HTTPS proxy. This behavior is controlled for either Git or Vault by settings under proxy.http and proxy.https. These settings are per repository, so if you are using a composite environment repository you must configure proxy settings for each backend in the composite individually. If using a network which requires separate proxy servers for HTTP and HTTPS URLs, you can configure both the HTTP and the HTTPS proxy settings for a single backend.

The following table describes the proxy configuration properties for both HTTP and HTTPS proxies. All of these properties must be prefixed by proxy.http or proxy.https.

Table 2.2. Proxy Configuration Properties

Property NameRemarks

host

The host of the proxy.

port

The port with which to access the proxy.

nonProxyHosts

Any hosts which the configuration server should access outside the proxy. If values are provided for both proxy.http.nonProxyHosts and proxy.https.nonProxyHosts, the proxy.http value will be used.

username

The username with which to authenticate to the proxy. If values are provided for both proxy.http.username and proxy.https.username, the proxy.http value will be used.

password

The password with which to authenticate to the proxy. If values are provided for both proxy.http.password and proxy.https.password, the proxy.http value will be used.


The following configuration uses an HTTPS proxy to access a Git repository.

spring:
+When myApp has the dev profile enabled, properties written to all of the above paths would be available to it, with properties in the first path in the list taking priority over the others.

2.1.5 Accessing Backends Through a Proxy

The configuration server can access a Git or Vault backend through an HTTP or HTTPS proxy. This behavior is controlled for either Git or Vault by settings under proxy.http and proxy.https. These settings are per repository, so if you are using a composite environment repository you must configure proxy settings for each backend in the composite individually. If using a network which requires separate proxy servers for HTTP and HTTPS URLs, you can configure both the HTTP and the HTTPS proxy settings for a single backend.

The following table describes the proxy configuration properties for both HTTP and HTTPS proxies. All of these properties must be prefixed by proxy.http or proxy.https.

Table 2.2. Proxy Configuration Properties

Property NameRemarks

host

The host of the proxy.

port

The port with which to access the proxy.

nonProxyHosts

Any hosts which the configuration server should access outside the proxy. If values are provided for both proxy.http.nonProxyHosts and proxy.https.nonProxyHosts, the proxy.http value will be used.

username

The username with which to authenticate to the proxy. If values are provided for both proxy.http.username and proxy.https.username, the proxy.http value will be used.

password

The password with which to authenticate to the proxy. If values are provided for both proxy.http.password and proxy.https.password, the proxy.http value will be used.


The following configuration uses an HTTPS proxy to access a Git repository.

spring:
   profiles:
     active: git
   cloud:
@@ -392,7 +392,7 @@ When myApp has the dev
               username: myproxyusername
               nonProxyHosts: example.com

2.1.6 Sharing Configuration With All Applications

Sharing configuration between all applications varies according to which approach you take, as described in the following topics:

File Based Repositories

With file-based (git, svn, and native) repositories, resources with file names in application* (application.properties, application.yml, application-*.properties, and so on) are shared between all client applications. You can use resources with these file names to configure global defaults and have them be overridden by application-specific files as necessary.

The #_property_overrides[property overrides] feature can also be used for setting global defaults, with placeholders applications -allowed to override them locally.

[Tip]Tip

With the “native” profile (a local file system backend) , you should use an explicit search location that is not part of the server’s own configuration. +allowed to override them locally.

[Tip]Tip

With the “native” profile (a local file system backend) , you should use an explicit search location that is not part of the server’s own configuration. Otherwise, the application* resources in the default search locations get removed because they are part of the server.

Vault Server

When using Vault as a backend, you can share configuration with all applications by placing configuration in secret/application. For example, if you run the following Vault command, all applications using the config server will have the properties foo and baz available to them:

$ vault write secret/application foo=bar baz=bam

2.1.7 JDBC Backend

Spring Cloud Config Server supports JDBC (relational database) as a backend for configuration properties. You can enable this feature by adding spring-jdbc to the classpath and using the jdbc profile or by adding a bean of type JdbcEnvironmentRepository. @@ -437,7 +437,7 @@ The priority order of a repository helps resolve any potential conflicts between If you have an environment similar to those in the preceding examples and you request configuration data with the master label but the Subversion repository does not contain a branch called master, the entire request fails.

Custom Composite Environment Repositories

In addition to using one of the environment repositories from Spring Cloud, you can also provide your own EnvironmentRepository bean to be included as part of a composite environment. To do so, your bean must implement the EnvironmentRepository interface. If you want to control the priority of your custom EnvironmentRepository within the composite environment, you should also implement the Ordered interface and override the getOrdered method. -If you do not implement the Ordered interface, your EnvironmentRepository is given the lowest priority.

2.1.9 Property Overrides

The Config Server has an “overrides” feature that lets the operator provide configuration properties to all applications. +If you do not implement the Ordered interface, your EnvironmentRepository is given the lowest priority.

2.1.9 Property Overrides

The Config Server has an “overrides” feature that lets the operator provide configuration properties to all applications. The overridden properties cannot be accidentally changed by the application with the normal Spring Boot hooks. To declare overrides, add a map of name-value pairs to spring.cloud.config.server.overrides, as shown in the following example:

spring:
   cloud:
@@ -461,9 +461,9 @@ By default, it asks the EnvironmentRepository for a
               name: myservice
               profiles: development

You can disable the Health Indicator by setting spring.cloud.config.server.health.enabled=false.

2.3 Security

You can secure your Config Server in any way that makes sense to you (from physical network security to OAuth2 bearer tokens), because Spring Security and Spring Boot offer support for many security arrangements.

To use the default Spring Boot-configured HTTP Basic security, include Spring Security on the classpath (for example, through spring-boot-starter-security). The default is a username of user and a randomly generated password. A random password is not useful in practice, so we recommend you configure the password (by setting spring.security.user.password) and encrypt it (see below for instructions on how to do that).

2.4 Encryption and Decryption

[Important]Important

To use the encryption and decryption features you need the full-strength JCE installed in your JVM (it is not included by default). -You can download the “Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files” from Oracle and follow the installation instructions (essentially, you need to replace the two policy files in the JRE lib/security directory with the ones that you downloaded).

If the remote property sources contain encrypted content (values starting with {cipher}), they are decrypted before sending to clients over HTTP. -The main advantage of this setup is that the property values need not be in plain text when they are “at rest” (for example, in a git repository). -If a value cannot be decrypted, it is removed from the property source and an additional property is added with the same key but prefixed with invalid and a value that means “not applicable” (usually <n/a>). +You can download the “Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files” from Oracle and follow the installation instructions (essentially, you need to replace the two policy files in the JRE lib/security directory with the ones that you downloaded).

If the remote property sources contain encrypted content (values starting with {cipher}), they are decrypted before sending to clients over HTTP. +The main advantage of this setup is that the property values need not be in plain text when they are “at rest” (for example, in a git repository). +If a value cannot be decrypted, it is removed from the property source and an additional property is added with the same key but prefixed with invalid and a value that means “not applicable” (usually <n/a>). This is largely to prevent cipher text being used as a password and accidentally leaking.

If you set up a remote config repository for config client applications, it might contain an application.yml similar to the following:

application.yml.  

spring:
   datasource:
@@ -486,7 +486,7 @@ mysecret

To use a key in a file (such as an RSA public key for encryptio the key value with "@" and provide the file path, as shown in the following example:

$ spring encrypt mysecret --key @${HOME}/.ssh/id_rsa.pub
 AQAjPgt3eFZQXwt8tsHAVv/QHiY5sI2dRcR+...
[Note]Note

The --key argument is mandatory (despite having a -- prefix).

2.5 Key Management

The Config Server can use a symmetric (shared) key or an asymmetric one (RSA key pair). The asymmetric choice is superior in terms of security, but it is often more convenient to use a symmetric key since it is a single property value to configure in the bootstrap.properties.

To configure a symmetric key, you need to set encrypt.key to a secret String (or use the ENCRYPT_KEY environment variable to keep it out of plain-text configuration files).

To configure an asymmetric key, you can either set the key as a PEM-encoded text value (in encrypt.key) or use a keystore (such as the keystore created by the keytool utility that comes with the JDK). -The following table describes the keystore properties:

PropertyDescription

encrypt.keyStore.location

Contains a Resource location

encrypt.keyStore.password

Holds the password that unlocks the keystore

encrypt.keyStore.alias

Identifies which key in the store to use

The encryption is done with the public key, and a private key is +The following table describes the keystore properties:

PropertyDescription

encrypt.keyStore.location

Contains a Resource location

encrypt.keyStore.password

Holds the password that unlocks the keystore

encrypt.keyStore.alias

Identifies which key in the store to use

The encryption is done with the public key, and a private key is needed for decryption. Thus, in principle, you can configure only the public key in the server if you want to only encrypt (and are prepared to decrypt the values yourself locally with the private key). In practice, you might not want to do decrypt locally, because it spreads the key management process around all the clients, instead of @@ -563,7 +563,7 @@ In addition to the JSON notifications from Github, Gitlab, Gitee, or Bitbucket, Doing so broadcasts to applications matching the {name} pattern (which can contain wildcards).

[Note]Note

The RefreshRemoteApplicationEvent is transmitted only if the spring-cloud-bus is activated in both the Config Server and in the client application.

[Note]Note

The default configuration also detects filesystem changes in local git repositories. In that case, the webhook is not used. However, as soon as you edit a config file, a refresh is broadcast.

7. Spring Cloud Config Client

A Spring Boot application can take immediate advantage of the Spring Config Server (or other external property sources provided by the application developer). It also picks up some additional useful features related to Environment change events.

7.1 Config First Bootstrap

The default behavior for any application that has the Spring Cloud Config Client on the classpath is as follows: When a config client starts, it binds to the Config Server (through the spring.cloud.config.uri bootstrap configuration property) and initializes Spring Environment with remote property sources.

The net result of this behavior is that all client applciations that want to consume the Config Server need a bootstrap.yml (or an environment variable) with the server address set in spring.cloud.config.uri (it defaults to "http://localhost:8888").

7.2 Discovery First Bootstrap

If you use a `DiscoveryClient implementation, such as Spring Cloud Netflix and Eureka Service Discovery or Spring Cloud Consul, you can have the Config Server register with the Discovery Service. -However, in the default “Config First” mode, clients cannot take advantage of the registration.

If you prefer to use DiscoveryClient to locate the Config Server, you can do so by setting spring.cloud.config.discovery.enabled=true (the default is false). +However, in the default “Config First” mode, clients cannot take advantage of the registration.

If you prefer to use DiscoveryClient to locate the Config Server, you can do so by setting spring.cloud.config.discovery.enabled=true (the default is false). The net result of doing so is that client applications all need a bootstrap.yml (or an environment variable) with the appropriate discovery configuration. For example, with Spring Cloud Netflix, you need to define the Eureka server address (for example, in eureka.client.serviceUrl.defaultZone). The price for using this option is an extra network round trip on startup, to locate the service registration. diff --git a/spring-cloud-config.html b/spring-cloud-config.html index 4055a60e..452f8d3f 100644 --- a/spring-cloud-config.html +++ b/spring-cloud-config.html @@ -4,7 +4,7 @@ - + spring-cloud-config