diff --git a/multi/multi__quick_start.html b/multi/multi__quick_start.html
index 87429e57..feff802e 100644
--- a/multi/multi__quick_start.html
+++ b/multi/multi__quick_start.html
@@ -10,12 +10,12 @@ The mini-application’s Environment is used to
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
-/{label}/{application}-{profile}.propertieswhere application is injected as the spring.config.name in the SpringApplication (what is normally application in a regular Spring Boot app), profile is an active profile (or comma-separated list of properties), and label is an optional git label (defaults to master.)
Spring Cloud Config Server pulls configuration for remote clients from a git repository (which must be provided), as shown in the following example:
spring:
+/{label}/{application}-{profile}.propertieswhere application is injected as the spring.config.name in the SpringApplication (what is normally application in a regular Spring Boot app), profile is an active profile (or comma-separated list of properties), and label is an optional git label (defaults to master.)
Spring Cloud Config Server pulls configuration for remote clients from various sources. The following example gets configuration from a git repository (which must be provided), as shown in the following example:
spring:
cloud:
config:
server:
git:
- uri: https://github.com/spring-cloud-samples/config-repoTo use these features in an application, you can build it as a Spring Boot application that depends on spring-cloud-config-client (for an example, see the test cases for the config-client or the sample application).
+ uri: https://github.com/spring-cloud-samples/config-repo
Other sources are any JDBC compatible database, Subversion, Hashicorp Vault, Credhub and local filesystems.
To use these features in an application, you can build it as a Spring Boot application that depends on spring-cloud-config-client (for an example, see the test cases for the config-client or the sample application).
The most convenient way to add the dependency is with a Spring Boot starter org.springframework.cloud:spring-cloud-starter-config.
There is also a parent pom and BOM (spring-cloud-starter-parent) for Maven users and a Spring IO version management properties file for Gradle and Spring CLI users. The following example shows a typical Maven configuration:
pom.xml.
<parent>
diff --git a/multi/multi__spring_cloud_config_server.html b/multi/multi__spring_cloud_config_server.html
index e35dd47d..f127be37 100644
--- a/multi/multi__spring_cloud_config_server.html
+++ b/multi/multi__spring_cloud_config_server.html
@@ -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 Name | Remarks |
|---|
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 Name | Remarks |
|---|
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:
@@ -264,7 +264,7 @@ A secret is anything that to which you want to tightly control access, such as A
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:
![[Important]](images/important.png) | 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:
| Important |
|---|
All of the properties in the preceding table must be prefixed with spring.cloud.config.server.vault or placed in the correct Vault section of a composite configuration. |
All configurable properties can be found in org.springframework.cloud.config.server.environment.VaultEnvironmentProperties.
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.
Optionally, there is support for the Vault Enterprise X-Vault-Namespace header. To have it sent to Vault set the namespace property.
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 kv put secret/application foo=bar baz=bam
$ vault kv put 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:
{
@@ -296,7 +296,7 @@ secret/myApp
secret/application,dev
secret/applicationProperties 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 Name | Remarks |
|---|
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 Name | Remarks |
|---|
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:
diff --git a/single/spring-cloud-config.html b/single/spring-cloud-config.html
index adf92062..304c86b2 100644
--- a/single/spring-cloud-config.html
+++ b/single/spring-cloud-config.html
@@ -14,12 +14,12 @@ The mini-application’s Environment is used to
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
-/{label}/{application}-{profile}.propertieswhere application is injected as the spring.config.name in the SpringApplication (what is normally application in a regular Spring Boot app), profile is an active profile (or comma-separated list of properties), and label is an optional git label (defaults to master.)
Spring Cloud Config Server pulls configuration for remote clients from a git repository (which must be provided), as shown in the following example:
spring:
+/{label}/{application}-{profile}.propertieswhere application is injected as the spring.config.name in the SpringApplication (what is normally application in a regular Spring Boot app), profile is an active profile (or comma-separated list of properties), and label is an optional git label (defaults to master.)
Spring Cloud Config Server pulls configuration for remote clients from various sources. The following example gets configuration from a git repository (which must be provided), as shown in the following example:
spring:
cloud:
config:
server:
git:
- uri: https://github.com/spring-cloud-samples/config-repoTo use these features in an application, you can build it as a Spring Boot application that depends on spring-cloud-config-client (for an example, see the test cases for the config-client or the sample application).
+ uri: https://github.com/spring-cloud-samples/config-repo
Other sources are any JDBC compatible database, Subversion, Hashicorp Vault, Credhub and local filesystems.
To use these features in an application, you can build it as a Spring Boot application that depends on spring-cloud-config-client (for an example, see the test cases for the config-client or the sample application).
The most convenient way to add the dependency is with a Spring Boot starter org.springframework.cloud:spring-cloud-starter-config.
There is also a parent pom and BOM (spring-cloud-starter-parent) for Maven users and a Spring IO version management properties file for Gradle and Spring CLI users. The following example shows a typical Maven configuration:
pom.xml.
<parent>
@@ -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 Name | Remarks |
|---|
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 Name | Remarks |
|---|
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:
@@ -348,7 +348,7 @@ A secret is anything that to which you want to tightly control access, such as A
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:
| 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:
| Important |
|---|
All of the properties in the preceding table must be prefixed with spring.cloud.config.server.vault or placed in the correct Vault section of a composite configuration. |
All configurable properties can be found in org.springframework.cloud.config.server.environment.VaultEnvironmentProperties.
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.
Optionally, there is support for the Vault Enterprise X-Vault-Namespace header. To have it sent to Vault set the namespace property.
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 kv put secret/application foo=bar baz=bam
$ vault kv put 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:
{
@@ -380,7 +380,7 @@ secret/myApp
secret/application,dev
secret/applicationProperties 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 Name | Remarks |
|---|
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 Name | Remarks |
|---|
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:
diff --git a/spring-cloud-config.xml b/spring-cloud-config.xml
index 617883c3..6c74e967 100644
--- a/spring-cloud-config.xml
+++ b/spring-cloud-config.xml
@@ -37,13 +37,14 @@ The mini-application’s Environment is used to enumerate
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties
where application is injected as the spring.config.name in the SpringApplication (what is normally application in a regular Spring Boot app), profile is an active profile (or comma-separated list of properties), and label is an optional git label (defaults to master.)
-Spring Cloud Config Server pulls configuration for remote clients from a git repository (which must be provided), as shown in the following example:
+Spring Cloud Config Server pulls configuration for remote clients from various sources. The following example gets configuration from a git repository (which must be provided), as shown in the following example:
spring:
cloud:
config:
server:
git:
uri: https://github.com/spring-cloud-samples/config-repo
+Other sources are any JDBC compatible database, Subversion, Hashicorp Vault, Credhub and local filesystems.
Client Side Usage
To use these features in an application, you can build it as a Spring Boot application that depends on spring-cloud-config-client (for an example, see the test cases for the config-client or the sample application).
@@ -667,14 +668,19 @@ The following table describes configurable Vault properties:
timeout
5
+
+namespace
+null
+
-All of the properties in the preceding table must be prefixed with spring.cloud.config.server.vault.
+All of the properties in the preceding table must be prefixed with spring.cloud.config.server.vault or placed in the correct Vault section of a composite configuration.
-All configurable properties can be found in org.springframework.cloud.config.server.environment.VaultEnvironmentRepository.
+All configurable properties can be found in org.springframework.cloud.config.server.environment.VaultEnvironmentProperties.
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.
+Optionally, there is support for the Vault Enterprise X-Vault-Namespace header. To have it sent to Vault set the namespace property.
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.