diff --git a/2.1.x/multi/multi__spring_cloud_config_server.html b/2.1.x/multi/multi__spring_cloud_config_server.html index 987785f1..bdd683c0 100644 --- a/2.1.x/multi/multi__spring_cloud_config_server.html +++ b/2.1.x/multi/multi__spring_cloud_config_server.html @@ -314,7 +314,10 @@ When myApp has the dev 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.7 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

CredHub Server

When using CredHub as a backend, you can share configuration with all applications by placing configuration in /application/ or by placing it in the default profile for the application. +For example, if you run the following CredHub command, all applications using the config server will have the properties shared.color1 and shared.color2 available to them:

credhub set --name "/application/profile/master/shared" --type=json
+value: {"shared.color1": "blue", "shared.color": "red"}
credhub set --name "/my-app/default/master/more-shared" --type=json
+value: {"shared.word1": "hello", "shared.word2": "world"}

2.1.7 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. @@ -340,7 +343,8 @@ value: {"marketing.enabled": true, "external.enabled": false}

All client toggle.link: "red", marketing.enabled: true, external.enabled: false -}

[Note]Note

When no profile is specified default will be used and when no label is specified master will be used as a default value.

OAuth 2.0

You can authenticate with OAuth 2.0 using UAA as a provider.

pom.xml.  +}

[Note]Note

When no profile is specified default will be used and when no label is specified master will be used as a default value. +NOTE: Values added to application will be shared by all the applications.

OAuth 2.0

You can authenticate with OAuth 2.0 using UAA as a provider.

pom.xml. 

<dependencies>
 	<dependency>
 		<groupId>org.springframework.security</groupId>
diff --git a/2.1.x/multi/multi_spring-cloud-config.html b/2.1.x/multi/multi_spring-cloud-config.html
index 7ca38783..7ff1e960 100644
--- a/2.1.x/multi/multi_spring-cloud-config.html
+++ b/2.1.x/multi/multi_spring-cloud-config.html
@@ -1,3 +1,3 @@
 
       
-   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. CredHub Backend
OAuth 2.0
2.1.9. Composite Environment Repositories
Custom Composite Environment Repositories
2.1.10. 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 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
\ No newline at end of file + 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
CredHub Server
2.1.7. JDBC Backend
2.1.8. CredHub Backend
OAuth 2.0
2.1.9. Composite Environment Repositories
Custom Composite Environment Repositories
2.1.10. 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 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
\ No newline at end of file diff --git a/2.1.x/single/spring-cloud-config.html b/2.1.x/single/spring-cloud-config.html index 37afebc5..6801bb0d 100644 --- a/2.1.x/single/spring-cloud-config.html +++ b/2.1.x/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
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. CredHub Backend
OAuth 2.0
2.1.9. Composite Environment Repositories
Custom Composite Environment Repositories
2.1.10. 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 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.6.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
CredHub Server
2.1.7. JDBC Backend
2.1.8. CredHub Backend
OAuth 2.0
2.1.9. Composite Environment Repositories
Custom Composite Environment Repositories
2.1.10. 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 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.6.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. @@ -398,7 +398,10 @@ When myApp has the dev 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.7 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

CredHub Server

When using CredHub as a backend, you can share configuration with all applications by placing configuration in /application/ or by placing it in the default profile for the application. +For example, if you run the following CredHub command, all applications using the config server will have the properties shared.color1 and shared.color2 available to them:

credhub set --name "/application/profile/master/shared" --type=json
+value: {"shared.color1": "blue", "shared.color": "red"}
credhub set --name "/my-app/default/master/more-shared" --type=json
+value: {"shared.word1": "hello", "shared.word2": "world"}

2.1.7 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. @@ -424,7 +427,8 @@ value: {"marketing.enabled": true, "external.enabled": false}

All client toggle.link: "red", marketing.enabled: true, external.enabled: false -}

[Note]Note

When no profile is specified default will be used and when no label is specified master will be used as a default value.

OAuth 2.0

You can authenticate with OAuth 2.0 using UAA as a provider.

pom.xml.  +}

[Note]Note

When no profile is specified default will be used and when no label is specified master will be used as a default value. +NOTE: Values added to application will be shared by all the applications.

OAuth 2.0

You can authenticate with OAuth 2.0 using UAA as a provider.

pom.xml. 

<dependencies>
 	<dependency>
 		<groupId>org.springframework.security</groupId>
diff --git a/2.1.x/spring-cloud-config.xml b/2.1.x/spring-cloud-config.xml
index a7670e4c..f9112270 100644
--- a/2.1.x/spring-cloud-config.xml
+++ b/2.1.x/spring-cloud-config.xml
@@ -811,6 +811,15 @@ Otherwise, the application* resources in the default search l
 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
 
+
+CredHub Server +When using CredHub as a backend, you can share configuration with all applications by placing configuration in /application/ or by placing it in the default profile for the application. +For example, if you run the following CredHub command, all applications using the config server will have the properties shared.color1 and shared.color2 available to them: +credhub set --name "/application/profile/master/shared" --type=json +value: {"shared.color1": "blue", "shared.color": "red"} +credhub set --name "/my-app/default/master/more-shared" --type=json +value: {"shared.word1": "hello", "shared.word2": "world"} +
JDBC Backend @@ -858,7 +867,8 @@ value: {"marketing.enabled": true, "external.enabled": false} external.enabled: false } -When no profile is specified default will be used and when no label is specified master will be used as a default value. +When no profile is specified default will be used and when no label is specified master will be used as a default value. +NOTE: Values added to application will be shared by all the applications.
OAuth 2.0