This February I got a chance to attend the Helm Summit in Portland. It was filled with amazing talks covering various topics about Helm. I attended almost all of them, and also got the opportunity to present a Lightning Talk myself. The talk was about a Helm trick\/tip that I came across and found very useful, so I thought I\u2019d share with you all as an article.<\/p>\n
Helm lets us manage Kubernetes applications effortlessly. Helm Charts make installation and upgradation of Kubernetes applications easier. In this article, I want to focus on one out of the many benefits of using Helm: How Helm makes updating an app that uses ConfigMap very easy.<\/p>\n
Updating a deployment<\/h2>\n
![\"Updating](\"https:\/\/rancher.com\/img\/blog\/2018\/updating-a-deployment.png\")
<\/p>\n
This is a sample manifest of a deployment. Let\u2019s assume this is being used to run an app. You specify the pod template under spec.template section. Now if you want to update the app, it is a must that something from this spec.template section changes. Meaning, for a change in container image, the deployment will get updated, but not for a change in spec.replicas.<\/p>\n
Updating a deployment that uses a ConfigMap<\/h2>\n
Some apps require certain configuration files and values. It\u2019s not recommended to have these configuration values\/files baked into the container image. This is so, because otherwise every time your configuration file changes, you\u2019d have to recreate the container image. Kubernetes provides a great way of managing configuration files\/values, with the ConfigMap resource.<\/p>\n
There are 2 ways to expose ConfigMap data to a pod,<\/p>\n
- \n
- Env vars<\/li>\n
- Volume mounts<\/li>\n<\/ol>\n
We\u2019re going to focus on the volume mounts way of exposing ConfigMap.<\/p>\n
I\u2019ve created a very simple chart to use as an example to go over this. Within that chart I have the following manifest for a ConfigMap:<\/p>\n
![\"Manifest](\"https:\/\/rancher.com\/img\/blog\/2018\/volume-mount-1.png\")
<\/p>\nAs you can see, the name of the ConfigMap is nginx-cm, and a file called default.conf is reading its data. This default.conf is an nginx configuration file.<\/p>\n
![\"Nginx](\"https:\/\/rancher.com\/img\/blog\/2018\/volume-mount-2.png\")
<\/p>\nNow I want to use this ConfigMap nginx-cm for my app. So I\u2019m going to expose it via Volume Mounts in the deployment manifest for my app.<\/p>\n
![\"Volume](\"https:\/\/rancher.com\/img\/blog\/2018\/volume-mount-3.png\")
<\/p>\nAs shown in the manifest above, we need to add the ConfigMap under Volumes section, and give it a unique name (config-volume as shown in the example manifest). Then, we add this volume under volume mounts in the containers section. The volumeMounts.mountPath field is the exact location in the container where the configuration file will be made available to the container.<\/p>\n
So using these manifests, we can have an app running that uses the content of nginx configuration file made available by the ConfigMap.<\/p>\n
Now let\u2019s say it\u2019s time to change the nginx configuration file. Changes to this config file should be followed by an update to the ConfigMap too, otherwise our app that uses the ConfigMap won\u2019t use the new content.<\/p>\n
We can for sure use the kubectl update command for updating the ConfigMap. This should be followed by an update to the deployment as well. Will kubectl update work for the deployment too?<\/p>\n
I got this message when I tried.<\/p>\n
![\"Deployment](\"https:\/\/rancher.com\/img\/blog\/2018\/volume-mount-4.png\")
<\/p>\nThis is because the deployment\u2019s spec.template portion has not changed even after updating the ConfigMap resource. Even though the ConfigMap\u2019s data section changed, that didn\u2019t cause any changes in the deployment\u2019s spec.template
\nOne workaround for this is to delete all the pods being managed by the deployment, and then the deployment will create new pods that use the updated configMap. But I didn\u2019t quite like this approach, as you have to delete all the pods manually. So I started looking for better solutions. That\u2019s when I came across this Helm trick.
\nhttps:\/\/github.com\/kubernetes\/helm\/blob\/master\/docs\/charts_tips_and_tricks.md#automatically-roll-deployments-when-configmaps-or-secrets-change<\/a><\/p>\nAs you can see under annotations, you can provide path to your configmap file, and pass it to sha256 sum function. This updates the annotation section everytime the configmap file changes, thus in turn updating spec.template portion of the deployment. I found this very helpful, because your configuration file contents can keep on changing quite frequently. So because of this trick, Helm ensures that your app will keep reflecting those changes promptly.<\/p>\n
I have created this sample Helm chart<\/a> to show how this trick can be implemented.<\/p>\n
Do check it out and hopefully you\u2019ll find it useful for your apps too! Also feel free to add more to it, and maybe share any such tips\/tricks that you have come across as well!<\/p>\n
![\"Rajashree](\"https:\/\/rancher.com\/img\/bio\/rajashree-mandaogane.jpg\")
<\/p>\nRajashree Mandaogane<\/p>\n
Software Engineer<\/p>\n