Helm and farewell

The final step of the internship

The final step of the internship has begun. Now that every application is operating on Kubernetes, the translation to Helm charts would be the next step. I’ll try to explain the need of using Helm charts instead of using the default Kubernetes files. Helm charts are basically a solution to translate all of your Kubernetes components to templates. Through this conversion you get the possibility to group all of the templates and deploy them as a full application with a single command. The templates also allow you to deploy multiple iterations of an application with the help of variable-files. 

By using Helm charts, there is also the possibility to integrate them with Jenkins pipelines. The future configuration could lead to freshly build applications which would then be used to automatically deploy newer versions of the applications to Kubernetes. This setup could then be used for testing and development purposes. Now that you have a small understanding of Helm, I will explain the actual journey of this process.

Try to get in under the knee

While I had no prior knowledge of Helm, I was interested to “get it under the knee” as we say in Belgium. Helm charts would make life a lot easier because you won’t be needing to deploy a ton of files in a specific order to get a working version of your application on Kubernetes. As I started studying Helm, I noticed that they mostly resemble Kubernetes applications apart from using variables and templates to define values in the Kubernetes files. It was fairly easy and straightforward to understand the Helm-logic. I started on converting the recruitment-tool Kubernetes file to a Helm chart. The first problem I noticed was the fact that the Metabase component of the recruitment-tool is based on a Helm chart as well. This would mean that I would be figuring out a way to insert a Helm chart into another Helm chart. Thankfully Helm charts support a nesting method by using sub-charts. Through this way I could define global variables which could be used by all of the other components and the Metabase chart as well. So far so good, right? Sadly, some details as defining ConfigMaps that are made out of files were a bit harder to make. By default they are made through a single command but because Helm works through templating it is necessary to define every ConfigMap. Those same ConfigMaps need to have variables defined which makes it not that easy because the Helm values.yaml file doesn’t accept weird characters. This problem was solved by defining a template for the ConfigMaps that need to have variables included in them. Afterwards it’s possible to define a ConfigMap that references the template. 

Fixing all of those small problems led eventually to a working Helm chart for the recruitment tool. With the experience gained I could repeat most of the process to the other applications. Eventually I finished all of the Helm charts whilst encountering some small problems but fortunately nothing serious. Sadly I can’t really demonstrate the results of the Helm charts because they deploy the same application as the previous Kubernetes applications. 

Kubernetes Hero

With all of this being said, I can conclude that I finished the main task of my internship. The only step left is to modify the Jenkins pipeline to deploy Helm charts on the Kubernetes-cluster. I will end the blog on this final accomplishment. This whole experience was really great and educational. Personally, I learned a lot of the Kubernetes world and I’m eager to learn even more. The benefits that come with technologies such as Kubernetes and Helm really shows that the future of containerized applications is here. All of this wouldn’t be possible without the help of Jan and Bjorn. Both of my mentors were always ready to answer questions and help where needed. Even the silliest question would always be answered with a smile. I also learned a lot in how to not only work in a DevOps-environment but also provide work that matches certain quality standards. Some honorable mentions are Paula and Maarten. I could always count on Paula to proofread and correct my crappy documentation. Maarten was also a listening ear for many stupid little problems that I encountered throughout this journey, which I am very thankful for. In the end I can only say that the people behind JIDOKA are awesome and if you happen to be looking for a new challenge in your career, you should definitely consider working here. No rhyme intended. 

The last unanswered question remains, have I become a Kubernetes Hero? I’m not sure, I will let you fill that in. For now, I think I know a good amount of Kubernetes but the sky is still the limit.