This is the first of a two part article where I’ll show you how to use Spring Cloud Config Server to build centralised configuration for your microservices. In this first post we’ll create a Config Service that pulls its data from a Git repo and exposes it to other services. We’ll also create a consumer, a Config Consumer Service that pulls from the Config Service on startup. The diagram below shows how the services will interact.
In part two of this article we’ll take the two services and deploy them to Kubernetes. We’ll initially deploy and test on a local Kubernetes cluster, before deploying on Azures manged Kubernetes Service, AKS.
The diagram below is a sneak peak of what we’ll eventually run on Kubernetes.
Source Code
The source code for this post and part two is available on Github. Feel free to pull it and have a dig around.
Creating the Config Service
Without further ado lets put Spring Cloud Config Server to work and create the first of our two services, the Config Service.
To turn a vanilla Spring Boot app into a Spring Cloud Config Server you’ll need spring-cloud-dependencies and spring-cloud-config-server in your POM.
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.briansjavablog.microservices</groupId>
<artifactId>config-server</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<name>config-server</name>
<description>Demo config server provides centralised configuration for micro services</description>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.4.2</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<properties>
<java.version>11</java.version>
<spring-cloud.version>2020.0.0</spring-cloud.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>
Next add the @EnableConfigServer annotation to the main application class.
package com.briansjavablog.microservices.configserver;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.config.server.EnableConfigServer;
@EnableConfigServer
@SpringBootApplication
public class ConfigServerApplication {
public static void main(String[] args) {
SpringApplication.run(ConfigServerApplication.class, args);
}
}
Service Configuration
The Config Service is going to use Git as its configuration repository. In order for the Config Service to pull the configuration, we’ll need to provide the details of the GIT repo in application.yml.
spring:
application:
name: config-server
cloud:
config:
server:
git:
# URI of GIT repo containing properties
uri: https://github.com/briansjavablog/spring-config-server-on-kubernettes
default-label: main
search-paths: configuration
server:
port: 8888
management:
endpoint:
health:
show-details: always
endpoints:
web:
exposure:
include: "*"
The most important config here is lines 4 to 11.
uri: https://github.com/briansjavablog/spring-config-server-on-kubernettesis the URI of the repo that Config Service will clone.default-label: maintells the Config Service to use themainbranch of the repositorysearch-paths: configurationis the path of the properties in the repo.
These three attributes combined, will tell the Config Service to serve up configuration from https://github.com/briansjavablog/spring-config-server-on-kubernettes/tree/main/configuration
Lines 14 to 21 enable the actuator endpoints. We’re only really interested in the health endpoint as we’ll need it later when deploying to the Kubernetes cluster.
Defining a Dockerfile
Now that we’ve defined the Config Service, the next step is to containerise it with Docker. The Dockerfile below is pretty straight forward. It uses a JRE 11 base image, adds the packaged JAR and runs the JAR on startup via the command in ENRTYPOINT. I’ve also installed cURL as it can be handy for debugging connectivity issues between containers.
FROM openjdk:11-jre-slim-buster MAINTAINER Brian Hannaway RUN apt-get update RUN apt-get -y install curl WORKDIR /app COPY /target/config-server-0.0.1-SNAPSHOT.jar /app/ ENTRYPOINT ["java", "-jar", "config-server-0.0.1-SNAPSHOT.jar"]
Now that we’ve defined the Config Service, its time to put it to work. Next we’ll create a consumer service that will pull its configuration from Config Service on startup.
Config Consumer Service
The Config Consumer service is a vanilla Spring Boot app with a simple REST endpoint. On startup the Config Consumer Service will call the Config Service to retrieve its configuration. The REST endpoint will return the config values loaded from the Configuration Service, allowing us to do a simple end to end test.
POM Definition
To consume config from the Confg Service we’ll need spring-cloud-starter-config in the POM. The full POM definition is shown below.
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.briansjavablog.microservices</groupId>
<artifactId>config-consumer-service</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
<name>config-consumer-service</name>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.4.2</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<properties>
<java.version>11</java.version>
<spring-cloud.version>2020.0.0</spring-cloud.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.retry</groupId>
<artifactId>spring-retry</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aspects</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
<repositories>
<repository>
<id>spring-milestones</id>
<name>Spring Milestones</name>
<url>https://repo.spring.io/milestone</url>
</repository>
</repositories>
</project>
REST Endpoint
The REST endpoint is very simple. It returns a TimoutConfig object with 2 values, connectionTimeoutMillis and readTimeoutMillis. These values are sourced from the Config Service and injected into the controller via Configuration.
@Slf4j
@RestController
@AllArgsConstructor
public class ConfigConsumerController {
private Configuration configuration;
@GetMapping("/timeout-config")
public ResponseEntity<TimeoutConfig> getTimeoutConfiguration(){
TimeoutConfig timeoutConfig = new TimeoutConfig();
timeoutConfig.setConnectionTimeoutMillis(configuration.getConnectionTimeoutMillis());
timeoutConfig.setReadTimeoutMillis(configuration.getReadTimeoutMillis());
log.info("retrieving TimeoutConfig [{}]", timeoutConfig);
return ResponseEntity.ok(timeoutConfig);
}
}
Configuration Properties
Configuration contains the two config values that we exposed on the REST endpoint. The @ConfigurationProperties(prefix="config-consumer-service") annotation along with the configuration in bootstrap.yml, tell Spring boot to source connectionTimeoutMillis and readTimeoutMillis from the Config Service, on startup. The prefix config-consumer-service is passed to the Config Service and used as a key to look up the configuration specific to the Config Consumer Service.
@Setter
@Getter
@Component
@EnableRetry
@ConfigurationProperties(prefix="config-consumer-service")
public class Configuration {
private Integer connectionTimeoutMillis;
private Integer readTimeoutMillis;
}
bootstrap.yml
In order to load configuration from a Spring Cloud Config Server, we need to provide the connection details for the service we’re calling. To make these connection details available to Spring Boot early in the startup sequence, we need add them to bootstrap.yml rather than application.yml. We do this because bootstrap.yml is loaded by the parent ApplicationContext, before application.yml is loaded.
spring:
application:
name: config-consumer-service
cloud:
config:
profile: uat
# target URI for config server corresponds to Kubernetes Service config-service
uri: http://config-service:8888
# the label must correspond with the branch name in Github
label: main
fail-fast: true
retry:
# retry configuration retrieval up to 100 times
max-attempts: 30
# max backoff interval
max-interval: 8000
name: config-consumer-servicetells the Config Service what application is requesting its configurationprofile: uattells the Config Service to return properties associated with the active profileuaturi: http://config-service:8888is the URI of the Config Servicelabel: mainis the name of the branch in the Git repo, containing the propertiesfail-fast: truetells the Config Consumer Service to fail startup if it cannot retrieve its properties from Config Servicemax-attempts: 30used by Spring Retry to retry the call to Config Service up to 30 times, in the event of a failure. This is useful as the Config Service may not be immediately available when the Config Consumer Service starts up.max-internal: 8000is the maximum back off time between retries
Defining a Dockerfile
The Dockerfile definition for Config Consumer Service is almost identical to the one we used for Config Service. The only difference is the name of the JAR that’s copied in and executed.
Wrapping Up
If you’ve made it this far, you’ll have created the Config Service and the Config Consumer Service. The next step is defining the Kubernetes resources required to run our services in a cluster. We’ll look at the Kubernetes manifest in detail, in part two.
Leave A Comment