Helm – Part-2: Helm Chart files and Folder Structure Tutorial

The chart in the Helm is nothing but the packaging format of Helm. In simple words, Helm Charts is the set of files that will have the description of Kubernetes clusters and resources. In our previous article, we have discussed Helm and get introduced to Helm Charts, Components, and Installation. In this article, we will discuss Helm Chart Templates Tutorial explaining how to write Helm Charts and Helm Chart Templates.

File and Directory structure of Helm chart.

Just like any other package manager, helm charts are the set and combination of files and directories. So, when we execute the helm create command, these files and directory structures will be created. Example:

$ helm create my-chart

This will create the following files and directories in the present working directory.

• Chart.yaml
• values.yaml
• template/
• charts/

Let’s discuss all these one by one.

Chart.yaml file

Chart.yaml is the file which contains the information about the metadata and basic API information about the Chart. Following is a sample file of helm Chart.yaml

apiVersion: The chart API version (required)
name: The name of the chart (required)
version: A SemVer 2 version (required)
kubeVersion: A SemVer range of compatible Kubernetes versions (optional)
description: A single-sentence description of this project (optional)
type: The type of the chart (optional)
keywords:
  - A list of keywords about this project (optional)
home: The URL of this projects home page (optional)
sources:
  - A list of URLs to source code for this project (optional)
dependencies: # A list of the chart requirements (optional)
  - name: The name of the chart (nginx)
    version: The version of the chart ("1.2.3")
    repository: (optional) The repository URL ("https://example.com/charts") or alias ("@repo-name")
    condition: (optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled )
    tags: # (optional)
      - Tags can be used to group charts for enabling/disabling together
    import-values: # (optional)
      - ImportValues holds the mapping of source values to parent key to be imported. Each item can be a string or pair of child/parent sublist items.
    alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times
maintainers: # (optional)
  - name: The maintainers name (required for each maintainer)
    email: The maintainers email (optional for each maintainer)
    url: A URL for the maintainer (optional for each maintainer)
icon: A URL to an SVG or PNG image to be used as an icon (optional).
appVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended.
deprecated: Whether this chart is deprecated (optional, boolean)
annotations:
  example: A list of annotations keyed by name (optional).

Values.yaml file

Then, we have values.yaml file. This file will have the values like Image parameters, Dependencies, Configurations. This will always override the values which are defined in the chart file.  Here are some samples.

global:
  imageRegistry: "https://hub.docker.com"
  imagePullSecrets: []
  storageClass: ""

ServiceEndpoint: "http://classendpoint:4343/get/id"

Basically, These values are the built-in object of the Helm that will be utilized in the Chart files. So, We can also pass the values to the commands from external files. For example.

$ helm install -f path/to/myvals.yaml ./mychart

Otherwise, values mentioned in the file can be easily accessed using the template. Assume the “serviceEndpoint” value in the chart file and we can use it in the template as below.

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  myvalue: "Hello World"
  drink: {{ .Values.ServiceEndpoint }}

So, when it is rendering the template file, the value will be appended here.

Templates Folder.

Just like values and Chart files, we have a template/ folder created under the same directory when you execute the helm create command. This particular folder will have the default folders as mentioned below.

• NOTES.txt
• deployment.yaml
• service.yaml
• _helper.tpl

NOTE.txt file is like the document file which will be displayed when you run the helm install command.

Deployment.yaml will have the manifest to create Kubernetes Deployment objects.

Service.yaml is the file which will have the manifest for creating a service endpoint you’re your deployments.

_helpers.tpl file will have the re-usable component throughout the chart.

Charts/ folder

So, charts/ folder will carry any of the charts that the user is going to create. We can say it as dependencies of the main chart.yaml file. Say for example, If we are going to create WordPress site using Kubernetes and we are going to deploy the same using the helm charts. So, we can create a directory structure as mentioned below.

Charts.yaml
..
..
Charts/
	wordpress/
		Charts.yaml
		..
		..
	mysql/
		Chart.yaml
		..
		..

The Chart.yaml file defined inside the subdirectories is called as child chart or sub chart. And every file can fetch its own values.yaml.

How to create a Template

As the first step of creating the Helm chart, we will create a ConfigMap Template, we need to create a template file called configmaps.yaml file. This file should contain the following lines.

apiVersion: v1
kind: ConfigMap
metadata:
  name: mychart-configmap
data:
  myvalue: "Sample Config Map"

Basically, this file will simply store the information that will help Kubernetes to have its object to store configuration data. In this file, myvalue: “sample Config Map” is the key value pair that will be sent to the Kubernetes.

To apply the above configuration to the cluster, we need to run the following command.

$ helm install helm-demo-configmap ./my-chart

So, when you check the Kubernetes cluster, you can see the ConfigMap created by using the Helm chart template that we created now.

Kubernetes Communications

If you have your Kubernetes clusters running on your local, then you don’t worry about the configurations. But if you are running the Kubernetes cluster on remote, you need to tell Helm about the Kubernetes communication.

The Teller of the Helm will take care of communicating the Kubernetes cluster with the Helm service. To do so, we need to create the serviceaccount in the Kubernetes.

$ kubectl -n kube-system create serviceaccount tiller

Now, you need to bind the

$ kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller

Then if you run the helm init with the service account mapped with the teller, then the helm will know where to install it.

Conclusion

In this article, we discussed the Helm Chart files and Folder Structurelm Charts and discussed a simple template file by creating it and installing it into the Kubernetes Cluster. In our upcoming article, we will discuss various built-in objects of Helm, functions in the template, Subcharts, control flow and, more. Stay tuned and subscribe DigitalVarys for more articles and study materials on DevOps, Agile, DevSecOps, and App Development.