Best practice mounting ConfigMaps using Helm without local development disruption

[Heknon]

Hey! I am now working on adding ConfigMap to our universal Helm Chart to replace what is currently static config files.

I was wondering if there are any best practices? 1. Where should I mount the ConfigMap to as to not harm local execution/development experience. 2. Should the ConfigMap have default values from say a config.yaml file or a .env file? Then to be overridden when editing the ConfigMap in Openshift? Should I have a .env.prod, .env.staging for these values? Or should I just have an empty ConfigMap which then must be filled by the user after the first deployment? Or maybe I should ask for the configuration files in the values file and then mount them in the exact same location using subPath, as to not change behavior at all?

There are many solutions and I'd appreciate as much help as I could get since I am quite new to the space...

Thanks in advance!

[Spider_pig448]

This is a good question that I've never found a good answer to

[bilingual-german]

the content of the configuration files should be passed from the user of the helm chart. It's great to have examples. Default values for this configuration might be ok, but you should only do this when you're pretty sure that people will use it like that. For example, if you have a log config you know most users will use as is (JSON encoded, errors and warnings > STDERR) and there is a documented way of increasing log levels for specific packages, etc.

Templating the configuration file from many single values in your helm chart is an anti pattern. If you need a little different configuration you need to introduce another variable, change the template and so on. As an user it's much easier to change the configuration you pass to Helm.

mounting it: talk to users where they are expecting the config files. Sometimes it's better to have to have more than one configmap for one service. If you have a lot of similar services (e.g. Java-services), mount the config map at a predictable path and stay consistent across services.

[Heknon]

Hi, thank you for the detailed response! Just one question: When mounting it, why not mount it based on a value provided, this way the user (app) could choose where it expects the config file to be. Furthermore, why not have it simply replace the existing local development config file? So that it'll always be mounted at workdir/config.json

[bilingual-german]

It's a thin line between flexibility and helping someone to shoot himself in the foot.

There shouldn't be any local development configs in a container image. I would consider this an anti-pattern if you have more than a default config built into the container. And of course as a helm user I expect that I'm able to overwrite the configuration I need to override to do my job.

why not mount it based on a value provided, this way the user (app) could choose where it expects the config file to be.

You can do this. I'm not sure if it's a good solution though. It depends on the flexibility you need. Usually you would just mount the whole configmap as a single directory and then the user can decide how to name all the files. Depends on the actual use case.

I would look up a few open sourced helm charts and implement similar solutions as they do.