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.
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:
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 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.
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
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:
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
Any type of failure when retrieving values from an environment repository results in a failure for the entire composite environment.
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
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
Any type of failure when retrieving values from an environment repository results in a failure for the entire composite environment.
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:
![[Tip]](images/tip.png)
![[Note]](images/note.png)