diff --git a/spring-cloud-config/1.0.4.RELEASE/ghpages.sh b/spring-cloud-config/1.0.4.RELEASE/ghpages.sh new file mode 100644 index 00000000..e1063ce3 --- /dev/null +++ b/spring-cloud-config/1.0.4.RELEASE/ghpages.sh @@ -0,0 +1,54 @@ +#!/bin/bash -x + +git remote set-url --push origin `git config remote.origin.url | sed -e 's/^git:/https:/'` + +if ! (git remote set-branches --add origin gh-pages && git fetch -q); then + echo "No gh-pages, so not syncing" + exit 0 +fi + +if ! [ -d docs/target/generated-docs ]; then + echo "No gh-pages sources in docs/target/generated-docs, so not syncing" + exit 0 +fi + +# Find name of current branch +################################################################### +branch=$TRAVIS_BRANCH +[ "$branch" == "" ] && branch=`git rev-parse --abbrev-ref HEAD` +target=. +if [ "$branch" != "master" ]; then target=./$branch; mkdir -p $target; fi + +# Stash any outstanding changes +################################################################### +git diff-index --quiet HEAD +dirty=$? +if [ "$dirty" != "0" ]; then git stash; fi + +# Switch to gh-pages branch to sync it with current branch +################################################################### +git checkout gh-pages + +for f in docs/target/generated-docs/*; do + file=${f#docs/target/generated-docs/*} + if ! git ls-files -i -o --exclude-standard --directory | grep -q ^$file$; then + # Not ignored... + cp -rf $f $target + git add -A $target/$file + fi +done + +git add -A README.adoc || echo "No change to README.adoc" +git commit -a -m "Sync docs from $branch to gh-pages" || echo "Nothing committed" + +# Uncomment the following push if you want to auto push to +# the gh-pages branch whenever you commit to branch locally. +# This is a little extreme. Use with care! +################################################################### +git push origin gh-pages || echo "Cannot push gh-pages" + +# Finally, switch back to the current branch and exit block +git checkout $branch +if [ "$dirty" != "0" ]; then git stash pop; fi + +exit 0 diff --git a/spring-cloud-config/1.0.4.RELEASE/index.html b/spring-cloud-config/1.0.4.RELEASE/index.html new file mode 100644 index 00000000..35e81dbd --- /dev/null +++ b/spring-cloud-config/1.0.4.RELEASE/index.html @@ -0,0 +1,1418 @@ + + + + + + + +Spring Cloud Config + + + + + +
+
+
+
+

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.

+
+
+

https://raw.githubusercontent.com/spring-cloud/spring-cloud-build/master/docs/src/main/asciidoc/contributing-docs.adoc

+
+
+
+
+

Quick Start

+
+
+

Start the server:

+
+
+
+
$ cd spring-cloud-config-server
+$ mvn spring-boot:run
+
+
+
+

The server is a Spring Boot application so you can build the jar file +and run that (java -jar …​) or pull it down from a Maven +repository. Then try it out as a client:

+
+
+
+
$ curl localhost:8888/foo/development
+{"name":"development","label":"master","propertySources":[
+  {"name":"https://github.com/scratches/config-repo/foo-development.properties","source":{"bar":"spam"}},
+  {"name":"https://github.com/scratches/config-repo/foo.properties","source":{"foo":"bar"}}
+]}
+
+
+
+

The default strategy for locating property sources is to clone a git +repository (at "spring.cloud.config.server.git.uri") and use it to +initialize a mini SpringApplication. The mini-application’s +Environment is used to enumerate property sources and publish them +via a JSON endpoint.

+
+
+

The HTTP service has resources in the form:

+
+
+
+
/{application}/{profile}[/{label}]
+/{application}-{profile}.yml
+/{label}/{application}-{profile}.yml
+/{application}-{profile}.properties
+/{label}/{application}-{profile}.properties
+
+
+
+

where the "application" is injected as the "spring.config.name" in the +SpringApplication (i.e. what is normally "application" in a regular +Spring Boot app), "profile" is an active profile (or comma-separated +list of properties), and "label" is an optional git label (defaults to +"master".)

+
+
+

The YAML and properties forms are coalesced into a single +map, even if the origin of the values (reflected in the +"propertySources" of the "standard" form) has multiple sources.

+
+
+

Spring Cloud Config Server pulls configuration for remote clients +from a git repository (which must be provided):

+
+
+
+
spring:
+  cloud:
+    config:
+	  server:
+	    git:
+	      uri: https://github.com/spring-cloud-samples/config-repo
+
+
+
+

Client Side Usage

+
+

To use these features in an application, just build it as a Spring +Boot application that depends on spring-cloud-config-client (e.g. see +the test cases for the config-client, or the sample app). The most +convenient way to add the dependency is via a Spring Boot starter +org.springframework.cloud:spring-cloud-starter-config. There is also a +parent pom and BOM (spring-cloud-starter-parent) for Maven users and a +Spring IO version management properties file for Gradle and Spring CLI +users. Example Maven configuration:

+
+
+
pom.xml
+
+
<parent>
+    <groupId>org.springframework.boot</groupId>
+    <artifactId>spring-boot-starter-parent</artifactId>
+    <version>1.2.3.RELEASE</version>
+    <relativePath /> <!-- lookup parent from repository -->
+</parent>
+
+<dependencyManagement>
+    <dependencies>
+        <dependency>
+            <groupId>org.springframework.cloud</groupId>
+            <artifactId>spring-cloud-starter-parent</artifactId>
+            <version>1.0.1.RELEASE</version>
+            <type>pom</type>
+            <scope>import</scope>
+        </dependency>
+    </dependencies>
+</dependencyManagement>
+
+<dependencies>
+    <dependency>
+        <groupId>org.springframework.cloud</groupId>
+        <artifactId>spring-cloud-starter-config</artifactId>
+    </dependency>
+    <dependency>
+        <groupId>org.springframework.boot</groupId>
+        <artifactId>spring-boot-starter-test</artifactId>
+        <scope>test</scope>
+    </dependency>
+</dependencies>
+
+<build>
+    <plugins>
+        <plugin>
+            <groupId>org.springframework.boot</groupId>
+            <artifactId>spring-boot-maven-plugin</artifactId>
+        </plugin>
+    </plugins>
+</build>
+
+<!-- repositories also needed for snapshots and milestones -->
+
+
+
+

Then you can create a standard Spring Boot application, like this simple HTTP server:

+
+
+
+
@Configuration
+@EnableAutoConfiguration
+@RestController
+public class Application {
+
+    @RequestMapping("/")
+    public String home() {
+        return "Hello World!";
+    }
+
+    public static void main(String[] args) {
+        SpringApplication.run(Application.class, args);
+    }
+
+}
+
+
+
+

When it runs it will pick up the external configuration from the +default local config server on port 8888 if it is running. To modify +the startup behaviour you can change the location of the config server +using bootstrap.properties (like application.properties but for +the bootstrap phase of an application context), e.g.

+
+
+
+
spring.cloud.config.uri: http://myconfigserver.com
+
+
+
+

The bootstrap properties will show up in the /env endpoint as a +high-priority property source, e.g.

+
+
+
+
$ curl localhost:8080/env
+{
+  "profiles":[],
+  "configService:https://github.com/spring-cloud-samples/config-repo/bar.properties":{"foo":"bar"},
+  "servletContextInitParams":{},
+  "systemProperties":{...},
+  ...
+}
+
+
+
+

(a property source called "configService:<URL of remote +repository>/<file name>" contains the property "foo" with value +"bar" and is highest priority).

+
+
+ + + + + +
+
Note
+		 +the URL in the property source name is the git repository not +the config server URL. +
+
+
+
+
+
+

Spring Cloud Config Server

+
+
+

The Server provides an HTTP, resource-based API for external +configuration (name-value pairs, or equivalent YAML content). The +server is easily embeddable in a Spring Boot application using the +@EnableConfigServer annotation.

+
+
+

Environment Repository

+
+

Where do you want to store the configuration data for the Config +Server? The strategy that governs this behaviour is the +EnvironmentRepository, serving Environment objects. This +Environment is a shallow copy of the domain from the Spring +Environment (including propertySources as the main feature). The +Environment resources are parametrized by three variables:

+
+
+
    +
  • +

    {application} maps to "spring.application.name" on the client side;

    +
    • +
  • +

    {profile} maps to "spring.active.profiles" on the client (comma separated list); and

    +
    • +
  • +

    {label} which is a server side feature labelling a "versioned" set of config files.

    +
    • +
+
+
+

Repository implementations generally behave just like a Spring Boot +application loading configuration files from a "spring.config.name" +equal to the {application} parameter, and "spring.profiles.active" +equal to the {profiles} parameter. Precedence rules for profiles are +also the same as in a regular Boot application: active profiles take +precedence over defaults, and if there are multiple profiles the last +one wins (like adding entries to a Map).

+
+
+

Example: a client application has this bootstrap configuration:

+
+
+
bootstrap.yml
+
+
spring:
+  application:
+    name: foo
+  profiles:
+    active: dev,mysql
+
+
+
+

(as usual with a Spring Boot application, these properties could also +be set as environment variables or command line arguments).

+
+
+

If the repository is file-based, the server will create an +Environment from application.yml (shared between all clients), and +foo.yml (with foo.yml taking precedence). If the YAML files have +documents inside them that point to Spring profiles, those are applied +with higher precendence (in order of the profiles listed), and if +there are profile-specific YAML (or properties) files these are also +applied with higher precedence than the defaults. Higher precendence +translates to a PropertySource listed earlier in the +Environment. (These are the same rules as apply in a standalone +Spring Boot application.)

+
+
+

Git Backend

+
+

The default implementation of EnvironmentRepository uses a Git +backend, which is very convenient for managing upgrades and physical +environments, and also 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 (e.g. in +application.yml). If you set it with a file: prefix it should work +from a local repository so you can get started quickly and easily +without a server, but in that case the server operates directly on the +local repository without cloning it (it doesn’t matter if it’s not +bare because the Config Server never makes changes to the "remote" +repository). To scale the Config Server up and make it highly +available, you would need to have all instances of the server pointing +to the same repository, so only a shared file system would work. Even +in that case it is better to use the ssh: protocol for a shared +filesystem repository, so that the server can clone it and use a local +working copy as a cache.

+
+
+

This repository implementation maps the {label} parameter of the +HTTP resource to a git label (commit id, branch name or tag). If the +git branch or tag name contains a slash ("/") then the label in the +HTTP URL should be specified with the special string "(_)" instead (to +avoid ambiguity with other URL paths). Be careful with the brackets in +the URL if you are using a command line client like curl (e.g. escape +them from the shell with quotes '').

+
+
+

Spring Cloud Config Server supports a single or multiple git +repositories:

+
+
+
+
spring:
+  cloud:
+    config:
+      server:
+        git:
+          uri: https://github.com/spring-cloud-samples/config-repo
+          repos:
+            simple: https://github.com/simple/config-repo
+            special:
+              pattern: pattern*,*pattern1*
+              uri: https://github.com/special/config-repo
+            local:
+              pattern: local*
+              uri: file:/home/configsvc/config-repo
+
+
+
+

In the above example, if {application} does not match any of the +patterns, it will use the default uri defined under +"spring.cloud.config.server.git.uri". For the "simple" repository, the +pattern is "simple" (i.e. it only matches one application named "simple"). +The pattern format is a comma-separated list of application names with +wildcards (a pattern beginning with a wildcard may need to be quoted).

+
+
+ + + + + +
+
Note
+		 +the "one-liner" short cut used in the "simple" example above can +only be used if the only property to be set is the URI. If you need to +set anything else (credentials, pattern, etc.) you need to use the full +form. +
+
+
+

Every repository can also optionally store config files in +sub-directories, and patterns to search for those directories can be +specified as searchPaths. For example at the top level:

+
+
+
+
spring:
+  cloud:
+    config:
+      server:
+        git:
+          uri: https://github.com/spring-cloud-samples/config-repo
+          searchPaths: foo,bar*
+
+
+
+

In this example the server searches for config files in the top level +and in the "foo/" sub-directory and also any sub-directory whose name +begins with "bar".

+
+
+

By default the server clones remote repositories when configuration +is first requested. The server can be configured to clone the repositories +at startup. For example at the top level:

+
+
+
+
spring:
+  cloud:
+    config:
+      server:
+        git:
+          uri: https://git/common/config-repo.git
+          repos:
+            team-a:
+                pattern: team-a-*
+                cloneOnStart: true
+                uri: http://git/team-a/config-repo.git
+            team-b:
+                pattern: team-b-*
+                cloneOnStart: false
+                uri: http://git/team-b/config-repo.git
+            team-c:
+                pattern: team-c-*
+                uri: http://git/team-a/config-repo.git
+
+
+
+

In this example the server clones team-a’s config-repo on startup before it +accepts any requests. All other repositories will not be cloned until +configuration from the repository is requested.

+
+
+

To use HTTP basic authentication on the remote repository add the +"username" and "password" properties separately (not in the URL), +e.g.

+
+
+
+
spring:
+  cloud:
+    config:
+      server:
+        git:
+          uri: https://github.com/spring-cloud-samples/config-repo
+          username: trolley
+          password: strongpassword
+
+
+
+

If you don’t use HTTPS and user credentials, SSH should also work out +of the box when you store keys in the default directories (~/.ssh) +and the uri points to an SSH location, +e.g. "git@github.com:configuration/cloud-configuration". The +repository is accessed using JGit, so any documentation you find on +that should be applicable.

+
+
+
+

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 native +profile just launch the Config Server with +"spring.profiles.active=native".

+
+
+ + + + + +
+
Warning
+		 +The default value of the searchLocations is identical to a +local Spring Boot application (so +[classpath:/, classpath:/config, file:./, file:./config]) which will +expose the application.properties from the server to all clients. +
+
+
+ + + + + +
+
Tip
+		 +A filesystem backend is great for getting started quickly and +for testing. To use it in production you need to be sure that the +file system is reliable, and shared across all instances of the +Config Server. +
+
+
+

This repository implementation maps the {label} parameter of the +HTTP resource to a suffix on the search path, so properties files are +loaded from each search location and a subdirectory with the same +name as the label (the labelled properties take precedence in the +Spring Environment).

+
+
+
+
+

Health Indicator

+
+

Config Server comes with a Health Indicator that checks if the configured +EnvironmentRepository is working. By default it asks the EnvironmentRepository +for an application named app, the default profile and the default +label provided by the EnvironmentRepository implementation.

+
+
+

You can configure the Health Indicator to check more applications +along with custom profiles and custom labels, e.g.

+
+
+
+
spring:
+  cloud:
+    config:
+      server:
+        health:
+          repositories:
+            myservice:
+              label: mylabel
+            myservice-dev:
+              name: myservice
+              profiles: development
+
+
+
+

You can disable the Health Indicator by setting spring.cloud.config.server.health.enabled=false.

+
+
+
+

Security

+
+

You are free to secure your Config Server in any way that makes sense +to you (from physical network security to OAuth2 bearer +tokens), and Spring Security and Spring Boot make it easy to do pretty +much anything.

+
+
+

To use the default Spring Boot configured HTTP Basic security, just +include Spring Security on the classpath (e.g. through +spring-boot-starter-security). The default is a username of "user" +and a randomly generated password, which isn’t going to be very useful +in practice, so we recommend you configure the password (via +security.user.password) and encrypt it (see below for instructions +on how to do that).

+
+
+
+

Encryption and Decryption

+
+ + + + + +
+
Important
+		 +Prerequisites: to use the encryption and decryption features +you need the full-strength JCE installed in your JVM (it’s not there by default). +You can download the "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files" +from Oracle, and follow instructions for installation (essentially replace the 2 policy files +in the JRE lib/security directory with the ones that you downloaded). +
+
+
+

If the remote property sources contain encryted content +(values starting with {cipher}) they will be decrypted before +sending to clients over HTTP. The main advantage of this set up is +that the property values don’t have to be in plain text when they are +"at rest" (e.g. in a git repository). If a value cannot be decrypted +it is replaced with an empty string, largely to prevent cipher text +being used as a password and accidentally leaking.

+
+
+

If you are setting up a remote config repository for config client +applications it might contain an application.yml like this, for +instance:

+
+
+
application.yml
+
+
spring:
+  datasource:
+    username: dbuser
+    password: '{cipher}FKSAJDFGYOS8F7GLHAKERGFHLSAJ'
+
+
+
+

You can safely push this plain text to a shared git repository and the +secret password is protected.

+
+
+

The server also exposes /encrypt and /decrypt endpoints (on the +assumption that these will be secured and only accessed by authorized +agents). If you are editing a remote config file you can use the Config Server +to encrypt values by POSTing to the /encrypt endpoint, e.g.

+
+
+
+
$ curl localhost:8888/encrypt -d mysecret
+682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda
+
+
+
+

The inverse operation is also available via /decrypt (provided the server is +configured with a symmetric key or a full key pair):

+
+
+
+
$ curl localhost:8888/decrypt -d 682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda
+mysecret
+
+
+
+

Take the encypted value and add the {cipher} prefix before you put +it in the YAML or properties file, and before you commit and push it +to a remote, potentially insecure store. The /encypt and /decrypt +endpoints also both accept paths of the form /*/{name}/{profiles} +which can be used to control cryptography per application (name) +and profile when clients call into the main Environment resource.

+
+
+ + + + + +
+
Note
+		 +to control the cryptography in this granular way you must also +provide a @Bean of type TextEncryptorLocator that creates a +different encryptor per name and profiles. The one that is provided +by default does not do this. +
+
+
+

The spring command line client (with Spring Cloud CLI extensions +installed) can also be used to encrypt and decrypt, e.g.

+
+
+
+
$ spring encrypt mysecret --key foo
+682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda
+$ spring decrypt --key foo 682bc583f4641835fa2db009355293665d2647dade3375c0ee201de2a49f7bda
+mysecret
+
+
+
+

To use a key in a file (e.g. an RSA public key for encyption) prepend +the key value with "@" and provide the file path, e.g.

+
+
+
+
$ spring encrypt mysecret --key @${HOME}/.ssh/id_rsa.pub
+AQAjPgt3eFZQXwt8tsHAVv/QHiY5sI2dRcR+...
+
+
+
+

The key argument is mandatory (despite having a -- prefix).

+
+
+
+

Key Management

+
+

The Config Server can use a symmetric (shared) key or an asymmetric +one (RSA key pair). The asymmetric choice is superior in terms of +security, but it is often more convenient to use a symmetric key since +it is just a single property value to configure.

+
+
+

To configure a symmetric key you just need to set encrypt.key to a +secret String (or use an enviroment variable ENCRYPT_KEY to keep it +out of plain text configuration files).

+
+
+

To configure an asymmetric key you can either set the key as a +PEM-encoded text value (in encrypt.key), or via a keystore (e.g. as +created by the keytool utility that comes with the JDK). The +keystore properties are encrypt.keyStore.* with * equal to

+
+
+
    +
  • +

    location (a Resource location),

    +
    • +
  • +

    password (to unlock the keystore) and

    +
    • +
  • +

    alias (to identify which key in the store is to be +used).

    +
    • +
+
+
+

The encryption is done with the public key, and a private key is +needed for decryption. Thus in principle you can configure only the +public key in the server if you only want to do encryption (and are +prepared to decrypt the values yourself locally with the private +key). In practice you might not want to do that because it spreads the +key management process around all the clients, instead of +concentrating it in the server. On the other hand it’s a useful option +if your config server really is relatively insecure and only a +handful of clients need the encrypted properties.

+
+
+
+

Creating a Key Store for Testing

+
+

To create a keystore for testing you can do something like this:

+
+
+
+
$ keytool -genkeypair -alias mytestkey -keyalg RSA \
+  -dname "CN=Web Server,OU=Unit,O=Organization,L=City,S=State,C=US" \
+  -keypass changeme -keystore server.jks -storepass letmein
+
+
+
+

Put the server.jks file in the classpath (for instance) and then in +your application.yml for the Config Server:

+
+
+
+
encrypt:
+  keyStore:
+    location: classpath:/server.jks
+    password: letmein
+    alias: mytestkey
+    secret: changeme
+
+
+
+
+

Using Multiple Keys and Key Rotation

+
+

In addition to the {cipher} prefix in encrypted property values, the +Config Server looks for {name:value} prefixes (zero or many) before +the start of the (Base64 encoded) cipher text. The keys are passed to +a TextEncryptorLocator which can do whatever logic it needs to +locate a TextEncryptor for the cipher. If you have configured a +keystore (encrypt.keystore.location) the default locator will look +for keys in the store with aliases as supplied by the "key" prefix, +i.e. with a cipher text like this:

+
+
+
+
foo:
+  bar: `{cipher}{key:testkey}...`
+
+
+
+

the locator will look for a key named "testkey". A secret can also be +supplied via a {secret:…​} value in the prefix, but if it is not +the default is to use the keystore password (which is what you get +when you build a keytore and don’t specify a secret). If you do +supply a secret it is recommended that you also encrypt the secrets +using a custom SecretLocator.

+
+
+

Key rotation is hardly ever necessary on cryptographic grounds if the +keys are only being used to encrypt a few bytes of configuration data +(i.e. they are not being used elsewhere), but occasionally you might +need to change the keys if there is a security breach for instance. In +that case all the clients would need to change their source config +files (e.g. in git) and use a new {key:…​} prefix in all the +ciphers, checking beforehand of course that the key alias is available +in the Config Server keystore.

+
+
+ + + + + +
+
Tip
+		 +the {name:value} prefixes can also be added to plaintext posted +to the /encrypt endpoint, if you want to let the Config Server +handle all encryption as well as decryption. +
+
+
+
+

Embedding the Config Server

+
+

The Config Server runs best as a standalone application, but if you +need to you can embed it in another application. Just use the +@EnableConfigServer annotation and (optionally) set +spring.cloud.config.server.prefix to a path prefix, e.g. "/config", +to serve the resources under a prefix. The prefix should start but not +end with a "/". It is applied to the @RequestMappings in the Config +Server (i.e. underneath the Spring Boot prefixes server.servletPath +and server.contextPath). Another optional property that can be +useful in this case is spring.cloud.config.server.bootstrap which is +a flag to indicate that the server should configure itself from its +own remote repository. The flag is off by default because it can delay +startup, but when embedded in another application it makes sense to +initialize the same way as any other application.

+
+
+
+
+
+

Spring Cloud Config Client

+
+
+

A Spring Boot application can take immediate advantage of the Spring +Config Server (or other external property sources provided by the +application developer), and it will also pick up some additional +useful features related to Environment change events.

+
+
+

Config First Bootstrap

+
+

This is the default behaviour for any application which has the Spring +Cloud Config Client on the classpath. When a config client starts up +it binds to the Config Server (via the bootstrap configuration +property spring.cloud.config.uri) and initializes Spring +Environment with remote property sources.

+
+
+

The net result of this is that all client apps that want to consume +the Config Server need a bootstrap.yml (or an environment variable) +with the server address in spring.cloud.config.uri (defaults to +"http://localhost:8888").

+
+
+
+

Eureka First Bootstrap

+
+

If you are using Spring Cloud Netflix and Eureka Service Discovery, +then you can have the Config Server register with Eureka if you want +to, but in the default "Config First" mode, clients won’t be able to +take advantage of the registration.

+
+
+

If you prefer to use Eureka to locate the Config Server, you can do +that by setting spring.cloud.config.discovery.enabled=true (default +"false"). The net result of that is that client apps all need a +bootstrap.yml (or an environment variable) with the Eureka server +address, e.g. in eureka.client.serviceUrl.defaultZone. The price +for using this option is an extra network round trip on start up to +locate the service registration. The benefit is that the Config Server +can change its co-ordinates, as long as Eureka is a fixed point. The +default service id is "CONFIGSERVER" but you can change that on the +client with spring.cloud.config.discovery.serviceId (and on the server +in the usual way for a service, e.g. by setting spring.application.name).

+
+
+
+

Config Client Fail Fast

+
+

In some cases, it may be desirable to fail startup of a service if +it cannot connect to the Config Server. If this is the desired +behavior, set the bootstrap configuration property +spring.cloud.config.failFast=true and the client will halt with +an Exception.

+
+
+
+

Config Client Retry

+
+

If you expect that the config server may occasionally be unavailable when +your app starts, you can ask it to keep trying after a failure. First you need +to set spring.cloud.config.failFast=true, and then you need to add +spring-retry and spring-boot-starter-aop to your classpath. The default +behaviour is to retry 6 times with an initial backoff interval of 1000ms and an +exponential multiplier of 1.1 for subsequent backoffs. You can configure these +properties (and others) using spring.config.retry.* configuration properties.

+
+
+ + + + + +
+
Tip
+		 +To take full control of the retry add a @Bean of type +RetryOperationsInterceptor with id "configServerRetryInterceptor". Spring +Retry has a RetryInterceptorBuilder that makes it easy to create one. +
+
+
+
+

Locating Remote Configuration Resources

+
+

The Config Service serves property sources from /{name}/{profile}/{label}, where the default bindings in the client app are

+
+
+
    +
  • +

    "name" = ${spring.application.name}

    +
    • +
  • +

    "profile" = ${spring.profiles.active} (actually Environment.getActiveProfiles())

    +
    • +
  • +

    "label" = "master"

    +
    • +
+
+
+

All of them can be overridden by setting spring.cloud.config.* +(where * is "name", "profile" or "label"). The "label" is useful for +rolling back to previous versions of configuration; with the default +Config Server implementation it can be a git label, branch name or +commit id. Label can also be provided as a comma-separated list, in +which case the items in the list are tried on-by-one until one succeeds. +This can be useful when working on a feature branch, for instance, +when you might want to align the config label with your branch, but +make it optional (e.g. spring.cloud.config.label=myfeature,develop).

+
+
+
+

Security

+
+

If you use HTTP Basic security on the server then clients just need to +know the password (and username if it isn’t the default). You can do +that via the config server URI, or via separate username and password +properties, e.g.

+
+
+
bootstrap.yml
+
+
spring:
+  cloud:
+    config:
+     uri: https://user:secret@myconfig.mycompany.com
+
+
+
+

or

+
+
+
bootstrap.yml
+
+
spring:
+  cloud:
+    config:
+     uri: https://myconfig.mycompany.com
+     username: user
+     password: secret
+
+
+
+

The spring.cloud.config.password and spring.cloud.config.username +values override anything that is provided in the URI.

+
+
+

If you deploy your apps on Cloud Foundry then the best way to provide +the password is through service credentials, e.g. in the URI, since +then it doesn’t even need to be in a config file. An example which +works locally and for a user-provided service on Cloud Foundry named +"configserver":

+
+
+
bootstrap.yml
+
+
spring:
+  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 (e.g. by +grabbing it in the bootstrap context and injecting one).

+
+
+
+
+
+ + + \ No newline at end of file