The Best Way to Configure an Application

Why should we not use ConfigMaps?

In our experience, ConfigMaps are overused.

If we have a configuration that is the same across multiple clusters, or if we have only one cluster, all we need to do is include it in our Dockerfile and forget it ever existed. When there are no variations of a configuration, there’s no need to have a configuration file, at least not outside an immutable image.

Unfortunately, that is not always the case. To be more precise, it’s almost never the case. We tend to make things more complicated than they should be. This, among other things, often means an endless list of configuration options hardly anyone ever uses. Still, some things usually do change from one cluster to another, and we might need to look into alternatives to configurations baked into images.

Finding out the best way

The best way to design new applications is to use a combination of configuration files and environment variables. Make sure that the default values in a configuration file are sensible and applicable in most use-cases. Bake it into the image. When running a container, declare only the environment variables that represent the differences of a specific cluster. This way, our configuration will be portable and simple at the same time.

What if our application is not new and does not support configuration through environment variables? We should refactor it so that it does. It shouldn’t be hard to add the ability to read a few environment variables. Keep in mind that we don’t need all the settings, but only those that differ from one cluster to another. It would be hard to imagine that such a trivial request would be complex or time-consuming. If it is, we might have more significant issues to fix before even thinking about putting our application into a container.

When to use ConfigMaps

Still, configuration files will not disappear. No matter which strategy we choose, each image should have a copy of them with sensible default values. Maybe we can put in extra effort and change the application so that configuration entries are loaded from two locations. This way, we can load the default values from one file and the differences from the other file. That would, at least, reduce the need to have to specify more than the minimum required for each cluster. In such a case, ConfigMap’s --from-literal and --from-env-file sources are an excellent choice.

When everything else fails, the --from-file source can be useful. Just make sure that ConfigMap is not defined in the same file as the objects that mount it. If it is, it would mean that they could be used only inside one cluster. Otherwise, we’d be deploying the same configuration, and we should go back to the initial idea of having it baked into the image together with the application.

Do not let this pessimism discourage you from using ConfigMaps. They are very useful, and you should adopt them. Our intention was to make you think of alternatives, not to tell you never to use ConfigMaps.