Most of the time, we want our image to be portable. It basically means that, we should allow whoever is running the container to override the default values.
These values depend on the user who’s running the container or starting the pod. We generally pass these values using three ways.
- Configuration files (YAML,JSON)
- Command line arguments as flags
- Environment variables
What is ConfigMap?
ConfigMap is a Kubernetes resources that decouples configuration from pods and other Kubernetes resources.
One thing to keep in mind while using ConfigMap is that you must create it first and then create the resource that reference to the ConfigMap otherwise the workload wouldn’t start. Also, make sure that the key you’re passing to the workload is not misspelled and exists in the ConfigMap.
Why do we need ConfigMaps?
There are many applications that need ConfigMap like when you run your Prometheus application, Prometheus looks for a Prometheus.yml file. Another example is when you run kube-bench then it looks for config file in the directory
/etc/kube-bench/config.yml. Apart from these, there are multiple applications where you need to pass ConfigMap in order to give application specific configurations to your pod.
Creating ConfigMaps imperatively
- You can creating ConfigMap in your Kubernetes cluster using the imperative command. The syntax looks something like this
kubectl create configmap <name> <data-source>
You can create these using two flags
--from-literal if you’re passing the key-value pairs while executing the kubectl command or
--from-file if you’re referencing to a file that carries the key-value pairs.
One thing to note is that if you want to create multiple key-value pair using
--from-literal flag, then you have to type it again & again.
kubectl create configmap demo-configmap --from-literal=NAME=ANURAG --from-literal=AGE=21
Creating ConfigMap from a file
It becomes boring if you have to repeat
--from-literal many times. What we can do is that we can create a file that store all your key-value pairs in one file and use that to create ConfigMap.
$ cat config.txt ENV=PROD NAME=ANURAG SERVICE=BACKEND $ kubectl create cm demo-cm --fromo-file config.txt configmap/dmeo-cm created
Now, we have created ConfigMap, and it’s time to mount that into the pod. There are two ways in which you can do that. One we can do it via the environment variables and another we can do it via volume mounts.
- Environment Variables
spec: containers: - name: demo-container image: nginx env: - name: ENV valueFrom: configMapKeyRef: name: my-config key: ENV
Now the container will have the environment variable
ENV with the value whatever is mapped to the
All you’ve to do is to pass your ConfigMap as volume.
volumes: - name: <name-of-volume> configMap: name: <name-of-config-map>
After configuring the volume, you need to mount this into the container, and it looks something like this
volumeMounts: - name: <name-of-configmap> mountPath: <path>
- Mountpath is the path where the configuration file will lie inside your container. Path is important for those services that look at configuration files at a certain location. Look at this job to understand volumes in more detail.
Creating ConfigMaps & Secrets with Devtron
- Prerequisites for creating ConfigMaps & Secrets in Devtron is to set up your global configurations. If you've not set up your global configurations, then read how to set it up here. Post setting up, your configurations, you need to deploy your application using devtron and there in the
App Configurationsection you will see options for creating ConfigMaps & Secrets.
- Devtron gives you a dashboard from where you can create your ConfigMap easily. Go to your app configuration and then create a ConfigMap.
- You can also select the option how you want to use the ConfigMap whether as env variables or volumes.
- If you’re selecting volumes, then you can also set the path where the volume should be mounted.
Secrets are exactly similar to ConfigMaps and the only difference is that they are base64 encoded. We use secrets to store data that are confidential for the organization.
If you want to decode the secret, then you can decode it easily using
echo "something-secret" | base64 -d
Let's see this in action. We will create one secret imperatively, and later we will decode it using base64.
Most probably you’re not going to use it, and the reason is that anyone can decode your secrets.
Devtron integrates with other secret's provider like HashiCorp Vault, AWS secrets manager etc. which gives you a more robust way to store your Kubernetes or application specific secrets.
- Please note that just saving the ConfigMap & Secret will not create one, you need to run the complete CD Process again and the ConfigMap/Secrets will reflect in your cluster.