Helm makes managing the deployment of your applications inside of Kubernetes easier by using a "templated approach." Every Helm chart follows the same structure, while still being flexible enough to represent any type of application you need on Kubernetes. Helm also supports versioning, taking into consideration the fact that deployment needs change over time.
In the article, “Get Your First App Up and Running with Helm Charts”, we covered setting up a small web application with Nginx. In this article we’ll provide helpful tips when working with Helm.
Tip 1- Knowing Your Docker Image Is Helpful
Start with a docker image for your app first and be sure you are comfortable working with it. Deploy first with basic Kubernetes descriptors or start with docker-compose.
When you have everything working with short Kubernetes descriptors, you’ll want to think about making your deployment more flexible. You might want to pass in deployment switches for different configurations or different environments. That’s a great time to introduce Helm.
Understanding a values File's Role
A quick recap of the structure of a helm chart:
When a user runs Helm install, the entries from values.yaml in the chart and the helm release information (i.e., unique release name) are injected into the templated yaml resource descriptors. The template is evaluated and rendered into K8's deployment descriptors. When a user runs Helm, install with parameters or a values file, the parameters or values file will be overlaid on the chart. The chart’s file defaults that can be overridden.
Tip 2- Start with the Basics
Something important to keep in mind are that charts are designed for a single docker image. So, if you’ve got a microservices app with several interacting parts, take a small piece of your app that you believe can be deployed on its own and write a helm chart for that.
Tip 3- Understanding Release Names
Helm injects release names into the Kubernetes deployment descriptors that Helm generates from our charts. Helm does this to ensure that every resource deployed has its own unique name (which K8's needs it to), even if we're installing the chart multiple times. This happens because templates contain content like this example:
apiVersion: v2kind: Servicemetadata: name: {{ .Release.Name }}-newservice
This shows that {{ .Release.Name }} is a placeholder, Helm injects the release name. For many of your charts, it is more likely you'll see this as:
apiVersion: v2kind: Servicemetadata: name: {{ template "fullname" . }}**
It is important to be aware of this when you start deploying multiple resources in your Helm chart, since they need to reference one another.
If you have the resources defined inside your chart, be careful to use the same names used in the chart definitions by using the same functions. As an example, say you wanted to inject an environment variable into a Pod, containing the name of the Service we have above, then you could do:
- name: SERVICE_NEW value: {{ template "fullname" . }}
Tip 4- Use the Official Charts to your Advantage
Official charts are a great resource, since they deal with things you won’t normally have thought of, and of course, they are maintained. So, start by looking in the official charts if you need something like a MYSQL database, instead of creating your chart.
It needs to be noted that Official charts are complex, since they have to be usable in a multitude of ways. So, don't feel required to deep-dive into their code and follow their example right away, although you might benefit from that further down the road. Just keep in mind that in the beginning to use them as it best suits you. Each chart will have an explanation of how to use it.
CONCLUSION
There’s a lot to learn with Helm, and it’s different from some traditional programming approaches, so it is best to take it one step at a time. You’ll be making waves faster than you think.
ABOUT STONE DOOR GROUP
Stone Door Group is a DevOps solutions integrator specializing in every flavor of Docker and Kubernetes. Our Docker CE-to-EE Accelerator℠ transforms your development instance of Docker CE into a compliant, enterprise container platform. For more information, drop us a line at letsdothis@stonedoorgroup.com.
ABOUT THE AUTHOR
Amber Ernst is a Docker Certified Associate and Docker Accredited Instructor for Stone Door Group, a Mirantis Value Added Reseller. Amber is a Docker and Kubernetes expert who currently teaches all courses in Docker’s official training catalogue and is based in San Antonio, TX.