diff --git a/multi/multi__spring_cloud_config_server.html b/multi/multi__spring_cloud_config_server.html
index f2198e02..8c575522 100644
--- a/multi/multi__spring_cloud_config_server.html
+++ b/multi/multi__spring_cloud_config_server.html
@@ -39,7 +39,8 @@ Precedence rules for profiles are also the same as in a regular Spring Boot appl
If the YAML files have documents inside them that point to Spring profiles, those are applied with higher precedence (in order of the profiles listed).
If there are profile-specific YAML (or properties) files, these are also applied with higher precedence than the defaults.
Higher precedence translates to a PropertySource listed earlier in the Environment.
-(These same rules apply in a standalone Spring Boot application.)
The default implementation of EnvironmentRepository uses a Git backend, which is very convenient for managing upgrades and physical
+(These same rules apply in a standalone Spring Boot application.)
You can set spring.cloud.config.server.accept-empty to false so that Server would return a HTTP 404 status, if the application is not found.By default, this flag is set to true. +==== Git Backend
The default implementation of EnvironmentRepository uses a Git backend, which is very convenient for managing upgrades and physical
environments and for auditing changes.
To change the location of the repository, you can set the spring.cloud.config.server.git.uri configuration property in the Config Server (for example in application.yml).
If you set it with a file: prefix, it should work from a local repository so that you can get started quickly and easily without a server. However, in that case, the server operates directly on the local repository without cloning it (it does not matter if it is not bare because the Config Server never makes changes to the "remote" repository).
@@ -49,7 +50,7 @@ If the git branch or tag name contains a slash (/),
For example, if the label is foo/bar, replacing the slash would result in the following label: foo($$_$$)bar.
The inclusion of the special string ($$_$$) can also be applied to the {application} parameter.
If you use a command-line client such as curl, be careful with the brackets in the URL — you should
-escape them from the shell with single quotes ('').
Spring Cloud Config Server supports a git repository URL with placeholders for the {application} and {profile} (and {label} if you need it, but remember that the label is applied as a git label anyway).
+escape them from the shell with single quotes ('').
Spring Cloud Config Server supports a git repository URL with placeholders for the {application} and {profile} (and {label} if you need it, but remember that the label is applied as a git label anyway).
So you can support a “one repository per application” policy by using a structure similar to the following:
spring: cloud: config: @@ -62,7 +63,7 @@ organizations, as shown in the following example:config: server: git: - uri: https://github.com/{application}where
{application}is provided at request time in the following format:organization($$_$$)application.
Spring Cloud Config also includes support for more complex requirements with pattern + uri: https://github.com/{application}
where {application} is provided at request time in the following format: organization($$_$$)application.
Spring Cloud Config also includes support for more complex requirements with pattern
matching on the application and profile name.
The pattern format is a comma-separated list of {application}/{profile} names with wildcards (note that a pattern beginning with a wildcard may need to be quoted), as shown in the following example:
spring: cloud: @@ -126,7 +127,7 @@ The server can be configured to clone the repositories at startup, as shown in t uri: http://git/team-a/config-repo.git
In the preceding example, the server clones team-a’s config-repo on startup, before it accepts any requests. All other repositories are not cloned until configuration from the repository is requested.
![]() | Note |
|---|---|
Setting a repository to be cloned when the Config Server starts up can help to identify a misconfigured configuration source (such as an invalid repository URI) quickly, while the Config Server is starting up.
-With |
To use HTTP basic authentication on the remote repository, add the username and password properties separately (not in the URL), as shown in the following example:
spring:
+With cloneOnStart not enabled for a configuration source, the Config Server may start successfully with a misconfigured or invalid configuration source and not detect an error until an application requests configuration from that configuration source.To use HTTP basic authentication on the remote repository, add the username and password properties separately (not in the URL), as shown in the following example:
spring: cloud: config: server: @@ -140,13 +141,13 @@ To avoid surprises, you should ensure that only one entry is present in theknown_hosts file. The repository is accessed by using JGit, so any documentation you find on that should be applicable. HTTPS proxy settings can be set in ~/.git/configor (in the same way as for any other JVM process) with -system properties (-Dhttps.proxyHostand-Dhttps.proxyPort).
Tip If you do not know where your
~/.gitdirectory is, usegit config --globalto manipulate the settings (for example,git config --global http.sslVerify false).
Spring Cloud Config Server also supports AWS CodeCommit authentication.
+system properties (-Dhttps.proxyHost and -Dhttps.proxyPort).
![]() | Tip |
|---|---|
If you do not know where your |
Spring Cloud Config Server also supports AWS CodeCommit authentication. AWS CodeCommit uses an authentication helper when using Git from the command line. This helper is not used with the JGit library, so a JGit CredentialProvider for AWS CodeCommit is created if the Git URI matches the AWS CodeCommit pattern. AWS CodeCommit URIs follow this pattern://git-codecommit.${AWS_REGION}.amazonaws.com/${repopath}.
If you provide a username and password with an AWS CodeCommit URI, they must be the AWS accessKeyId and secretAccessKey that provide access to the repository. If you do not specify a username and password, the accessKeyId and secretAccessKey are retrieved by using the AWS Default Credential Provider Chain.
If your Git URI matches the CodeCommit URI pattern (shown earlier), you must provide valid AWS credentials in the username and password or in one of the locations supported by the default credential provider chain. AWS EC2 instances may use IAM Roles for EC2 Instances.
![]() | Note |
|---|---|
The |
By default, the JGit library used by Spring Cloud Config Server uses SSH configuration files such as ~/.ssh/known_hosts and /etc/ssh/ssh_config when connecting to Git repositories by using an SSH URI.
+If the aws-java-sdk-core jar is not on your classpath, the AWS Code Commit credential provider is not created, regardless of the git server URI.
By default, the JGit library used by Spring Cloud Config Server uses SSH configuration files such as ~/.ssh/known_hosts and /etc/ssh/ssh_config when connecting to Git repositories by using an SSH URI.
In cloud environments such as Cloud Foundry, the local filesystem may be ephemeral or not easily accessible.
For those cases, SSH configuration can be set by using Java properties.
In order to activate property-based SSH configuration, the spring.cloud.config.server.git.ignoreLocalSshSettings property must be set to true, as shown in the following example:
spring:
@@ -185,7 +186,7 @@ In order to activate property-based SSH configuration, the 69pcVH/4rmLbXdcmNYGm6iu+MlPQk4BUZknHSmVHIFdJ0EPupVaQ8RHT
- -----END RSA PRIVATE KEY-----The following table describes the SSH configuration properties.
Table 2.1. SSH Configuration Properties
| Property Name | Remarks |
|---|---|
ignoreLocalSshSettings | If |
privateKey | Valid SSH private key. Must be set if |
hostKey | Valid SSH host key. Must be set if |
hostKeyAlgorithm | One of |
strictHostKeyChecking |
|
knownHostsFile | Location of custom |
preferredAuthentications | Override server authentication method order. This should allow for evading login prompts if server has keyboard-interactive authentication before the |
Spring Cloud Config Server also supports a search path with placeholders for the {application} and {profile} (and {label} if
+ -----END RSA PRIVATE KEY-----
The following table describes the SSH configuration properties.
Table 2.1. SSH Configuration Properties
| Property Name | Remarks |
|---|---|
ignoreLocalSshSettings | If |
privateKey | Valid SSH private key. Must be set if |
hostKey | Valid SSH host key. Must be set if |
hostKeyAlgorithm | One of |
strictHostKeyChecking |
|
knownHostsFile | Location of custom |
preferredAuthentications | Override server authentication method order. This should allow for evading login prompts if server has keyboard-interactive authentication before the |
Spring Cloud Config Server also supports a search path with placeholders for the {application} and {profile} (and {label} if
you need it), as shown in the following example:
spring: cloud: config: @@ -193,7 +194,7 @@ you need it), as shown in the following example:git: uri: https://github.com/spring-cloud-samples/config-repo searchPaths: '{application}'The preceding listing causes a search of the repository for files in the same name as the directory (as well as the top level). -Wildcards are also valid in a search path with placeholders (any matching directory is included in the search).
As mentioned earlier, Spring Cloud Config Server makes a clone of the remote git repository in case the local copy gets dirty (for example, +Wildcards are also valid in a search path with placeholders (any matching directory is included in the search).
As mentioned earlier, Spring Cloud Config Server makes a clone of the remote git repository in case the local copy gets dirty (for example, folder content changes by an OS process) such that Spring Cloud Config Server cannot update the local copy from remote repository.
To solve this issue, there is a force-pull property that makes Spring Cloud Config Server force pull from the remote repository if the local copy is dirty, as shown in the following example:
spring: cloud: config: @@ -218,7 +219,7 @@ folder content changes by an OS process) such that Spring Cloud Config Server ca force-pull: true team-c: pattern: team-c-* - uri: http://git/team-a/config-repo.git
![]() | Note |
|---|---|
The default value for |
As Spring Cloud Config Server has a clone of the remote git repository + uri: http://git/team-a/config-repo.git
![]() | Note |
|---|---|
The default value for |
As Spring Cloud Config Server has a clone of the remote git repository after check-outing branch to local repo (e.g fetching properties by label) it will keep this branch forever or till the next server restart (which creates new local repo). So there could be a case when remote branch is deleted but local copy of it is still available for fetching. @@ -231,12 +232,12 @@ Example:
server: git: uri: https://github.com/spring-cloud-samples/config-repo - deleteUntrackedBranches: true
![]() | Note |
|---|---|
The default value for |
![]() | Warning | |||||
|---|---|---|---|---|---|---|
With VCS-based backends (git, svn), files are checked out or cloned to the local filesystem. + deleteUntrackedBranches: true
There is also a “native” profile in the Config Server that does not use Git but loads the config files from the local classpath or file system (any static URL you want to point to with |
There is also a “native” profile in the Config Server that does not use Git but loads the config files from the local classpath or file system (any static URL you want to point to with spring.cloud.config.server.native.searchLocations).
To use the native profile, launch the Config Server with spring.profiles.active=native.
![]() | Note |
|---|---|
Remember to use the |
![]() | Warning | ||
|---|---|---|---|
The default value of the If you do not use placeholders in the search locations, this repository also appends the Spring Cloud Config Server also supports Vault as a backend. Spring Cloud Config Server also supports Vault as a backend. 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 By default, the config server assumes that your Vault server runs at Properties written to Sharing configuration between all applications varies according to which approach you take, as described in the following topics: With file-based (git, svn, and native) repositories, resources with file names in Sharing configuration between all applications varies according to which approach you take, as described in the following topics: With file-based (git, svn, and native) repositories, resources with file names in The #_property_overrides[property overrides] feature can also be used for setting global defaults, with placeholders applications allowed to override them locally.
When using Vault as a backend, you can share configuration with all applications by placing configuration in $ vault write secret/application foo=bar baz=bam 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 $ vault write secret/application foo=bar baz=bam Spring Cloud Config Server supports JDBC (relational database) as a backend for configuration properties.
You can enable this feature by adding The database needs to have a table called In some scenarios, you may wish to pull configuration data from multiple environment repositories.
+Property values behave in the same way as they would if they came from Spring Boot properties files named In some scenarios, you may wish to pull configuration data from multiple environment repositories. To do so, you can 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 an SVN repository, you can set the following properties for your configuration server: spring: profiles: @@ -310,7 +311,7 @@ The priority order of a repository helps resolve any potential conflicts between If you have an environment similar to the one in the preceding example and you request configuration data with the |
In addition to using one of the environment repositories from Spring Cloud, you can also provide your own EnvironmentRepository bean to be included as part of a composite environment.
To do so, your bean must implement the EnvironmentRepository interface.
If you want to control the priority of your custom EnvironmentRepository within the composite environment, you should also implement the Ordered interface and override the getOrdered method.
-If you do not implement the Ordered interface, your EnvironmentRepository is given the lowest priority.
The Config Server has an “overrides” feature that lets the operator provide configuration properties to all applications.
+If you do not implement the Ordered interface, your EnvironmentRepository is given the lowest priority.
The Config Server has an “overrides” feature that lets the operator provide configuration properties to all applications.
The overridden properties cannot be accidentally changed by the application with the normal Spring Boot hooks.
To declare overrides, add a map of name-value pairs to spring.cloud.config.server.overrides, as shown in the following example:
spring: cloud: diff --git a/multi/multi_spring-cloud-config.html b/multi/multi_spring-cloud-config.html index 596c842f..6f3d976e 100644 --- a/multi/multi_spring-cloud-config.html +++ b/multi/multi_spring-cloud-config.html @@ -1,3 +1,3 @@ -Spring Cloud Config \ No newline at end of file +Table of Contents
- 1. Quick Start
- 2. Spring Cloud Config Server
- 2.1. Environment Repository
- 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
Spring Cloud Config Table of Contents
- 1. Quick Start
- 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
- 2.1.12. Sharing Configuration With All Applications
- 2.1.13. JDBC Backend
- 2.1.14. 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