Bookmark this page

Install Applications by Using Helm Charts

Objectives

  • Install multi-container applications by using Helm Charts.

Deploy Applications with Helm

Developers commonly need to create standardized, reproducible, and predictable deployments of Kubernetes and Red Hat OpenShift resources. As the complexity of an application grows, for example the need for multiple microservices, supporting multiple Kubernetes environments, or managing stateful applications, the number of resources that developers maintain grows as well.

Helm is a Cloud Native Computing Foundation (CNCF) project that simplifies managing complex Kubernetes deployments. With Helm, developers define Helm charts, which contain the necessary YAML files for deploying and updating complex Kubernetes applications with a single Helm command. Developers then use Helm repositories to distribute charts, and use charts from other application developers. Companies can create private Helm repositories for deploying and managing internal applications.

Helm acts as a Kubernetes-native package manager that you can use to:

  • Deploy applications.

  • Customize your application deployment for different environments, for example Kubernetes and OpenShift.

  • Update your applications with an updated Helm chart.

  • Roll back to the previous deployment if the update does not work.

  • Uninstall applications.

Deploy Charts with Web Console

On Red Hat OpenShift, you can use the web console to deploy charts. Red Hat uses the openshift-helm-charts repository to distribute Helm charts that are compatible with OpenShift. OpenShift defines the openshift-helm-charts repository by default. In the developer view, click Helm to configure a new Helm repository, and see the installed Helm charts.

Click the Install a Helm chart from the developer catalog link to see the available charts.

Figure 6.1: Helm charts in the developer catalog

You can deploy any chart from the developer catalog by using web console.

Developers that use OpenShift can use charts from additional repositories as well. However, the chart developers must adhere to OpenShift security standards, such as not using the privileged root user by the deployed application. See the references section for a list of popular Helm repositories, such as:

  • IBM repositories

  • Helm Stable repositories

  • Bitnami repositories

  • Hashicorp repositories

Manage Charts with Helm CLI

You can use the Helm CLI to deploy applications to your Kubernetes cluster. To deploy an application, you require a Helm chart. To download charts, add a repository that contains the chart.

The following example shows adding the openshift-helm-charts repository to the Helm CLI.

[user@host ~]$ helm repository add openshift-helm-charts \
https://charts.openshift.io/
"openshift-helm-charts" has been added to your repositories

When you add a private registry, you can define the credentials when adding the repository, for example by using the --username and --password flags.

You can search the contents of the repository:

[user@host ~]$ helm search repo openshift-helm-charts
NAME                                              	CHART VERSION	APP VERSION 	DESCRIPTION
openshift-helm-charts/a10networks-a10tkc          	0.2.0        	1.16.0      	A Helm chart for A10 Thunder Kubernetes Connector
openshift-helm-charts/broadpeak-bks400            	0.2.0        	02.01.07    	BkS400 Helm chart for Kubernetes
openshift-helm-charts/castai-castai-agent         	0.52.0       	v0.42.2     	CAST AI agent deployment chart.
...output omitted...

Use the helm pull command to download a helm chart.

[user@host ~]$ helm pull openshift-helm-charts/redhat-quarkus \
--untar --destination redhat-quarkus
...no output expected...

The preceding example uses the --untar option to unpack the chart tar file. You can inspect the chart before you deploy it.

To upload your charts, use the helm package command to create a chart tar file.

[user@host ~]$ helm package my-chart-directory
Successfully packaged chart and saved it to: /home/user/example-chart-0.1.0.tgz

Then, use the helm push command to upload the packaged helm chart to your repository.

[user@host ~]$ helm push example-chart-0.1.0.tgz example.repository.org
...output omitted...

Finally, use the helm install command to install a remote or local chart.

[user@host ~]$ helm install my-quarkus-application \
openshift-helm-charts/redhat-quarkus \
--set replicaCount=3,image.tag=latest
...output omitted...
Your Quarkus app is building! To view the build logs, run:

oc logs bc/my-quarkus-application --follow
...output omitted...

The preceding example deploys the openshift-helm-charts/redhat-quarkus chart in your OpenShift cluster. The chart instance, or a Helm release, is called my-quarkus-application. The command uses the --set parameter to customize the chart's default templating values.

To install a local chart, specify the location of the chart on the local file system. The following example specifies the . location, which means the current working directory. This is useful, for example, when you develop a custom chart.

[user@host ~]$ helm install my-quarkus-application .
...output omitted...

You can view Helm releases, or applications that you installed by using Helm charts:

[user@host ~]$ helm ls
NAME                  	NAMESPACE  REVISION	UPDATED   STATUS  	CHART
my-quarkus-application	test	     1       	2022-...	deployed	quarkus-0.0.3
vertx-app             	test	     1       	2023-...	deployed	vertx-0.0.1

When the chart developer releases an updated chart, you can update your release:

[user@host ~]$ helm upgrade my-quarkus-application \
openshift-helm-charts/redhat-quarkus
...output omitted...
Release "my-quarkus-application" has been upgraded. Happy Helming!
NAME: my-quarkus-application
LAST DEPLOYED: Thu Aug 17 08:37:07 2023
NAMESPACE: multicontainer-helm
STATUS: deployed
REVISION: 2
TEST SUITE: None

Use helm history to list the release application history:

[user@host ~]$ helm history my-quarkus-application
...output omitted...
REVISION	UPDATED                 	STATUS    	CHART        		DESCRIPTION
1       	Thu Jun 06 08:36:13 2022	superseded	quarkus-0.0.2	 	Install complete
2       	Thu Aug 17 08:37:07 2023	deployed  	quarkus-0.0.3	 	Upgrade complete

If the new chart version does not work as you expect, you can roll back to the previous version. The following example rolls back the my-quarkus-application release to revision 1.

[user@host ~]$ helm rollback my-quarkus-application 1
...output omitted...
Rollback was a success! Happy Helming!

Finally, you can uninstall the release:

[user@host ~]$ helm uninstall my-quarkus-application
release "my-quarkus-application" uninstalled

Creating Helm Charts

To generate a Helm chart directory structure, use the helm create command:

[user@host ~]$ helm create my-helm-chart
Creating my-helm-chart

The previous command creates the following directory structure:

my-helm-chart/
├── charts
├── Chart.yaml
├── templates
│   ├── deployment.yaml
│   ├── _helpers.tpl
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── serviceaccount.yaml
│   ├── service.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

Charts contain the following important components:

Chart.yaml

This is the main chart file that contains the chart metadata. For example, it defines the chart name, its description, and version.

values.yaml

The values.yaml file contains variables that you can use to template your YAML files, for example:

replicaCount: 1

image:
  repository: nginx
  pullPolicy: IfNotPresent
templates

The templates directory holds the YAML files that you want to template and deploy. By default, Helm deploys all YAML files in this directory.

templates/NOTES.txt

This file configures the text that Helm prints after you install the chart. Typically, this file contains information about the deployed application, such as the application URL, or information about how developers can interact with the application.

Template YAML Files With Helm

Developers can create customizable Helm charts by using Helm templates. Helm templates use the Golang templating language to create customizable YAML files. To create a template, create a file in the templates directory, for example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      deployment: example-deployment
  strategy: {}
  template:
    metadata:
      labels:
        deployment: example-deployment
    spec:
      containers:
      - image: quay.io/example/deployment:1.0
        name: example-deployment

Then, use the templating language to customize the template to use the variables that you defined in the values.yaml file, for example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: {{ .Values.replicaCount }}
...deployment omitted...

You must place every template expression inside of double curly brackets: {{ }}. If an expression starts with a period and a capital letter, then it is referring to a file with the same name. In the preceding example, .Values refers to the values.yaml file, which contains the replicaCount variable.

If a file uses multiple variables, you can set the variable scope by using the with block, for example:

{{ with .Values.image }}
apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      deployment: example-deployment
  strategy: {}
  template:
    metadata:
      labels:
        deployment: example-deployment
    spec:
      containers:
      - image: {{ .repository | quote }}
        imagePullPolicy: {{ .pullPolicy | default "Always" | quote }}
        name: example-deployment
{{ end }}

The preceding example uses the with .Values.image variable as the context. Consequently, {{ .repository }} refers to the .Values.image.repository variable.

Additionally, the preceding example uses built-in template functions. For example, the quote function wraps the expression in double quotes and the default function provides a default value when the variable is not defined.

Template Flow Control in YAML Files

The Helm template language supports basic flow control. The following template shows a simple if condition.

...file omitted...
    spec:
      containers:
      - image: {{ .Values.image.repository | quote }}
        {{ if eq .Values.createSharedSecret "true" }}
        env:
          - name: DATABASE_NAME
            valueFrom:
              secretKeyRef:
                key: database-name
                name: postgresql
          - name: DATABASE_PASSWORD
            valueFrom:
              secretKeyRef:
                key: database-password
                name: postgresql
          - name: DATABASE_USER
            valueFrom:
              secretKeyRef:
                key: database-user
                name: postgresql
        {{ end }}
        name: example-deployment
...file omitted...

In the preceding example, the deployment defines the env parameter only if the .Values.createSharedSecret variable equals to true. See the references section for comprehensive Helm template language documentation.

Verify Templates

When you create templates, it is useful to verify that the templates are syntactically correct, which means that Helm can render the template. Use the helm template command to render all templates in the chart, for example:

[user@host ~]$ helm template .
---
# Source: my-helm-chart/templates/serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
...output omitted...

To render a specific template, use the --show-only parameter. The short -s parameter is an alternative to the --show-only parameter.

[user@host ~]$ helm template -s templates/serviceaccount.yaml .
---
# Source: my-helm-chart/templates/serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
...output omitted...

Similarly to installing a chart, you can template a remote chart as well, for example:

[user@host ~]$ helm template openshift-helm-charts/redhat-quarkus
---
# Source: quarkus/templates/service.yaml
apiVersion: v1
kind: Service
...output omitted...

This is useful to inspect the chart YAML files before deploying the chart without downloading the chart locally.

Revision: do288-4.12-0d49506