diff --git a/multi/multi__spring_cloud_config_server.html b/multi/multi__spring_cloud_config_server.html index e5c9ed60..6fc7a844 100644 --- a/multi/multi__spring_cloud_config_server.html +++ b/multi/multi__spring_cloud_config_server.html @@ -301,7 +301,20 @@ Example:

                force-pull: true
             team-c:
                 pattern: team-c-*
-                uri: http://git/team-a/config-repo.git
[Note]Note

The default value for force-pull 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. 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. This can lead to unexpected behaviour such as missing properties. To avoid this problem, change the directory Config Server uses, by setting spring.cloud.config.server.git.basedir or spring.cloud.config.server.svn.basedir to a directory that does not reside in the system temp structure.

2.1.3 File System Backend

There is also a "native" profile in the Config Server that doesn’t use + uri: http://git/team-a/config-repo.git

[Note]Note

The default value for force-pull property is false.

Deleting untracked branches in Git Repositories

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. +And if Spring Cloud Config Server client service starts with --spring.cloud.config.label=deletedRemoteBranch,master +it will fetch properties from deletedRemoteBranch local branch, but not from master.

In order to keep local repository branches clean and up to remote - deleteUntrackedBranches property could be set. +It will make Spring Cloud Config Server force delete untracked branches from local repository. +Example:

spring:
+  cloud:
+    config:
+      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. 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. This can lead to unexpected behaviour such as missing properties. To avoid this problem, change the directory Config Server uses, by setting spring.cloud.config.server.git.basedir or spring.cloud.config.server.svn.basedir to a directory that does not reside in the system temp structure.

2.1.3 File System Backend

There is also a "native" profile in the Config Server that doesn’t use Git, but just 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 diff --git a/multi/multi_spring-cloud-config.html b/multi/multi_spring-cloud-config.html index 266ff3f9..09455401 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. 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 + 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
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. 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 30b820d9..286d5538 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. 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

2.0.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
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. 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
2.0.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
@@ -403,7 +403,20 @@ Example:
                force-pull: true
             team-c:
                 pattern: team-c-*
-                uri: http://git/team-a/config-repo.git
[Note]Note
The default value for force-pull 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. 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. This can lead to unexpected behaviour such as missing properties. To avoid this problem, change the directory Config Server uses, by setting spring.cloud.config.server.git.basedir or spring.cloud.config.server.svn.basedir to a directory that does not reside in the system temp structure.
2.1.3 File System Backend
There is also a "native" profile in the Config Server that doesn’t use
+                uri: http://git/team-a/config-repo.git
[Note]Note

The default value for force-pull property is false.

Deleting untracked branches in Git Repositories

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. +And if Spring Cloud Config Server client service starts with --spring.cloud.config.label=deletedRemoteBranch,master +it will fetch properties from deletedRemoteBranch local branch, but not from master.

In order to keep local repository branches clean and up to remote - deleteUntrackedBranches property could be set. +It will make Spring Cloud Config Server force delete untracked branches from local repository. +Example:

spring:
+  cloud:
+    config:
+      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. 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. This can lead to unexpected behaviour such as missing properties. To avoid this problem, change the directory Config Server uses, by setting spring.cloud.config.server.git.basedir or spring.cloud.config.server.svn.basedir to a directory that does not reside in the system temp structure.

2.1.3 File System Backend

There is also a "native" profile in the Config Server that doesn’t use Git, but just 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 diff --git a/spring-cloud-config.xml b/spring-cloud-config.xml index 2b967c4a..09fe31e2 100644 --- a/spring-cloud-config.xml +++ b/spring-cloud-config.xml @@ -610,6 +610,28 @@ Example: The default value for force-pull property is false. +

+Deleting untracked branches in Git Repositories +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. +And if Spring Cloud Config Server client service starts with --spring.cloud.config.label=deletedRemoteBranch,master +it will fetch properties from deletedRemoteBranch local branch, but not from master. +In order to keep local repository branches clean and up to remote - deleteUntrackedBranches property could be set. +It will make Spring Cloud Config Server force delete untracked branches from local repository. +Example: +spring: + cloud: + config: + server: + git: + uri: https://github.com/spring-cloud-samples/config-repo + deleteUntrackedBranches: true + +The default value for deleteUntrackedBranches property is false. + +
Version Control Backend Filesystem Use