Config Server 

Configuring properties in Spring Boot improves the application’s flexibility and adaptability. This can be achieved by leveraging environment variables or Java system properties, or by defining properties within the deployed package. However, modifying a property will necessitate restarting the application or even rebuilding and redeploying it. Additionally, it’s not very convenient to modify a property for all instances of the same microservice. 

Fortunately, Spring Cloud Config Server offers centralized configuration through a server that all microservices within an application can rely on to retrieve their configuration. The microsevices will consume the configuration using  a REST API exposed by the Config Server. 

The configuration served by the Config Server is kept external to the server, usually in a source code control system like Git. Using a source code management system brings with it many benefits: Versioning, branching, reverting and so on.

Creating Config Server

The Config Server itself is a microservice with the sole task of managing the configuration. It can be built like any other Spring Boot application by adding this dependency:

<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-config-server</artifactId>

</dependency>

And you will need to enable Config Server for example by annotating the bootstrap’s class with @EnableConfigServer annotation.

@EnableConfigServer
@SpringBootApplication
public class ConfigServerApplication {

  public static void main(String[] args) {

    SpringApplication.run(ConfigServerApplication.class, args);

  }

}

As mentioned earlier, the shared configuration is stored in a source control system, and you must provide the URL to access the configuration. In addition, microservices that consume configuration from the Config Server assume that the server is operating on port 8888. Therefore, it may be beneficial to configure the server to use port 8888. So, if you are using GitHub as source control system then the application.yml file could look like following:

spring:

  cloud:

    config:

      server:

        git:

          uri: https://github.com/afikri-code/server-config-repository

server:

  port: 8888

In the browser you can check the configuration:

http://localhost:8888/application/default

To access a profile other than the default, simply substitute the default profile name with the desired profile name in the URL.

Please note that the term application in the URL (after the port number) can be substituted with any other string. This corresponds to the spring.application.name of the Microservice that is consuming the configuration. 

Additionally, it is possible to configure the Config Server to retrieve configuration information from a specific branch. To do so, simply add the branch’s name using the  parameter default-label

spring:

  cloud:

    config:

      server:

        git:

          uri: https://github.com/afikri-code/server-config-repository

          default-label: new-feature

Consume the configuration

To make use of the configuration served by the Spring Cloud Config Server, the microservice needs to include the Config Server client dependency in its project configuration:

<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-starter-config</artifactId>

</dependency> 

and 

<dependency>

    <groupId>org.springframework.cloud</groupId>

    <artifactId>spring-cloud-starter-bootstrap</artifactId>

</dependency>

Upon running the application, the autoconfiguration will automatically register a property source that fetches properties from a Config Server. By default, the autoconfiguration assumes that the Config Server is running on the localhost and listening on port 8888. However, if the Config Server is not running on the default location, the location of the Config Server can be configured by setting the spring.cloud.config.uri property. So your configuration might look like following:

spring:

  cloud:

    config:

      uri: http://localhost:8888



  application:

    name: mymicroservice

To specify properties that are specific to a particular microservice and not shared with other microservices, you can create a file with the same name as the microservice. For example, if the name of your microservice is „mymicroservice“, you can create a file called „mymicroservice.yml“. If there are duplicate property definitions between the common properties in application.yml and those in the microservice-specific configuration file, the microservice-specific properties will take precedence.

Refreshing configuration properties on the fly

Spring Cloud Config Server provides a feature to refresh configuration properties of running applications without requiring a redeployment or restart. This means that changes made to the external configuration repository can be immediately reflected in the running application, with zero downtime. This can be achieved in two ways: manually, by calling the Actuator endpoint enabled at the microservice client; or automatically, by defining a commit hook in the Git repository that triggers a refresh on all servers that are clients of the Config Server. While manual refresh gives more precise control over when services are updated with fresh configuration, automatic refresh can save time and effort.

To refresh the configuration explicitly using the Config Server, you can add the Spring Boot Actuator starter dependency to the client’s project. 

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-actuator</artifactId>

</dependency>

Then, you can send a POST request to the /actuator/refresh endpoint provided by Actuator to refresh the configuration whenever you want.