From 9e04dea8abec40720382c16a334dadd52493edd4 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Wed, 13 Jun 2018 20:38:32 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- multi/multi__spring_cloud_config_server.html | 35 +++++++--- multi/multi_spring-cloud-config.html | 2 +- single/spring-cloud-config.html | 37 +++++++--- spring-cloud-config.xml | 72 ++++++++++++++++++-- 4 files changed, 118 insertions(+), 28 deletions(-) diff --git a/multi/multi__spring_cloud_config_server.html b/multi/multi__spring_cloud_config_server.html index d042c17a..6a01f8c0 100644 --- a/multi/multi__spring_cloud_config_server.html +++ b/multi/multi__spring_cloud_config_server.html @@ -246,7 +246,7 @@ 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.11 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.11 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. @@ -283,15 +283,29 @@ 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.12 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. +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.12 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:
+    config:
+      server:
+        git:
+          uri: https://github.com/spring-cloud-samples/config-repo
+          proxy:
+            https:
+              host: my-proxy.host.io
+              password: myproxypassword
+              port: '3128'
+              username: myproxyusername
+              nonProxyHosts: example.com

2.1.13 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. 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.13 JDBC Backend

Spring Cloud Config Server supports JDBC (relational database) as a backend for configuration properties. +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.14 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. If you include the right dependencies on the classpath (see the user guide for more details on that), Spring Boot configures a data source.

The database needs to have a table called PROPERTIES with columns called APPLICATION, PROFILE, and LABEL (with the usual Environment meaning), plus KEY and VALUE for the key and value pairs in Properties style. All fields are of type String in Java, so you can make them VARCHAR of whatever length you need. -Property values behave in the same way as they would if they came from Spring Boot properties files named {application}-{profile}.properties, including all the encryption and decryption, which will be applied as post-processing steps (that is, not in the repository implementation directly).

2.1.14 Composite Environment Repositories

In some scenarios, you may wish to pull configuration data from multiple environment repositories. +Property values behave in the same way as they would if they came from Spring Boot properties files named {application}-{profile}.properties, including all the encryption and decryption, which will be applied as post-processing steps (that is, not in the repository implementation directly).

2.1.15 Composite Environment Repositories

In some scenarios, you may wish to pull configuration data from multiple environment repositories. To do so, you can enable the composite profile in your configuration server’s application properties or YAML file. If, for example, you want to pull configuration data from a Subversion repository as well as two Git repositories, you can set the following properties for your configuration server:

spring:
   profiles:
@@ -311,25 +325,26 @@ If, for example, you want to pull configuration data from a Subversion repositor
           uri: file:///path/to/walter/git/repo

Using this configuration, precedence is determined by the order in which repositories are listed under the composite key. In the above example, the Subversion repository is listed first, so a value found in the Subversion repository will override values found for the same property in one of the Git repositories. A value found in the rex Git repository will be used before a value found for the same property in the walter Git repository.

If you want to pull configuration data only from repositories that are each of distinct types, you can enable the corresponding profiles, rather than the composite profile, in your configuration server’s application properties or YAML file. -If, for example, you want to pull configuration data from a single Git repository and a single Subversion repository, you can set the following properties for your configuration server:

spring:
+If, for example, you want to pull configuration data from a single Git repository and a single HashiCorp Vault server, you can set the following properties for your configuration server:
spring:
   profiles:
-    active: git, subversion
+    active: git, vault
   cloud:
     config:
       server:
         git:
           uri: file:///path/to/git/repo
           order: 2
-        svn:
-          uri: file:///path/to/svn/repo
+        vault:
+          host: 127.0.0.1
+          port: 8200
           order: 1
Using this configuration, precedence can be determined by an order property.
 You can use the order property to specify the priority order for all your repositories.
 The lower the numerical value of the order property, the higher priority it has.
-The priority order of a repository helps resolve any potential conflicts between repositories that contain values for the same properties.
[Note]Note
Any type of failure when retrieving values from an environment repository results in a failure for the entire composite environment.
[Note]Note
When using a composite environment, it is important that all repositories contain the same labels.
+The priority order of a repository helps resolve any potential conflicts between repositories that contain values for the same properties.
[Note]Note
If your composite environment includes a Vault server as in the previous example, you must include a Vault token in every request made to the configuration server. See Vault Backend.
[Note]Note
Any type of failure when retrieving values from an environment repository results in a failure for the entire composite environment.
[Note]Note
When using a composite environment, it is important that all repositories contain the same labels.
 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.15 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.16 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:
diff --git a/multi/multi_spring-cloud-config.html b/multi/multi_spring-cloud-config.html
index f71f3bc0..a6d4687d 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. Placeholders in Git URI
2.1.2. Pattern Matching and Multiple Repositories
2.1.3. Authentication
2.1.4. Authentication with AWS CodeCommit
2.1.5. Git SSH configuration using properties
2.1.6. Placeholders in Git Search Paths
2.1.7. Force pull in Git Repositories
2.1.8. Deleting untracked branches in Git Repositories
2.1.9. Version Control Backend Filesystem Use
2.1.10. File System Backend
2.1.11. Vault Backend
Multiple Properties Sources
2.1.12. Sharing Configuration With All Applications
File Based Repositories
Vault Server
2.1.13. JDBC Backend
2.1.14. Composite Environment Repositories
Custom Composite Environment Repositories
2.1.15. 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. Security
7.7.1. Health Indicator
7.7.2. Providing A Custom RestTemplate
7.7.3. Vault
7.8. 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. Placeholders in Git URI
2.1.2. Pattern Matching and Multiple Repositories
2.1.3. Authentication
2.1.4. Authentication with AWS CodeCommit
2.1.5. Git SSH configuration using properties
2.1.6. Placeholders in Git Search Paths
2.1.7. Force pull in Git Repositories
2.1.8. Deleting untracked branches in Git Repositories
2.1.9. Version Control Backend Filesystem Use
2.1.10. File System Backend
2.1.11. Vault Backend
Multiple Properties Sources
2.1.12. Accessing Backends Through a Proxy
2.1.13. Sharing Configuration With All Applications
File Based Repositories
Vault Server
2.1.14. JDBC Backend
2.1.15. Composite Environment Repositories
Custom Composite Environment Repositories
2.1.16. 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. Security
7.7.1. Health Indicator
7.7.2. Providing A Custom RestTemplate
7.7.3. Vault
7.8. 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 3b495c56..4b3cb9dc 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. Placeholders in Git URI
2.1.2. Pattern Matching and Multiple Repositories
2.1.3. Authentication
2.1.4. Authentication with AWS CodeCommit
2.1.5. Git SSH configuration using properties
2.1.6. Placeholders in Git Search Paths
2.1.7. Force pull in Git Repositories
2.1.8. Deleting untracked branches in Git Repositories
2.1.9. Version Control Backend Filesystem Use
2.1.10. File System Backend
2.1.11. Vault Backend
Multiple Properties Sources
2.1.12. Sharing Configuration With All Applications
File Based Repositories
Vault Server
2.1.13. JDBC Backend
2.1.14. Composite Environment Repositories
Custom Composite Environment Repositories
2.1.15. 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. Security
7.7.1. Health Indicator
7.7.2. Providing A Custom RestTemplate
7.7.3. Vault
7.8. Nested Keys In Vault
2.0.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. Placeholders in Git URI
2.1.2. Pattern Matching and Multiple Repositories
2.1.3. Authentication
2.1.4. Authentication with AWS CodeCommit
2.1.5. Git SSH configuration using properties
2.1.6. Placeholders in Git Search Paths
2.1.7. Force pull in Git Repositories
2.1.8. Deleting untracked branches in Git Repositories
2.1.9. Version Control Backend Filesystem Use
2.1.10. File System Backend
2.1.11. Vault Backend
Multiple Properties Sources
2.1.12. Accessing Backends Through a Proxy
2.1.13. Sharing Configuration With All Applications
File Based Repositories
Vault Server
2.1.14. JDBC Backend
2.1.15. Composite Environment Repositories
Custom Composite Environment Repositories
2.1.16. 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. Security
7.7.1. Health Indicator
7.7.2. Providing A Custom RestTemplate
7.7.3. Vault
7.8. Nested Keys In Vault
2.0.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.
@@ -330,7 +330,7 @@ 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.11 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.11 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.
@@ -367,15 +367,29 @@ 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.12 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.
+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.12 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:
+    config:
+      server:
+        git:
+          uri: https://github.com/spring-cloud-samples/config-repo
+          proxy:
+            https:
+              host: my-proxy.host.io
+              password: myproxypassword
+              port: '3128'
+              username: myproxyusername
+              nonProxyHosts: example.com
2.1.13 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.
 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.13 JDBC Backend
Spring Cloud Config Server supports JDBC (relational database) as a backend for configuration properties.
+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.14 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.
 If you include the right dependencies on the classpath (see the user guide for more details on that), Spring Boot configures a data source.
The database needs to have a table called PROPERTIES with columns called APPLICATION, PROFILE, and LABEL (with the usual Environment meaning), plus KEY and VALUE for the key and value pairs in Properties style.
 All fields are of type String in Java, so you can make them VARCHAR of whatever length you need.
-Property values behave in the same way as they would if they came from Spring Boot properties files named {application}-{profile}.properties, including all the encryption and decryption, which will be applied as post-processing steps (that is, not in the repository implementation directly).
2.1.14 Composite Environment Repositories
In some scenarios, you may wish to pull configuration data from multiple environment repositories.
+Property values behave in the same way as they would if they came from Spring Boot properties files named {application}-{profile}.properties, including all the encryption and decryption, which will be applied as post-processing steps (that is, not in the repository implementation directly).
2.1.15 Composite Environment Repositories
In some scenarios, you may wish to pull configuration data from multiple environment repositories.
 To do so, you can enable the composite profile in your configuration server’s application properties or YAML file.
 If, for example, you want to pull configuration data from a Subversion repository as well as two Git repositories, you can set the following properties for your configuration server:
spring:
   profiles:
@@ -395,25 +409,26 @@ If, for example, you want to pull configuration data from a Subversion repositor
           uri: file:///path/to/walter/git/repo
Using this configuration, precedence is determined by the order in which repositories are listed under the composite key.
 In the above example, the Subversion repository is listed first, so a value found in the Subversion repository will override values found for the same property in one of the Git repositories.
 A value found in the rex Git repository will be used before a value found for the same property in the walter Git repository.
If you want to pull configuration data only from repositories that are each of distinct types, you can enable the corresponding profiles, rather than the composite profile, in your configuration server’s application properties or YAML file.
-If, for example, you want to pull configuration data from a single Git repository and a single Subversion repository, you can set the following properties for your configuration server:
spring:
+If, for example, you want to pull configuration data from a single Git repository and a single HashiCorp Vault server, you can set the following properties for your configuration server:
spring:
   profiles:
-    active: git, subversion
+    active: git, vault
   cloud:
     config:
       server:
         git:
           uri: file:///path/to/git/repo
           order: 2
-        svn:
-          uri: file:///path/to/svn/repo
+        vault:
+          host: 127.0.0.1
+          port: 8200
           order: 1
Using this configuration, precedence can be determined by an order property.
 You can use the order property to specify the priority order for all your repositories.
 The lower the numerical value of the order property, the higher priority it has.
-The priority order of a repository helps resolve any potential conflicts between repositories that contain values for the same properties.
[Note]Note
Any type of failure when retrieving values from an environment repository results in a failure for the entire composite environment.
[Note]Note
When using a composite environment, it is important that all repositories contain the same labels.
+The priority order of a repository helps resolve any potential conflicts between repositories that contain values for the same properties.
[Note]Note
If your composite environment includes a Vault server as in the previous example, you must include a Vault token in every request made to the configuration server. See Vault Backend.
[Note]Note
Any type of failure when retrieving values from an environment repository results in a failure for the entire composite environment.
[Note]Note
When using a composite environment, it is important that all repositories contain the same labels.
 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.15 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.16 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:
diff --git a/spring-cloud-config.xml b/spring-cloud-config.xml
index 3e3771af..2d765f2b 100644
--- a/spring-cloud-config.xml
+++ b/spring-cloud-config.xml
@@ -571,7 +571,7 @@ Thus, the default behaviour with no placeholders is the same as adding a search
 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.
 
-

+

 Vault Backend
 Spring Cloud Config Server also supports Vault as a backend.
 
@@ -678,6 +678,62 @@ An application with the name, myApp, would have any propertie
 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.
 

 

+

+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.
+
+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:
+    config:
+      server:
+        git:
+          uri: https://github.com/spring-cloud-samples/config-repo
+          proxy:
+            https:
+              host: my-proxy.host.io
+              password: myproxypassword
+              port: '3128'
+              username: myproxyusername
+              nonProxyHosts: example.com
+

 

 Sharing Configuration With All Applications
 Sharing configuration between all applications varies according to which approach you take, as described in the following topics:
@@ -716,7 +772,7 @@ If you include the right dependencies on the classpath (see the user guide for m
 All fields are of type String in Java, so you can make them VARCHAR of whatever length you need.
 Property values behave in the same way as they would if they came from Spring Boot properties files named {application}-{profile}.properties, including all the encryption and decryption, which will be applied as post-processing steps (that is, not in the repository implementation directly).
 

-

+

 Composite Environment Repositories
 In some scenarios, you may wish to pull configuration data from multiple environment repositories.
 To do so, you can enable the composite profile in your configuration server’s application properties or YAML file.
@@ -741,24 +797,28 @@ If, for example, you want to pull configuration data from a Subversion repositor
 In the above example, the Subversion repository is listed first, so a value found in the Subversion repository will override values found for the same property in one of the Git repositories.
 A value found in the rex Git repository will be used before a value found for the same property in the walter Git repository.
 If you want to pull configuration data only from repositories that are each of distinct types, you can enable the corresponding profiles, rather than the composite profile, in your configuration server’s application properties or YAML file.
-If, for example, you want to pull configuration data from a single Git repository and a single Subversion repository, you can set the following properties for your configuration server:
+If, for example, you want to pull configuration data from a single Git repository and a single HashiCorp Vault server, you can set the following properties for your configuration server:
 spring:
   profiles:
-    active: git, subversion
+    active: git, vault
   cloud:
     config:
       server:
         git:
           uri: file:///path/to/git/repo
           order: 2
-        svn:
-          uri: file:///path/to/svn/repo
+        vault:
+          host: 127.0.0.1
+          port: 8200
           order: 1
 Using this configuration, precedence can be determined by an order property.
 You can use the order property to specify the priority order for all your repositories.
 The lower the numerical value of the order property, the higher priority it has.
 The priority order of a repository helps resolve any potential conflicts between repositories that contain values for the same properties.
 
+If your composite environment includes a Vault server as in the previous example, you must include a Vault token in every request made to the configuration server. See Vault Backend.
+
+
 Any type of failure when retrieving values from an environment repository results in a failure for the entire composite environment.