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...
The Config Server provides the HTTP API, which may be invoked in various ways. The following endpoints are available:
/{application}/{profile}[/{label}]: This returns data in a JSON format; the label parameter is optional/{application}-{profile}.yml: This returns the YAML format/{label}/{application}-{profile}.yml: A variant of the previous endpoint, where we can pass an optional label parameter/{application}-{profile}.properties: This returns the simple key/value format used by properties files/{label}/{application}-{profile}.properties: A variant of the previous endpoint, where we can pass an optional label parameter
From a client point of view, the application parameter is the name of the application, which is taken from the spring.application.name or spring.config.name property, and profile is an active profile or comma-separated list of active profiles. The last available parameter label is an optional property, important only while working with Git...
We have started by discussing HTTP, a resource-based API provided by the Spring Cloud Config Server, and the way of creating and storing properties there. But now let's move back to the basics. The same as a discovery server, a Config Server may be run as a Spring Boot application. To enable it on the server side, we should include spring-cloud-config-server in our dependencies in the pom.xml file:
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-server</artifactId> </dependency>
In addition to this, we should enable the Config Server on the main application class. It would be a good idea to change the server port to 8888, because it is the default value of the spring.cloud.config.uri property on the client side. For example, it is auto configured on the client side. To switch the server to a different port, you should set the server.port property on 8888 or launch it with the...
If you set port 8888 as the default for the server, the configuration on the client side is really simple. All you need to do is to provide the bootstrap.ymlfile with the application name and include the following dependency in yourpom.xml. Of course, that rule is applicable only on localhost, because the auto-configured Config Server address for a client ishttp://localhost:8888:
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-config</artifactId> </dependency>
If you set a port different than 8888 for the server, or it is running on a different machine than the client application, you should also set its current address in bootstrap.yml. Here are the bootstrap context settings, which allow you to fetch properties for client-service from the server available on port 8889. When running the application with the--spring.profiles.active=zone1 argument, it automatically fetches the...
In the example solution described previously, all of the applications must hold the network location of the configuration server. The network location of service discovery is stored there as a property. At this point, we are confronted with an interesting problem to discuss. We could ask whether our microservices should be aware of the Config Server's network address. In previous discussions, we have agreed that the main place all the service’s network locations should be kept is the service discovery server. The configuration server is also a Spring Boot application like other microservices, so logically it should register itself with Eureka to enable the automated discovery mechanism for other services that have to fetch data from the Spring Cloud Config Server. This in turn requires placing the service discovery connection settings in bootstrap.yml instead of the spring.cloud.config.uri property.
Choosing between these two different approaches is one of...
All of the previous examples in this chapter have used the filesystem backend, which means that the config files were loaded from the local filesystem or classpath. This type of backend is very good for tutorial purposes or for testing. If you would like to use Spring Cloud Config in production, it is worth considering the other options. The first of them is a repository backend based on Git, which is also enabled by default. It is not the only one version control system (VCS) that can be used as a repository for configuration sources. The other option is SVN, or we can even decide to create a composite environment, which may consist of both Git and SVN repositories. The next supported backend type is based on a tool provided by HashiCorp, Vault. It is especially useful when managing security properties such as passwords or certificates. Let's take a closer look at each of the solutions listed here.
Let's take a look at some other useful features of the Spring Cloud Config.
Sometimes it doesn't make any sense to launch the application if the Config Server is unavailable. In this case, we would like to halt a client with an exception. To achieve this, we have to set the bootstrap configuration property spring.cloud.config.failFast to true. Such a radical solution is not always the desired behavior. If a Config Server is unreachable only occasionally, the better approach would be to keep trying to reconnect until it succeeds. The spring.cloud.config.failFast property still has to be equal totrue, but we would also need to add the spring-retrylibrary andspring-boot-starter-aopto the application classpath. The default behavior assumes to retry six times with an initial backoff interval of 1000 milliseconds. You may override these settings by using the spring.cloud.config.retry.*configuration properties.
We have already discussed the most important features of Spring Cloud Config. At that point, we implemented examples illustrating how to use different backend storage as a repository. But no matter whether we decided to choose filesystem, Git, or Vault, our client-side application needed to restart to be able to fetch the newest configuration from the server. However, sometimes this is not an optimal solution, especially if we have many microservices running and some of them use the same generic configuration.
Even if we created a dedicatedpropertyfile per single application, an opportunity to dynamically reload it without restart could be very helpful. As you may have deduced, such a solution is available for Spring Boot and therefore for Spring Cloud. In Chapter 4, Service Discovery while describing deregistration from the service discovery server, I introduced an endpoint, /shutdown, which may be used for gracefully shutting down...
In this chapter, I have described the most important features of a Spring Cloud Config project. The same as for service discovery, we started from the basics, a simple use case on the client and server sides. We discussed the different backend repository types for a Config Server. I implemented the examples illustrating how to use filesystem, Git, and even third-party tools such as Vault as a repository for your property files. I put particular focus on interoperability with other components, such as service discovery or multiple instances of microservices within a larger system. Finally, I showed you how to reload an application's configuration without restart, based on WebHooks and a message broker. To conclude, after reading this chapter you should be able to use Spring Cloud Config as one element of your microservice-based architecture and take an advantage of its main features.
After we have discussed an implemetation of service discovery and configuration server with Spring...
© 2018 Packt Publishing Limited All Rights ReservedAuthor (1)
