From 9ca9a9cd70ff582021742b71c5d391d39881bbfd Mon Sep 17 00:00:00 2001 From: buildmaster Date: Fri, 22 Sep 2017 13:23:41 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- multi/multi__spring_cloud_config_server.html | 22 ++++++++++++++---- multi/multi_spring-cloud-config.html | 2 +- single/spring-cloud-config.html | 24 ++++++++++++++++---- spring-cloud-config.xml | 23 +++++++++++++++++-- 4 files changed, 59 insertions(+), 12 deletions(-) diff --git a/multi/multi__spring_cloud_config_server.html b/multi/multi__spring_cloud_config_server.html index 6264beb1..8b244504 100644 --- a/multi/multi__spring_cloud_config_server.html +++ b/multi/multi__spring_cloud_config_server.html @@ -324,7 +324,7 @@ is the same as file:/tmp/config,file:/tmp/config/{label}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 you want to tightly control access to, such as API keys, passwords, certificates, and more. 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 quickstart guide.

To enable the config server to use a Vault backend you must run your config server +while providing tight access control and recording a detailed audit log.

For more information on Vault see the Vault quickstart 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 will assume your Vault server is running at http://127.0.0.1:8200. It also will assume that the name of backend @@ -381,8 +381,22 @@ resources in the default search locations are 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 this Vault command

$ vault write secret/application foo=bar baz=bam

All applications using the config server will have the properties -foo and baz available to them.

2.1.6 Composite Environment Repositories

In some scenarios you may wish to pull configuration data from multiple -environment repositories. To do this just enable +foo and baz available to them.

2.1.6 JDBC Backend

Spring Cloud Config Server supports JDBC (relation 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. Spring Boot +will configure a data source if you include the right dependencies on +the classpath (see the user guide for more details on that).

The database needs to have a table called "PROPERTIES" with columns +"APPLICATION", "PROFILE", "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 (i.e. not in the repository implementation +directly).

2.1.7 Composite Environment Repositories

In some scenarios you may wish to pull configuration data from multiple +environment repositories. To do this you can just enable multiple profiles in your config server’s application properties or YAML file. If, for example, you want to pull configuration data from a Git repository as well as a SVN repository you would set the following properties for your @@ -412,7 +426,7 @@ must implement the EnvironmentRepository interface. the priority of you 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 then your -EnvironmentRepository will be given the lowest priority.

2.1.7 Property Overrides

The Config Server has an "overrides" feature that allows the operator +EnvironmentRepository will be given the lowest priority.

2.1.8 Property Overrides

The Config Server has an "overrides" feature that allows the operator to provide configuration properties to all applications that cannot be accidentally changed by the application using the normal Spring Boot hooks. To declare overrides just add a map of name-value pairs to diff --git a/multi/multi_spring-cloud-config.html b/multi/multi_spring-cloud-config.html index 53e7f8f7..266ff3f9 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
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
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. Sharing Configuration With All Applications
File Based Repositories
Vault Server
2.1.6. Composite Environment Repositories
Custom Composite Environment Repositories
2.1.7. 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. Vault
7.7.1. 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
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
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. Sharing Configuration With All Applications
File Based Repositories
Vault Server
2.1.6. JDBC Backend
2.1.7. Composite Environment Repositories
Custom Composite Environment Repositories
2.1.8. 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. Vault
7.7.1. 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 b05db579..af168349 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
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
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. Sharing Configuration With All Applications
File Based Repositories
Vault Server
2.1.6. Composite Environment Repositories
Custom Composite Environment Repositories
2.1.7. 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. Vault
7.7.1. Nested Keys In Vault

1.4.0.BUILD-SNAPSHOT

Spring Cloud Config provides server 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. It is easy to add alternative implementations and plug them in with Spring configuration.

1. Quick Start

Start the server:

$ cd spring-cloud-config-server
+   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
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
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. Sharing Configuration With All Applications
File Based Repositories
Vault Server
2.1.6. JDBC Backend
2.1.7. Composite Environment Repositories
Custom Composite Environment Repositories
2.1.8. 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. Vault
7.7.1. Nested Keys In Vault
1.4.0.BUILD-SNAPSHOT
Spring Cloud Config provides server 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.  It is easy to add alternative implementations and plug them in with Spring configuration.
1. Quick Start
Start the server:
$ cd spring-cloud-config-server
 $ ../mvnw spring-boot:run
The server is a Spring Boot application so you can run it from your
 IDE instead if you prefer (the main class is
 ConfigServerApplication). Then try out a client:
$ curl localhost:8888/foo/development
@@ -426,7 +426,7 @@ is the same as file:/tmp/config,file:/tmp/config/{label}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 you want to tightly control access to, such as API keys, passwords,
 certificates, and more. 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 quickstart guide.
To enable the config server to use a Vault backend you must run your config server
+while providing tight access control and recording a detailed audit log.
For more information on Vault see the Vault quickstart 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 will assume your Vault server is running at
 http://127.0.0.1:8200.  It also will assume that the name of backend
@@ -483,8 +483,22 @@ resources in the default search locations are 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 this Vault command

$ vault write secret/application foo=bar baz=bam

All applications using the config server will have the properties -foo and baz available to them.

2.1.6 Composite Environment Repositories

In some scenarios you may wish to pull configuration data from multiple -environment repositories. To do this just enable +foo and baz available to them.

2.1.6 JDBC Backend

Spring Cloud Config Server supports JDBC (relation 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. Spring Boot +will configure a data source if you include the right dependencies on +the classpath (see the user guide for more details on that).

The database needs to have a table called "PROPERTIES" with columns +"APPLICATION", "PROFILE", "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 (i.e. not in the repository implementation +directly).

2.1.7 Composite Environment Repositories

In some scenarios you may wish to pull configuration data from multiple +environment repositories. To do this you can just enable multiple profiles in your config server’s application properties or YAML file. If, for example, you want to pull configuration data from a Git repository as well as a SVN repository you would set the following properties for your @@ -514,7 +528,7 @@ must implement the EnvironmentRepository interface. the priority of you 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 then your -EnvironmentRepository will be given the lowest priority.

2.1.7 Property Overrides

The Config Server has an "overrides" feature that allows the operator +EnvironmentRepository will be given the lowest priority.

2.1.8 Property Overrides

The Config Server has an "overrides" feature that allows the operator to provide configuration properties to all applications that cannot be accidentally changed by the application using the normal Spring Boot hooks. To declare overrides just add a map of name-value pairs to diff --git a/spring-cloud-config.xml b/spring-cloud-config.xml index 48dc5d93..91402c36 100644 --- a/spring-cloud-config.xml +++ b/spring-cloud-config.xml @@ -659,7 +659,7 @@ certificates, and more. 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 quickstart guide. -To enable the config server to use a Vault backend you must run your config server +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 will assume your Vault server is running at @@ -788,10 +788,29 @@ all applications by placing configuration in foo and baz available to them. +

+JDBC Backend +Spring Cloud Config Server supports JDBC (relation 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. Spring Boot +will configure a data source if you include the right dependencies on +the classpath (see the user guide for more details on that). +The database needs to have a table called "PROPERTIES" with columns +"APPLICATION", "PROFILE", "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 (i.e. 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 this just enable +environment repositories. To do this you can just enable multiple profiles in your config server’s application properties or YAML file. If, for example, you want to pull configuration data from a Git repository as well as a SVN repository you would set the following properties for your