In one of our articles, we discussed the environment variable pattern; how to define them, where to use them and their potential drawbacks. We briefly touched the configMap and Secrets resources as a means of injecting external configuration settings to the Pod (and its running containers). In this article, we have a deeper demonstration of the configMap and Secret usage patterns and best practices.
What’s The Problem With Using Environment Variables?
There are several considerations that you must take into account when deciding to use environment variables for all your configuration needs:
They are honored in multiple layers. For example, an environment variable that’s set in bash_profile of an image will be overridden if the same variable name was set in the Dockderfile. Even further, the same variable can be overridden in the Pod definition. Such behavior can cause hard-to-detect bugs when you’re not certain that your environment variable won’t get overridden by mistake.
Environment variables cannot be changed once the application is launched. Modifying an environment variable requires restarting the container to apply the new data but depending on your deployment pattern, this may or may not be desired.
More often than not, the external configuration is not limited to a bunch of variables, it spans throughout the whole configuration file. Think of php.ini, config.json, or package.json files. Those files need to be externally availed to the running container. The application expects to find its configuration file in a specific location rather than a set of environment variables.
Using environment variables for storing sensitive data is a security risk.
For more information: https://www.magalix.com/blog/the-configmap-pattern
Top comments (0)