From a8e42a9fd5983000fc853ae97fbc4a42269a9575 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Tue, 29 May 2018 15:28:35 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- multi/multi__spring_cloud_config_client.html | 10 +++++----- multi/multi_spring-cloud-config.html | 2 +- single/spring-cloud-config.html | 12 ++++++------ spring-cloud-config.xml | 5 +++++ 4 files changed, 17 insertions(+), 12 deletions(-) diff --git a/multi/multi__spring_cloud_config_client.html b/multi/multi__spring_cloud_config_client.html index d198929d..8443b8d9 100644 --- a/multi/multi__spring_cloud_config_client.html +++ b/multi/multi__spring_cloud_config_client.html @@ -32,7 +32,7 @@ With the default Config Server implementation, it can be a git label, branch nam Label can also be provided as a comma-separated list. In that case, the items in the list are tried one by one until one succeeds. This behavior can be useful when working on a feature branch. -For instance, you might want to align the config label with your branch but make it optional (in that case, use spring.cloud.config.label=myfeature,develop).

7.6 Security

If you use HTTP Basic security on the server, clients need to know the password (and username if it is not the default). +For instance, you might want to align the config label with your branch but make it optional (in that case, use spring.cloud.config.label=myfeature,develop).

7.6 Specifying Multiple Urls for the Config Server

To ensure high availability when you have multiple instances of Config Server deployed and expect one or more instances to be unavailable from time to time, you can either specify multiple URLs (as a comma-separated list under the spring.cloud.config.uri property) or have all your instances register in a Service Registry like Eureka ( if using Discovery-First Bootstrap mode ). Note that doing so ensures high availability only when the Config Server is not running (that is, when the application has exited) or when a connection timeout has occurred. For example, if the Config Server returns a 500 (Internal Server Error) response or the Config Client receives a 401 from the Config Server (due to bad credentials or other causes), the Config Client does not try to fetch properties from other URLs. An error of that kind indicates a user issue rather than an availability problem.

If you use HTTP basic security on your Config Server, it is currently possible to support per-Config Server auth credentials only if you embed the credentials in each URL you specify under the spring.cloud.config.uri property. If you use any other kind of security mechanism, you cannot (currently) support per-Config Server authentication and authorization.

7.7 Security

If you use HTTP Basic security on the server, clients need to know the password (and username if it is not the default). You can specify the username and password through the config server URI or via separate username and password properties, as shown in the following example:

bootstrap.yml.  

spring:
   cloud:
@@ -51,11 +51,11 @@ The following example works locally and for a user-provided service on Cloud Fou
   cloud:
     config:
      uri: ${vcap.services.configserver.credentials.uri:http://user:password@localhost:8888}

-

If you use another form of security, you might need to provide a RestTemplate to the ConfigServicePropertySourceLocator (for example, by grabbing it in the bootstrap context and injecting it).

7.6.1 Health Indicator

The Config Client supplies a Spring Boot Health Indicator that attempts to load configuration from the Config Server. +

If you use another form of security, you might need to provide a RestTemplate to the ConfigServicePropertySourceLocator (for example, by grabbing it in the bootstrap context and injecting it).

7.7.1 Health Indicator

The Config Client supplies a Spring Boot Health Indicator that attempts to load configuration from the Config Server. The health indicator can be disabled by setting health.config.enabled=false. The response is also cached for performance reasons. The default cache time to live is 5 minutes. -To change that value, set the health.config.time-to-live property (in milliseconds).

7.6.2 Providing A Custom RestTemplate

In some cases, you might need to customize the requests made to the config server from the client. +To change that value, set the health.config.time-to-live property (in milliseconds).

7.7.2 Providing A Custom RestTemplate

In some cases, you might need to customize the requests made to the config server from the client. Typically, doing so involves passing special Authorization headers to authenticate requests to the server. To provide a custom RestTemplate:

  1. Create a new configuration bean with an implementation of PropertySourceLocator, as shown in the following example:

CustomConfigServiceBootstrapConfiguration.java.  

@Configuration
@@ -71,13 +71,13 @@ To provide a custom RestTemplate:
  1. In resources/META-INF, create a file called
 spring.factories and specify your custom configuration, as shown in the following example:
spring.factories. 
 
org.springframework.cloud.bootstrap.BootstrapConfiguration = com.my.config.client.CustomConfigServiceBootstrapConfiguration

-

7.6.3 Vault

When using Vault as a backend to your config server, the client needs to supply a token for the server to retrieve values from Vault. +

7.7.3 Vault

When using Vault as a backend to your config server, the client needs to supply a token for the server to retrieve values from Vault. This token can be provided within the client by setting spring.cloud.config.token in bootstrap.yml, as shown in the following example:

bootstrap.yml.  

spring:
   cloud:
     config:
       token: YourVaultToken

-

7.7 Nested Keys In Vault

Vault supports the ability to nest keys in a value stored in Vault, as shown in the following example:

echo -n '{"appA": {"secret": "appAsecret"}, "bar": "baz"}' | vault write secret/myapp -

This command writes a JSON object to your Vault. +

7.8 Nested Keys In Vault

Vault supports the ability to nest keys in a value stored in Vault, as shown in the following example:

echo -n '{"appA": {"secret": "appAsecret"}, "bar": "baz"}' | vault write secret/myapp -

This command writes a JSON object to your Vault. To access these values in Spring, you would use the traditional dot(.) annotation, as shown in the following example

@Value("${appA.secret}")
 String name = "World";

The preceding code would sets the value of the name variable to appAsecret.

Prev   
6. Push Notifications and Spring Cloud Bus Home 
\ No newline at end of file diff --git a/multi/multi_spring-cloud-config.html b/multi/multi_spring-cloud-config.html index 6f3d976e..f71f3bc0 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. Security
7.6.1. Health Indicator
7.6.2. Providing A Custom RestTemplate
7.6.3. Vault
7.7. 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. 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 diff --git a/single/spring-cloud-config.html b/single/spring-cloud-config.html index 36db7bbc..974a4a71 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. Security
7.6.1. Health Indicator
7.6.2. Providing A Custom RestTemplate
7.6.3. Vault
7.7. 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. 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. 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. @@ -550,7 +550,7 @@ With the default Config Server implementation, it can be a git label, branch nam Label can also be provided as a comma-separated list. In that case, the items in the list are tried one by one until one succeeds. This behavior can be useful when working on a feature branch. -For instance, you might want to align the config label with your branch but make it optional (in that case, use spring.cloud.config.label=myfeature,develop).

7.6 Security

If you use HTTP Basic security on the server, clients need to know the password (and username if it is not the default). +For instance, you might want to align the config label with your branch but make it optional (in that case, use spring.cloud.config.label=myfeature,develop).

7.6 Specifying Multiple Urls for the Config Server

To ensure high availability when you have multiple instances of Config Server deployed and expect one or more instances to be unavailable from time to time, you can either specify multiple URLs (as a comma-separated list under the spring.cloud.config.uri property) or have all your instances register in a Service Registry like Eureka ( if using Discovery-First Bootstrap mode ). Note that doing so ensures high availability only when the Config Server is not running (that is, when the application has exited) or when a connection timeout has occurred. For example, if the Config Server returns a 500 (Internal Server Error) response or the Config Client receives a 401 from the Config Server (due to bad credentials or other causes), the Config Client does not try to fetch properties from other URLs. An error of that kind indicates a user issue rather than an availability problem.

If you use HTTP basic security on your Config Server, it is currently possible to support per-Config Server auth credentials only if you embed the credentials in each URL you specify under the spring.cloud.config.uri property. If you use any other kind of security mechanism, you cannot (currently) support per-Config Server authentication and authorization.

7.7 Security

If you use HTTP Basic security on the server, clients need to know the password (and username if it is not the default). You can specify the username and password through the config server URI or via separate username and password properties, as shown in the following example:

bootstrap.yml.  

spring:
   cloud:
@@ -569,11 +569,11 @@ The following example works locally and for a user-provided service on Cloud Fou
   cloud:
     config:
      uri: ${vcap.services.configserver.credentials.uri:http://user:password@localhost:8888}

-

If you use another form of security, you might need to provide a RestTemplate to the ConfigServicePropertySourceLocator (for example, by grabbing it in the bootstrap context and injecting it).

7.6.1 Health Indicator

The Config Client supplies a Spring Boot Health Indicator that attempts to load configuration from the Config Server. +

If you use another form of security, you might need to provide a RestTemplate to the ConfigServicePropertySourceLocator (for example, by grabbing it in the bootstrap context and injecting it).

7.7.1 Health Indicator

The Config Client supplies a Spring Boot Health Indicator that attempts to load configuration from the Config Server. The health indicator can be disabled by setting health.config.enabled=false. The response is also cached for performance reasons. The default cache time to live is 5 minutes. -To change that value, set the health.config.time-to-live property (in milliseconds).

7.6.2 Providing A Custom RestTemplate

In some cases, you might need to customize the requests made to the config server from the client. +To change that value, set the health.config.time-to-live property (in milliseconds).

7.7.2 Providing A Custom RestTemplate

In some cases, you might need to customize the requests made to the config server from the client. Typically, doing so involves passing special Authorization headers to authenticate requests to the server. To provide a custom RestTemplate:

  1. Create a new configuration bean with an implementation of PropertySourceLocator, as shown in the following example:

CustomConfigServiceBootstrapConfiguration.java.  

@Configuration
@@ -589,13 +589,13 @@ To provide a custom RestTemplate:
  1. In resources/META-INF, create a file called
 spring.factories and specify your custom configuration, as shown in the following example:
spring.factories. 
 
org.springframework.cloud.bootstrap.BootstrapConfiguration = com.my.config.client.CustomConfigServiceBootstrapConfiguration

-

7.6.3 Vault

When using Vault as a backend to your config server, the client needs to supply a token for the server to retrieve values from Vault. +

7.7.3 Vault

When using Vault as a backend to your config server, the client needs to supply a token for the server to retrieve values from Vault. This token can be provided within the client by setting spring.cloud.config.token in bootstrap.yml, as shown in the following example:

bootstrap.yml.  

spring:
   cloud:
     config:
       token: YourVaultToken

-

7.7 Nested Keys In Vault

Vault supports the ability to nest keys in a value stored in Vault, as shown in the following example:

echo -n '{"appA": {"secret": "appAsecret"}, "bar": "baz"}' | vault write secret/myapp -

This command writes a JSON object to your Vault. +

7.8 Nested Keys In Vault

Vault supports the ability to nest keys in a value stored in Vault, as shown in the following example:

echo -n '{"appA": {"secret": "appAsecret"}, "bar": "baz"}' | vault write secret/myapp -

This command writes a JSON object to your Vault. To access these values in Spring, you would use the traditional dot(.) annotation, as shown in the following example

@Value("${appA.secret}")
 String name = "World";

The preceding code would sets the value of the name variable to appAsecret.

\ No newline at end of file diff --git a/spring-cloud-config.xml b/spring-cloud-config.xml index b007f1b8..5eebb97b 100644 --- a/spring-cloud-config.xml +++ b/spring-cloud-config.xml @@ -1123,6 +1123,11 @@ In that case, the items in the list are tried one by one until one succeeds. This behavior can be useful when working on a feature branch. For instance, you might want to align the config label with your branch but make it optional (in that case, use spring.cloud.config.label=myfeature,develop). +
+Specifying Multiple Urls for the Config Server +To ensure high availability when you have multiple instances of Config Server deployed and expect one or more instances to be unavailable from time to time, you can either specify multiple URLs (as a comma-separated list under the spring.cloud.config.uri property) or have all your instances register in a Service Registry like Eureka ( if using Discovery-First Bootstrap mode ). Note that doing so ensures high availability only when the Config Server is not running (that is, when the application has exited) or when a connection timeout has occurred. For example, if the Config Server returns a 500 (Internal Server Error) response or the Config Client receives a 401 from the Config Server (due to bad credentials or other causes), the Config Client does not try to fetch properties from other URLs. An error of that kind indicates a user issue rather than an availability problem. +If you use HTTP basic security on your Config Server, it is currently possible to support per-Config Server auth credentials only if you embed the credentials in each URL you specify under the spring.cloud.config.uri property. If you use any other kind of security mechanism, you cannot (currently) support per-Config Server authentication and authorization. +
Security If you use HTTP Basic security on the server, clients need to know the password (and username if it is not the default).