From ded1a4ab74dcf7bbd696b1a6688767e1919627dd Mon Sep 17 00:00:00 2001 From: buildmaster Date: Mon, 19 Nov 2018 21:31:06 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- multi/multi__embedding_the_config_server.html | 15 +++++++- multi/multi__spring_cloud_config_server.html | 19 ++++++---- multi/multi_spring-cloud-config.html | 2 +- single/spring-cloud-config.html | 36 +++++++++++++----- spring-cloud-config.xml | 38 ++++++++++++++++--- 5 files changed, 86 insertions(+), 24 deletions(-) diff --git a/multi/multi__embedding_the_config_server.html b/multi/multi__embedding_the_config_server.html index 11c11da4..df3e2f32 100644 --- a/multi/multi__embedding_the_config_server.html +++ b/multi/multi__embedding_the_config_server.html @@ -6,7 +6,20 @@ To do so, use the @EnableConfigServer annotation. An optional property named spring.cloud.config.server.bootstrap can be useful in this case. It is a flag to indicate whether the server should configure itself from its own remote repository. By default, the flag is off, because it can delay startup. -However, when embedded in another application, it makes sense to initialize the same way as any other application.

[Note]Note

If you use the bootstrap flag, the config server needs to have its name and repository URI configured in bootstrap.yml.

To change the location of the server endpoints, you can (optionally) set spring.cloud.config.server.prefix (for example, /config), to serve the resources under a prefix. +However, when embedded in another application, it makes sense to initialize the same way as any other application. +When setting spring.cloud.config.server.bootstrap to true you must also use a composite environment repository configuration. +For example

spring:
+  application:
+    name: configserver
+  profiles:
+    active: composite
+  cloud:
+    config:
+      server:
+        composite:
+          - type: native
+            search-locations: ${HOME}/Desktop/config
+        bootstrap: true
[Note]Note

If you use the bootstrap flag, the config server needs to have its name and repository URI configured in bootstrap.yml.

To change the location of the server endpoints, you can (optionally) set spring.cloud.config.server.prefix (for example, /config), to serve the resources under a prefix. The prefix should start but not end with a /. It is applied to the @RequestMappings in the Config Server (that is, underneath the Spring Boot server.servletPath and server.contextPath prefixes).

If you want to read the configuration for an application directly from the backend repository (instead of from the config server), you basically want an embedded config server with no endpoints. diff --git a/multi/multi__spring_cloud_config_server.html b/multi/multi__spring_cloud_config_server.html index ce7a9bd8..28329983 100644 --- a/multi/multi__spring_cloud_config_server.html +++ b/multi/multi__spring_cloud_config_server.html @@ -241,7 +241,11 @@ Example:

      server:
         git:
           uri: https://github.com/spring-cloud-samples/config-repo
-          deleteUntrackedBranches: true
[Note]Note

The default value for deleteUntrackedBranches property is false.

2.1.2 Version Control Backend Filesystem Use

[Warning]Warning

With VCS-based backends (git, svn), files are checked out or cloned to the local filesystem. + deleteUntrackedBranches: true

[Note]Note

The default value for deleteUntrackedBranches property is false.

Git Refresh Rate

You can control how often the config server will fetch updated configuration data +from your Git backend by using spring.cloud.config.server.git.refreshRate. The +value of this property is specified in seconds. By default the value is 0, meaning +the config server will fetch updated configuration from the Git repo every time it +is requested.

2.1.2 Version Control Backend Filesystem Use

[Warning]Warning

With VCS-based backends (git, svn), files are checked out or cloned to the local filesystem. By default, they are put in the system temporary directory with a prefix of config-repo-. On linux, for example, it could be /tmp/config-repo-<randomid>. Some operating systems routinely clean out temporary directories. @@ -256,14 +260,14 @@ In this way, you can segregate the directories in the path and choose a strategy 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. -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. +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 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:

{
+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:
{
    "name":"myapp",
    "profiles":[
       "default"
@@ -292,7 +296,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:
@@ -401,8 +405,9 @@ $ spring decrypt --key foo 682bc583f4641835fa2db009355293665d2647dade3375c0ee201
 mysecret
To use a key in a file (such as an RSA public key for encryption), prepend
 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 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).
[Note]Note
You cannot configure an asymmetric key using encrypt.key.
To configure an asymmetric key use a keystore (e.g. as
+created by the keytool utility that comes with the JDK). The
+keystore properties are encrypt.keyStore.* with * equal to
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_spring-cloud-config.html b/multi/multi_spring-cloud-config.html
index ec1257db..7cf033d5 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
Git Refresh Rate
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 c320031a..ee819998 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
Git Refresh Rate
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.
@@ -325,7 +325,11 @@ Example:
      server:
         git:
           uri: https://github.com/spring-cloud-samples/config-repo
-          deleteUntrackedBranches: true
[Note]Note
The default value for deleteUntrackedBranches property is false.
2.1.2 Version Control Backend Filesystem Use
[Warning]Warning
With VCS-based backends (git, svn), files are checked out or cloned to the local filesystem.
+          deleteUntrackedBranches: true
[Note]Note
The default value for deleteUntrackedBranches property is false.
Git Refresh Rate
You can control how often the config server will fetch updated configuration data
+from your Git backend by using spring.cloud.config.server.git.refreshRate.  The
+value of this property is specified in seconds.  By default the value is 0, meaning
+the config server will fetch updated configuration from the Git repo every time it
+is requested.
2.1.2 Version Control Backend Filesystem Use
[Warning]Warning
With VCS-based backends (git, svn), files are checked out or cloned to the local filesystem.
 By default, they are put in the system temporary directory with a prefix of config-repo-.
 On linux, for example, it could be /tmp/config-repo-<randomid>.
 Some operating systems routinely clean out temporary directories.
@@ -340,14 +344,14 @@ In this way, you can segregate the directories in the path and choose a strategy
 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.
-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.
+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
 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:
{
+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:
{
    "name":"myapp",
    "profiles":[
       "default"
@@ -376,7 +380,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:
@@ -485,8 +489,9 @@ $ spring decrypt --key foo 682bc583f4641835fa2db009355293665d2647dade3375c0ee201
 mysecret
To use a key in a file (such as an RSA public key for encryption), prepend
 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 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).
[Note]Note
You cannot configure an asymmetric key using encrypt.key.
To configure an asymmetric key use a keystore (e.g. as
+created by the keytool utility that comes with the JDK). The
+keystore properties are encrypt.keyStore.* with * equal to
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
@@ -548,7 +553,20 @@ To do so, use the @EnableConfigServer annotation.
 An optional property named spring.cloud.config.server.bootstrap can be useful in this case.
 It is a flag to indicate whether the server should configure itself from its own remote repository.
 By default, the flag is off, because it can delay startup.
-However, when embedded in another application, it makes sense to initialize the same way as any other application.
[Note]Note
If you use the bootstrap flag, the config server needs to have its name and repository URI configured in bootstrap.yml.
To change the location of the server endpoints, you can (optionally) set spring.cloud.config.server.prefix (for example, /config), to serve the resources under a prefix.
+However, when embedded in another application, it makes sense to initialize the same way as any other application.
+When setting spring.cloud.config.server.bootstrap to true you must also use a composite environment repository configuration.
+For example
spring:
+  application:
+    name: configserver
+  profiles:
+    active: composite
+  cloud:
+    config:
+      server:
+        composite:
+          - type: native
+            search-locations: ${HOME}/Desktop/config
+        bootstrap: true
[Note]Note
If you use the bootstrap flag, the config server needs to have its name and repository URI configured in bootstrap.yml.
To change the location of the server endpoints, you can (optionally) set spring.cloud.config.server.prefix (for example, /config), to serve the resources under a prefix.
 The prefix should start but not end with a /.
 It is applied to the @RequestMappings in the Config Server (that is, underneath the Spring Boot server.servletPath and server.contextPath prefixes).
If you want to read the configuration for an application directly from the backend repository (instead of from the config server), you
 basically want an embedded config server with no endpoints.
diff --git a/spring-cloud-config.xml b/spring-cloud-config.xml
index 45a45a46..16ebb409 100644
--- a/spring-cloud-config.xml
+++ b/spring-cloud-config.xml
@@ -562,6 +562,14 @@ Example:
 The default value for deleteUntrackedBranches property is false.
 
 
+

+Git Refresh Rate
+You can control how often the config server will fetch updated configuration data
+from your Git backend by using spring.cloud.config.server.git.refreshRate.  The
+value of this property is specified in seconds.  By default the value is 0, meaning
+the config server will fetch updated configuration from the Git repo every time it
+is requested.
+

 
 

 Version Control Backend Filesystem Use
@@ -605,7 +613,7 @@ This behavior can be disabled by setting spring.cloud.config.server.nat
 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.
+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.
@@ -671,8 +679,8 @@ The following table describes configurable Vault properties:
 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
+$ 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:
@@ -992,8 +1000,12 @@ AQAjPgt3eFZQXwt8tsHAVv/QHiY5sI2dRcR+...
 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:
+
+You cannot configure an asymmetric key using encrypt.key.
+
+To configure an asymmetric key use a keystore (e.g. as
+created by the keytool utility that comes with the JDK). The
+keystore properties are encrypt.keyStore.* with * equal to
 
 
 
@@ -1136,7 +1148,21 @@ To do so, use the @EnableConfigServer annotation.
 An optional property named spring.cloud.config.server.bootstrap can be useful in this case.
 It is a flag to indicate whether the server should configure itself from its own remote repository.
 By default, the flag is off, because it can delay startup.
-However, when embedded in another application, it makes sense to initialize the same way as any other application.
+However, when embedded in another application, it makes sense to initialize the same way as any other application.
+When setting spring.cloud.config.server.bootstrap to true you must also use a composite environment repository configuration.
+For example
+spring:
+  application:
+    name: configserver
+  profiles:
+    active: composite
+  cloud:
+    config:
+      server:
+        composite:
+          - type: native
+            search-locations: ${HOME}/Desktop/config
+        bootstrap: true
 
 If you use the bootstrap flag, the config server needs to have its name and repository URI configured in bootstrap.yml.