Spring Cloud Config Server on Kubernetes (Part 1)

Let's get your services up and running.

Brian Hannaway

May. 02, 21 · Tutorial

Likes (5)

Comment

Save

8.2K Views

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 
   
 
  
    
 
      
 
     
 
      
 
     
 
     
 
    
xxxxxxxxxx
 
          
 
         
 
          
 
         

              
          
<?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.

     Java 
   
xxxxxxxxxx
 
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.

     YAML 
   
xxxxxxxxxx
 
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-kubernettes is the URI of the repo that Config Service will clone.
default-label: main tells the Config Service to use the main branch of the repository
search-paths: configuration is 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.

     Dockerfile 
   
xxxxxxxxxx
 
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 
   
 
  
    
 
      
 
     
 
      
 
     
 
     
 
    
xxxxxxxxxx
 
          
 
         
 
          
 
         

              
          
<?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>
    &llt;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.

     Java 
   
xxxxxxxxxx
 
@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.

     Java 
   
xxxxxxxxxx
 
@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.

     YAML 
   
xxxxxxxxxx
 
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-service tells the Config Service what application is requesting its configuration
profile: uat tells the Config Service to return properties associated with the active profile uat
uri: http://config-service:8888 is the URI of the Config Service
label: main is the name of the branch in the Git repo, containing the properties
fail-fast: true tells the Config Consumer Service to fail startup if it cannot retrieve its properties from Config Service
max-attempts: 30 used 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: 8000 is 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.

Spring Framework Spring Cloud Kubernetes microservice

Published at DZone with permission of Brian Hannaway, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

Trending

Spring Cloud Config Server on Kubernetes (Part 1)

Let's get your services up and running.

Source Code

Creating the Config Service

Service Configuration

Defining a Dockerfile

Config Consumer Service

POM Definition

REST Endpoint

Configuration Properties

bootstrap.yml

Defining a Dockerfile

Wrapping Up

Related

Partner Resources