When the developers plan to deploy Spring Boot application on Kubernetes, the first question comes to a spring developer's mind is "Can I use Spring Config server?" Spring Config server is a de-facto way of doing centralized configuration of a distributed application. Yes, we can use Spring Config server, but let’s think of some constraints that Spring Config server can have in a typical Enterprise deployment:
- No access to the internet from production.
- This means I can’t use the default Git backed if the customer uses other VCS.
- Running own ConfigServer locally is another possibility.
- But then you need to deploy to set it up in each environment and then applying policies, rules, etc.
- Restricting access to config server properties and files.
- Typically like making *-prod not visible to other environment users or file permissions.
- What are other backends that I can use?
- If I need to add a new backend how or what customization do I need to make to my config server.
- I can't mount the Spring Config server hosted properties as Volumes/Files.
Though there might be or will be a workaround to overcome these constraints, but as a Developer, I would prefer to use something that my platform provides natively rather than customizing it myself. The big advantage to using the native way clear separation of concern, where I was a Developer, I don’t need to worry about how the configuration is available to me but just be assured I will have it! Are there are better ways to do the same inside Kubernetes? The answer is affirmative :). OK then,
- What are they?
- How do I use them?
- What backend can I use with it?
- Is it secured?
- Can Spring Boot use them?
- Can those kinds of properties be hot reloaded?
To answer all those questions is why I decided to write this blog series "Configuring Spring Boot Application on Kubernetes".
Before we jump into details let me answer some of the questions asked above.
What are they?
In Kubernetes, we can handle all the application configuration and properties using ConfigMaps and Secrets. Using ConfigMaps and Secrets, the application naturally satisfies Config principle of The Twelve-Factor App.
How do I use them?
There are many ways to use them, but we will be focusing on two simple methods of using theme i.e.
- As Environment Variables
- As Files inside the containers
What backend do they support?
When ConfigMaps and Secrets can be loaded as files from various backends like S3, CephFS, GlusterFS, NFS and much more. More details are available at https://kubernetes.io/docs/concepts/storage/volumes/.
Is it secured?
Using ConfigMaps and Secrets as files are the easiest ways to make ConfigMaps and Secrets secured. We can apply for the file/directory permissions. We can also restrict the access based on the Namespace synonymous to environments and Service Accounts.
To answer the question “Can Spring Boot use them?”, I have split the blog series into two parts, with each dedicated to ConfigMaps and Secrets.
The blog posts provide the details demo sources. The README on the source repos helps you to try things by yourself (DIY).
The Spring Boot and Kubernetes Series
How to Configure the Spring Boot Application on Kubernetes
Part I: Configuring Spring Boot on Kubernetes with ConfigMap