0

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?

enter image description here

paiego
  • 3,619
  • 34
  • 43
  • 2
    One option is to pass an environment variable via helm that the container uses to override the default location of the application.properties file (as explained [here](https://www.tutorialspoint.com/spring_boot/spring_boot_application_properties.htm)). This might be nit picking, but baking the configuration for the different environments in the containers is not good practice from the point of view of the [12 factor-app](https://12factor.net/). It's not that they **always apply** but it's worth checking. – Augusto Dec 08 '21 at 23:24
  • @Augusto. I see your point about the config files existing outside of the Jar and Container. Maven typically creates src/main/resources and I assume you wouldn't put property configs in ./resources. Can you mention where you'd put your config files AND your chart directory? – paiego Dec 08 '21 at 23:49

1 Answers1

1

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.

Augusto
  • 28,839
  • 5
  • 58
  • 88
  • "the latter cannot be done if the config is baked in the container", we're currently baking-in the configs, yet they're not used; so Factor III isn't really being violated. There's a configmap in the k8s container with properties which the app is actually using. I ended up putting the config files outside of the jar and into the Chart; which was needed because Helm can't seem to reach outside of itself. This has the advantage of not baking conf files into the jar. – paiego Dec 10 '21 at 23:49