As the situation is currently, most applications end up defining the running environment type twice in their helm chart configuration. Once under common.env (used for labeling) and once under common.configmap.data or common.container.env. (mounted as env variables). The latter being self specified however, often leads to:
Different applications/repositories not following a specified naming convention for env type variables.
This makes it more difficult to create a golden path and easily read in default values in e.g. common logging libraries which usually want to adapt to the running environment.
Unnecessary text duplication in the helm config
The solution would be to automatically just define common.env as a readily available environment variable in every pod if available - thereby simplifying setups. An environment variable name other than "ENVIRONMENT" or "ENV" should be used, e.g. "KUB_ENV" to avoid naming conflicts with existing setups.
As the situation is currently, most applications end up defining the running environment type twice in their helm chart configuration. Once under
common.env(used for labeling) and once undercommon.configmap.dataorcommon.container.env. (mounted as env variables). The latter being self specified however, often leads to:The solution would be to automatically just define
common.envas a readily available environment variable in every pod if available - thereby simplifying setups. An environment variable name other than "ENVIRONMENT" or "ENV" should be used, e.g. "KUB_ENV" to avoid naming conflicts with existing setups.See following repos for example of duplication: