Creating a Configuration Microservice Using Spring Cloud Config

Config-server architecture

The advent of microservice architecture has alleviated a lot of pain points for developers that were present in the monolith architecture. However, it also has introduced some complications as a result of its distributed nature. One such complication is maintaining property files for the system.

In a monolith there is one place where the property files are stored and when changes are needed, there is only one place that they need to be updated. In a microservice architecture, each microservice owns its own properties. This can result in duplication of a single property value across multiple microservices. If that value needs to be updated it will need to be changed in every microservice. This isn’t a big deal if you only have one or two microservices, but if that property is used in 10, 20, or 30 different ones you will have to make the change in each one and re-deploy it for the change to take effect. Luckily, Spring Cloud offers an easy way to combine all the properties for all of your microservices into one place.

In the rest of this post I will walk you through a basic setup of the Spring Cloud Config Server so it can be used in your microservice architecture.

Spring Cloud Config Server has the ability to use multiple backends such as Git, SVN, File System, or Vault. In this tutorial we will use a Git backend for the configuration service so the first step is to create a git repo. To start out, we will use a local git repository. Go ahead and create a folder to use as a local repo called configuration-files and initialize it as a git repo.

mkdir configuration-files && cd configuration-files
git init

Inside this folder we need to add our property files. The Config Server allows a lot of customization in how we can organize our property files for the different applications. I prefer a structure that has a folder for each application and all of its necessary property files underneath it.

microservice-one
|--- application.properties
|--- application-prod.properties
|--- application-dev.properties
microservice-two
|--- application.properties
|--- application-prod.properties
|--- application-dev.properties

Create two folders with three property files under each one like above. We will add some test properties to each file, so we can see the difference in how the server handles different profiles and applications.

# Create application directories
mkdir microservice-one microservice-two
# Create microservice-one properties
echo "test.message=microservice-one dev" > microservice-one/application-dev.properties
echo "test.message=microservice-one prod" > microservice-one/application-prod.properties
echo "test.message=microservice-one common" > microservice-one/application.properties
# Create microservice-two properties
echo "test.message=microservice-two dev" > microservice-two/application-dev.properties
echo "test.message=microservice-two prod" > microservice-two/application-prod.properties
echo "test.message=microservice-two common" > microservice-two/application.properties

In order for the Config Server to pick up these files they will need to be added and committed to the repo. Once this is done we are ready to create the server.

Spring provides an excellent tool for creating a Spring Boot application, Spring Initializr. I am using Gradle as my build tool and the most recent version of Spring Boot (2.1.2.RELEASE) at the time of writing. To create a Spring Config Server we will need only one dependency: Config Server.

Replace Group with your own domain.

Open the project in your favorite IDE and open the ConfigServiceApplication.java file. By default the Spring Initializr tool creates a file that only starts the application.

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

Add the @EnableConfigServer annotation to the class. This enables the Config Server for the Spring Boot Application and handles all the necessary configuration for us. Now, while the config server has been enabled, it does not know where to pull the properties from. We still need to configure a few basic properties to allow it to work properly.

The default properties style uses a file extension of .properties but I have chosen to use a .yml extension instead. You can choose to use whichever you prefer in your own implementation. For our basic configuration of the Config Server we will need to set only five properties. The first is the application name. In this case we will call it config-service but this is not essential for the application to run, just a good practice. The next is the port that the Config Server will run on. I am using port 8888. The most important property is the git uri of the Git repo that we created up above. For the time being, we will use a local file version of the Git repo. Set property spring.cloud.config.server.git.uri to point to the git repository that we created earlier. Spring Cloud Config Server also allows us to customize the search paths that are used when making a request to the server. Since we set up our git repo to have a folder for each application, we need to specify how the server should search for properties. Using the '{application}' value for search-paths we can tell the server to look inside the directory that corresponds to the name of the application that is calling it. Here is what our finished property file should look like.

server:
  port: 8888
spring:
  application:
    name: config-service
  cloud:
    config:
      server:
        git:
          uri: ${HOME}/<path_to_config_repo>/configuration-files
          search-paths:
          - '{application}'

At this point we are ready to build, run, and test our config server. It can be accessed using http://localhost:8888 once it is up and running. To access the properties for an application use an url path that adheres to this format: /{application}/{profile} where application is the name of the application folder that is configured and profile is the spring profile/environment.

For example, if we wanted to access the prod properties for application1 that we created earlier, this would be the url: http://localhost:8888/microservice-one/prod This should result in a response that includes our properties test.message=microservice-one common and test.message=microservice-one prod . We can switch to see the dev properties by replacing the prod with dev.

Because Spring Boot properties have a hierarchical relationship with all profiles using the application.properties file and then also using the file for that specific profile. As a result, the Spring Config server will return both the properties within the application.properties file and those that are in the application-{profile}.properties file. If you pass in a profile that does not have a corresponding property file, the server will only return the properties located in the application.properties file.

You should now have a fully functional config server that can be used with a number of microservices. The code for the server can be found here, and the properties repo can be found here.

Follow Here for More Awesome Content