Spring Cloud Config Server on Kubernetes (Part 1)
Let's get your services up and running.
Join the DZone community and get the full member experience.Join For Free
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.
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-config-server in your POM.
Next add the
@EnableConfigServer annotation to the main application class.
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
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 the
mainbranch of the repository
search-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.
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.
To consume config from the Confg Service we’ll need
spring-cloud-starter-config in the POM. The full POM definition is shown below.
The REST endpoint is very simple. It returns a
TimoutConfig object with 2 values,
readTimeoutMillis. These values are sourced from the Config Service and injected into the controller via
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
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.
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
application.yml is loaded.
name: config-consumer-servicetells the Config Service what application is requesting its configuration
profile: uattells the Config Service to return properties associated with the active profile
uri: http://config-service:8888is the URI of the Config Service
label: mainis the name of the branch in the Git repo, containing the properties
fail-fast: truetells the Config Consumer Service to fail startup if it cannot retrieve its properties from Config Service
max-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.
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.
Published at DZone with permission of Brian Hannaway, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.