Create git repos for configurations. Configurations are either properties or yaml files. Names are like below.

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

Setup properties repos are mainly based on two ways, one repo per application or one repo per profile. This demo uses one repo per profile strategy. Create the strcutre like below in your local repositories.

go to each folder development, staging and production, run following

git init git add . git commit -m "add properties file" 

The properties files are extremely simple, having only one property example.message

$ cat development/config-repo/config-client-demo.properties example.message=This is a dev properties $ cat staging/config-repo/config-client-demo.properties example.message=This is a staging properties $ cat production/config-repo/config-client-demo.properties example.message=This is a production properties 

In the example, three local git repositories are created. One is development repository, one is staging repository, the last is production repository. Based on different profile, different properties will be used.

Create project using SPRING INITIALIZR

Simplely add EnableConfigServer annotation in the main spring boot class.

@SpringBootApplication @EnableConfigServer public class ConfigServerApplication { public static void main(String[] args) { SpringApplication.run(ConfigServerApplication.class, args); } } 

We are using one repo per profile in the example. Below is the application.yml. For demo purpose, local repositories are used. For the real config-repos, change to uri to real gitserver repositories location.

server: port: 8888 # spring cloud config repo settings. spring: cloud: config: server: git: uri: https://gitserver/development/config-repo # default repo repos: development: pattern: - '*/development' - '*/qa' uri: C:\\Users\\bzhang\\git-repo\\development\\config-repo staging: pattern: - '*/staging' uri: C:\\Users\\bzhang\\git-repo\\staging\\config-repo production: pattern: - '*/production' uri: C:\\Users\\bzhang\\git-repo\\production\\config-repo local: pattern: - '*/local' uri: C:\\Users\\bzhang\\git-repo\\development\\config-repo #Disable security of the Management endpoint management: security: enabled: false 

From the application.yml above, you can see there are three repositories for different profiles. development and qa are using the same development repository, the staging and production profile has its own repository. Each repository could have its own security controls.

Except one repo per profile, you can also define your application.yml like below to demonstrate one repo per application:

spring: cloud: config: server: git: uri: https://gitserver/config-repos/{application} 

set spring.cloud.config.server.git.force-pull=true

Spring Cloud Config Server by default makes a clone of the remote git repository and if the local copy gets dirty it cannot update the local copy from remote repository. To solve this problem, there is a force-pull property that will make Spring Cloud Config Server force pull from remote repository if the local copy is dirty.

spring: cloud: config: server: git: uri: https://github.com/production/config-repo force-pull: true 

If you have a multiple repositories configuration you can configure the force-pull property per repository.

Normally, many source code repository providers (like Github) will notify you of changes in a repository through a webhook. You can configure the webhook via the provider’s user interface as a URL and a set of events in which you are interested. For instance Github will POST to the webhook with a JSON body containing a list of commits, and a header "X-Github-Event" equal to "push". If you add a dependency on the spring-cloud-config-monitor library and activate the Spring Cloud Bus : spring-cloud-starter-bus-amqp or spring-cloud-starter-bus-kafka or spring-cloud-starter-bus-redis. in your Config Server, then a "/monitor" endpoint is enabled.

 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-monitor</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-bus-redis</artifactId> <!-- or -amqp (rabbitmq) or -kafka --> </dependency> 

mvn clean install java -jar target/config-server-0.0.1-SNAPSHOT.jar 

Open browser and test those.

http://localhost:8888/config-client-demo/development http://localhost:8888/config-client-demo/staging http://localhost:8888/config-client-demo/production 

Create project using SPRING INITIALIZR

In client side, you needs to create bootstrap.properties. The bootstrap.properties allows the application connect spring cloud config server first and pulls all properties of this application when it starts. It is defined like this.

$ cat bootstrap.properties server.port=8001 spring.application.name=config-client-demo spring.profiles.active=development spring.cloud.config.uri=http://localhost:8888 management.security.enabled=true 

The yaml format is below, they are identical. Either one is fine.

$ cat bootstrap.yml server: port: 8001 spring: application: name: config-client-demo spring: profiles: active: development spring: cloud: config: uri: http://localhost:8888 management: security: enabled: true 

The application name has to match as the {application} in the git repositories.

Compile:

# compile mvn clean install # start config-client-demo application with the development profile java -jar config-client-demo.jar --spring.application.profiles=development # Test application use another console curl http://localhost:8001/message 

You should get something like this:

This is a dev properties 

Try other profiles:staging and production:

# start config-client-demo application with staging profiles java -jar config-client-demo.jar --spring.application.profiles=staging # start config-client-demo application with production profiles java -jar config-client-demo.jar --spring.application.profiles=production 

curl http://localhost:8001/message you will get for staging and production

 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> 

@RestController @RefreshScope public class MessageController { @Value("${example.message}") private String msg; @RequestMapping("/message") String getMsg() { return this.msg; } } 

When configations change on the config-server, you can trigger /refresh endpoint manually to reload the config changes.

From above, you need to trigger /refresh endpoint manually to reload the config changes. This is not practical and viable if you have large number of applications. Spring Cloud Bus module can be used to implement auto refresh configs. It links multiple applications with a message broker and broadcast configuration changes.

(Continue .. )