Distributed Configuration with Spring Cloud Config

It is the right time to introduce a new element in our architecture, a distributed configuration server. Similar to service discovery, this is one of the key concepts around microservices. In the previous chapter, we discussed in detail how to prepare discovery, both on the server and client sides. But so far, we have always provided a configuration for the application using properties placed inside a fat JAR file. That approach has one big disadvantage, it requires a recompilation and a redeployment of the microservice's instance. Another approach supported by Spring Boot assumes the use of an explicit configuration stored in a filesystem outside of the fat JAR. It can be easily configured for an application during startup with the spring.config.location property. That approach does not require a redeployment, but it is also not free from drawbacks. With a lot of microservices, a configuration management based on explicit files placed in a filesystem may be really troublesome. In addition, let’s imagine that there are many instances of every microservice and each of them has a specific configuration. Well, with that approach it is better not to imagine it.

Anyway, a distributed configuration is a very popular standard in a cloud-native environment. Spring Cloud Config provides server-side and client-side support for externalized configuration in a distributed system. With that solution, we have one central place where we can manage external properties for applications across all environments. The concept is really simple and easy to implement. A server does nothing more than expose HTTP and resource-based API interfaces, which returns property files in JSON, YAML, or properties formats. Additionally, it performs decryption and encryption operations for returned property values. A client needs to fetch configuration settings from a server, and also decrypt them if such a feature has been enabled on the server side.

Configuration data may be stored in different repositories. The default implementation of EnvironmentRepository uses a Git backend. It is also possible to set up other VCS systems such as SVN. If you don't want to take advantage of features provided by VCS as a backend, you may use the filesystem or Vault. Vault is a tool for managing secrets, which stores and controls access to such resources as tokens, passwords, certificates, and API keys.

The topics we will cover in this chapter are:

• HTTP API exposed by Spring Cloud Config Server
• Different types of repository backend on the server side
• Integrating with service discovery
• Reloading the configuration automatically with Spring Cloud Bus and message broker