Kubernetes: Externalized Configuration with Spring Boot

Why Externalize Configurations in Spring Boot ?

Most applications have different properties and resources that need to be configured before or after deployment. It is also important that the application is not environment specific. The application must be able to run on any environment be it Dev/Test/QA/Staging or Production. So, how are we able to achieve this? The answer is externalized configurations. These externalized configurations include the environment the application is running, the credentials for database and other applications in microservices and various other configurations that can be easily changed pre or post deployment. So we do not have to build the application every time we have to make minor changes.

So, It is preferred in microservices architecture to externalize configurations. 

Java Spring Boot is a popular, open source tool that helps make web application and microservices with Spring Framework easier with these core capabilities:

1. Autoconfiguration
2. An opinionated approach to configuration
3. The ability to create standalone applications

In this blog, we are going to build a sample application with jenkins and docker and then run it with external configurations in kubernetes.

How to Externalize Spring Boot Configurations ?

Spring boot application loads application properties or YAML configuration files from the locations mentioned below:

1. /config directory of the current directory
2. The current directory
3. The classpath /config package
4. The classpath root (Resource folder)

It is also important to know the priority for each location listed above. 

Location 1, /config directory of the current directory has the highest priority. If the configurations are found in this location other locations will be discarded.

Location 2, the current directory has the second priority. If the configurations are not found in the first location then the configurations will be loaded from this location and locations 3 and 4 will be discarded.

Location 3. the classpath /config package has the third priority. If the configurations are not found in the locations 1 and 2, they will be loaded from this location. Location 4 will be discarded.

Location  4, the classpath root which is the resource folder will be prioritized last. If the configurations are not found in all the other three locations then they will be loaded from this location. If they are not found even in this location, then the application will fail to start.

So for the demo application we will remove the YAML config files from the project repository and resource directory. Then we will load the configs from Kubernetes configmap in the location /app/config and the application will be running from the /app directory. We will be running a jar application located in /app in Docker alpine image.

Building the Application with Jenkins and Dockerfile

We have used maven for building the jar file from the java source code and Docker to build container image from a Dockerfile.

The Jenkinsfile:

The Dockerfile:

I have already build a alpine base image (alpine_base:1.0) with latest packages and java 17 installed, that is why I have used "FROM alpine_base:1.0" in the Dockerfile. After the build is successful we will run the application in Kubernetes.

Running the Application in Kubernetes

First we will create the deployment and configmap in Kubernetes and then run the application.

The deployment:

The configmap:

Now we run the application by scaling the deployment replicas to 1.

We can find the config files in /app/config location as shown below.

The application processes running in the pod container are shown below.

Finally, we can verify the application is running by checking the logs.