#WHATIS?: Spring Cloud Config

Last Updated:  November 4, 2019 | Published: December 30, 2017

In today's #WHAT IS? blog post I want to present you one of my latest learning experiences: Spring Cloud Config.

When I started to use the Spring Framework, the whole Spring ecosystem with its projects like Spring Data, Spring Web and Spring Security just overstrained me. While writing my first RESTful microservice with Spring Boot I was glad to understand the basic concepts of the Spring Boot projects bit by bit. Scrolling through the information page of all available Spring projects I noticed that there is another big Spring ecosystem under the umbrella of Spring Cloud

Last week I took the time to understand what the Spring Cloud is all about. The are several buzzwords when working with the Spring Cloud ecosystem: Cloud Config, Cloud Bus, Hystrix, Eureka, Feign, Ribbon. To understand the basics I worked through a great Udemy course from Ken Krueger: Microservices with Spring Cloud.

This week I want to start with the project Spring Cloud Config and introduce you to its features.

Introduction to Spring Cloud Config

In a microservice environment, every service has its own configuration and highly depends on the configuration from outside. Imagine having a three-digit amount of microservices like Netflix, Google or Amazon. For them, it becomes quite hard and cumbersome to manage all the different configurations by hand.

For my projects, I currently provide the different application.properties from within the Spring project. They usually have different -prod, -dev or -test properties on the classpath. To change the active profile I add the JVM argument -Dspring.profiles.active to the launch of my application. For a small set of services and a small and maintainable number of property files it's okay but with a growing number of microservices, it's not that elegant.

With Spring Cloud Config the configuration process for your applications becomes quite easy. Spring Cloud Config provides server and client-side support for externalized configuration. The central config server then distributes the config files over HTTP to several clients.

The config server gets the configuration files for its clients from either a Git repository or from the filesystem. During the startup of the Spring application, the application claims to get its .properties/.yml configuration file from the config server.

 

Client-side requirements

To distribute the correct config file, the clients have to identify themselves with a unique application name which is set with the Spring property spring.application.name. This name has to be set at the bootstrap of the Spring app wherefore Spring uses a bootstrap.properties file. This file is mostly placed at src/main/resources and is loaded during the first milliseconds of the startup.

For the configuration file claim, the client application also needs to get informed about the location of the config server with the Spring property spring.cloud.config.uri which should also be placed in the bootstrap.properties file. A full example of this file could look like the following:

With this setup, you do not need to have application.properties file bundled in your .jar as the configuration gets overwritten with the distributed one. Nevertheless, I would recommend adding an own application.properties to the Spring app for a fallback reason when the config server is down or network issues occur.

To enable this configuration process in your app, the client-side has to add the following dependency to its pom.xml:

And a separate entry for the dependency management for Spring Cloud dependencies like:

No further configuration is needed besides the bootstrap.properties file.

Server-side requirements for Spring Cloud Config

The server side is quite as simple as the client-side. To start your own Spring Cloud Config server you have to create a new Spring project with the following pom.xml:

The only annotation you have to add is @EnableConfigServer to your application class like:

For the discovery of the several property files, you also need to add the location of these files to the application.properties of your config server. The following example uses a dedicated GitHub Repository:

The repository looks like the following:

 

As you see in the screenshot above you are also able to place different property files for you different profiles to the config server backend.

With this setup, you just have to start your config server first and define your active Spring profile for your client apps during the startup and everything should work. If you don't specify a profile, the default profile is loaded.

I created an example setup for you on GitHub:

Spring Cloud Config Server: https://github.com/rieckpil/spring-cloud-sample-config-server
Spring Cloud Config Client: https://github.com/rieckpil/spring-cloud-sample-config-client
Repository for storing property files: https://github.com/rieckpil/spring-cloud-config-data

Be curious to read about one of my next blog posts, where I show you how to dynamically change your Spring properties during the runtime without a re-deployment!

Find further Spring related blog posts here.

Have fun using this Spring Cloud technology,

Phil.

>