When creating deployments, I am currently trying to find a reason why one should externalize the environment variables for a container into a configmap. So instead of defining environment variables with
env:
- name: LANGUAGE
value: "English"
in the deployment.yaml use
env:
- name: LANGUAGE
valueFrom:
configMapKeyRef:
name: language
key: LANGUAGE
or
envFrom:
- configMapRef:
name: env-configmap
with an additional configmap.yaml like so:
apiVersion: v1
kind: ConfigMap
metadata:
name: env-configmap
data:
LANGUAGE: English
Of course, when using confidential values, they should be read from a secret, but that does not apply to non-confidential variables. The only advantage I see is that I can reuse these configmaps, but apart from that it only makes the chart more complicated as I now have to ensure that the pods are restarted etc...
So: What are other advantages when using ConfigMaps to read the environment variables?
A ConfigMap allows you to decouple environment-specific configuration from your container images, so that your applications are easily portable.
Use a ConfigMap to keep your application code separate from your configuration. It is an important part of creating a Twelve-Factor Application. This lets you change easily configuration depending on the environment (development, production, testing) and to dynamically change configuration at runtime.
According to the docs, in Kubernetes, ConfigMap resources “allow you to decouple configuration artifacts from image content to keep containerized applications portable.” Used with Kubernetes pods, configmaps can be used to dynamically add or change files used by containers.
You can use kubectl create configmap to create a ConfigMap from an individual file, or from multiple files.
As you point out, you can re-use the ConfigMap so that other parts of your chart can easily re-use the same environment variables. How useful this is can depend on how many variables you have and how many places they are used in.
A ConfigMap is also available as an Object in the cluster that other Pods can make use of, including ones that are not part of your chart. This could mean your configmap getting referenced by other apps getting installed in the same cluster, or it could be that you choose to publish your chart and then it might get packaged as a dependency within another chart. If your chart is to be used as a dependency in another chart then it makes things a bit easier/cleaner for the chart that is building on top of yours to reference parts of your configuration from a ConfigMap. So the usefulness can also depend on how you intend your chart to be used. The official charts use a lot of ConfigMaps but they do sometimes use environment variables directly and they use ConfigMaps in a variety of ways for different purposes.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With