Using Helm For Deploying Spring Boot Microservice to K8s

We have build a few Microservices (MS) which have been deployed to our company's K8s clusters.

For current deployment, any one of our MSs will be built as a Docker image and they deployed manually using the following steps; and it works fine:

• Create Configmap
• Installing a Service.yaml
• Installing a Deployment.yaml
• Installing an Ingress.yaml

I'm now looking at Helm v3 to simplify and encapsulate these deployments. I've read a lot of the Helm v3 documentation, but I still haven't found the answer to some simple questions and I hope to get an answer here before absorbing the entire doc along with Go and SPRIG and then finding out it won't fit our needs.

Our Spring MS has 5 separate application.properties files that are specific to each of our 5 environments. These properties files are simple multi-line key=value format with some comments preceded by #.

# environment based values
key1=value1
key2=value2

Using helm create, I installed a chart called ./deploy in the root directory which auto-created ./templates and a values.yaml.

The problem is that I need to access the application.properties files outside of the Chart's ./deploy directory.

From helm, I'd like to reference these 2 files from within my configmap.yaml's Data: section.

• ./src/main/resource/dev/application.properties
• ./src/main/resources/logback.xml

And I want to keep these files in their current format, not rewrite them to JSON/YAML format.

Does Helm v3 allow this?

Putting this as answer as there's no enough space on the comments!

Check the 12 factor app link I shared above, in particular the section on configuration... The explanation there is not great but the idea is behind is to build one container and deploy that container in any environment without having to modify it plus to have the ability to change the configuration without the need to create a new release (the latter cannot be done if the config is baked in the container). This allows, for example, to change a DB connection pool size without a release (or any other config parameter). It's also good from a security point of view as you might not want the container running in your lower environments (dev/test/whatnot) having production configuration (passwords, api keys, etc). This approach is similar to the Continuous Delivery principle of build once, deploy anywhere.

I assume that when you run the app locally, you only need access to one set of configuration, so you can keep that in a separate file (e.g. application.dev.properties), and have the parameters that change between environments in helm environment variables. I know you mentioned you don't want to do this, but this is considered a good practice nowadays (might be considered otherwise in the future...).

I also think it's important to be pragmatic, if in your case you don't feel the need to have the configuration outside of the container, then don't do it, and probably using the suggestion I gave to change a command line parameter to pick the config file works well. At the same time, keep in mind the 12 factor-app approach in case you find out you do need it in the future.