2 - Helm Services

Updated 1 week ago by Michael Cretzman

This topic describes how to create a Harness Application and adds a Service that uses a Docker image and Helm chart for a Kubernetes deployment.

Harness includes both Kubernetes and Helm deployments, and you can use Helm charts in both. Harness Kubernetes Deployments allow you to use your own Helm chart (remote or local), and Harness executes the Kubernetes API calls to build everything without Helm and Tiller needing to be installed in the target cluster. See Helm Charts.

Release Name Required

When using a Native Helm deployment in Harness, ensure that the workload-related manifests include a Release Name in their metadata. For an example, see this StatefulSet spec from Artifactory.

You can see that the release name is under:

  • metadata.labels
  • spec.selector.matchLabels
  • spec.template.metadata.labels

Harness requires a release name for tracking different deployments as well as tracking resources deployed under that release.

The release name must be unique across the cluster.

Create the Harness Application

An application in Harness represents a logical group of one or more entities, including Services, Environments, Workflows, Pipelines, Triggers, and Infrastructure Provisioners. Applications organize all of the entities and configurations in Harness CI/CD. For more information, see Application Checklist.

To add the Harness Application and service, do the following:

  1. In Harness, click Setup.
  2. Click Add Application. The Application dialog appears.
  3. Give your application a name that describes your microservice or app. For the purposes of this guide, we use the name Docker-Helm.
  4. Click SUBMIT. The new application is added.
  5. Click the application name to open the application. The application entities are displayed.

Add the Helm Service to the Application

  1. In your new application, click Services. The Services page appears.
  2. In the Services page, click Add Service. The Service dialog appears.
  3. In Name, enter a name for your microservice. For example, if your microservice were the checkout service in a Web application, you could name it checkout. For this guide, we will use Docker-Helm.
  4. In Deployment Type, select Native Helm. Harness will create a service that is designed for Helm deployments. When you are finished, the dialog will look like this:
  5. Select Enable Helm V3. This ensures that you are using the latest Helm settings.
  6. Click SUBMIT. The new service is added. Let's look at where Docker and Helm are configured in the Service page:

The following table describes the different sections.

Component

Section in Service

Description

Docker

Artifact Source

You add a pointer to the Docker image location you want to deploy.

Helm

Chart Specification

You enter the Helm chart repo and chart to use.

Typically, this is the only Helm configuration needed in a Harness service.

This is the easiest way to point to your chart, but you can add the chart info in Values YAML Override instead.

Helm

Values YAML Override

You can enter the contents of a Helm values.yaml file here. This file contains the default values for a chart.

Values entered here will overwrite values in the values.yaml entered in Chart Specification.

If you want to point to your Helm chart here, you can simply add the YAML:

harness:
 helm:
   chart:
     name: nginx
     version: 1.0.1
     url: https://charts.bitnami.com/bitnami

Add the Docker Artifact Source

  1. In the new service, click AddArtifact Source, and select Docker Registry. There are a number of artifact sources you can use. For more information, see Add a Docker Image Server. The Docker Registry dialog appears.
  2. In Name, let Harness generate a name for the source.
  3. In Source Server, select the Artifact Server you added earlier in this guide. We are using Docker Hub in this guide.
  4. In Docker Image Name, enter the image name. Official images in public repos such as Docker Hub need the label library. For example, library/nginx. For this guide, we will use Docker Hub and the publicly available NGINX at library/nginx.
  5. Click SUBMIT. The Artifact Source is added.

Add the Helm Chart

As explained earlier, you have two options when entering in the Helm chart info. The Chart Specifications or the Values YAML. For this guide, we will use the Chart Specifications.

  1. Click Chart Specifications. The Chart Specification settings appear.
  2. In Location, select Helm Repository or Source Repository.

For Source Repository, do the following:

  1. In Source Repository, select a Git SourceRepo Provider for the Git repo you added to your Harness account. For more information, see Add SourceRepo Providers.
  2. In Commit ID, select Latest from Branch or Specific Commit ID.
  3. In Branch or Commit ID, enter the branch or commit ID for the remote repo.
  4. In File/Folder path, enter the repo file and folder path.
If your Helm chart in a Git repo has chart dependencies, use the Helm Repository option.

For Helm Repository, do the following:

  1. In Helm Repository, select the Helm Chart Repository you added as a Harness Artifact Server. For more information, see Helm Repository.
If you are using Google Cloud Storage for your Helm repo, you will see a Base Path setting for the bucket. See Google Cloud Storage (GCS) for details on the policies required.
  1. In Base Path, enter the path to the charts' bucket folder or a Workflow variable expression.
    1. If you use a charts' bucket folder, simply enter the name of the folder. Whether you need to specify a single folder (e.g. charts) a folder path (e.g. helm/charts) depends on the Helm Chart Repository you added as a Harness Artifact Server.
    2. If you use a Workflow variable expression, you can enter in the expression as part of the path. For example, /Myservice/Chart/${workflow.variables.branchName}/ or simply ${workflow.variables.chartFolder}.
    1. If the chart is in the root folder of the repository location set in the Helm Chart Repository you added as a Harness Artifact Server, leave Base Path empty.
  2. In Chart Name, enter the name of the chart in that repo.
  3. In Chart Version, enter the chart version to use. This is found in the Chart.yaml version label. If you leave this field empty Harness gets the latest chart.

Here are a couple of examples using GCS and S3:

Here is an example using a Workflow variable expression. You can see the variable created in the Workflow's Workflow Variables section, referenced using an expression in Chart Specification, and then a value provided for the variable in the deployment dialog that matches the chart folder's name.

  1. To use Helm command flags, click Enable Command Flags, and then enter the command to use.
  2. Click SUBMIT. The chart specification is added to the service.

When you deploy a Workflow using a Harness Kubernetes Service set up with a Helm Repository, you will see Harness fetch the chart:

Next, you will see Harness initialize using the chart:

Release Name Required

Ensure that the workload-related manifests include a Release Name in their metadata.

See Release Name Required.

Other Options

You can specify other options in the Chart Specification dialog by choosing None in the Helm Repository field, and the using the remaining fields as described in the following table.

These options are provided for backwards-compatibility and it is preferable that you use either the Helm Repository or Source Repository options.

Installation Method

Example

Field Values

Chart reference.

helm install stable/nginx

Chart Name: stable/nginx

Path to a packaged chart.In this method, the chart file is located on the same pod as the Harness Delegate.You can add a Delegate Profile that copies the chart from a repo to the pod. For more information, see Delegate Profiles.

helm install ./nginx-1.2.3.tgz

Chart Name: dir_path_to_delegate/nginx

Path to an unpacked chart directory.In this method, the chart file is located on the same pod as the Harness delegate.You can add a Delegate Profile that copies the chart from a repo to the pod. For more information, see Delegate Profiles.

helm install ./nginx

Chart Name: dir_path_to_delegate/nginx

Absolute URL.

helm install https://example.com/charts/nginx-1.2.3.tgz

Chart Name: https://example.com/charts/nginx-1.2.3.tgz

For Helm, that's it. You don't have to do any further configuration to the service. Harness will use the chart you specified to configure the Kubernetes cluster.

File-based repo triggers are a powerful feature of Harness that lets you set a Webhook on your repo to trigger a Harness Workflow or Pipeline when a Push event occurs in the repo. For more information, see File-based Repo Triggers.

Now you can define the deployment environment and workflow for the deployment.

Option: Helm Command Flags

Currently, this feature is behind a Feature Flag. Contact Harness Support to enable the feature. Feature Flags can only be removed for Harness Professional and Essentials editions. Once the feature is released to a general audience, it is available for Trial and Community Editions.

Enable this option to have Harness run Helm commands and their options when this Helm chart is deployed.

You can use the following commands and all of their options:

Global Command

For Global Command, enter Helm options that you want applied to every Helm command executed at deployment runtime.

For example, --debug--tls (Helm v2 only), --tiller-namespace (Helm v2 only).

At runtime the command is applied like this:

helm get manifest --tls nginx-gcp-k8s-helm-rjogwmu

Harness Variable Expressions are Supported

You can use Harness variable expressions in any of the command options settings. For example, Service Config variables and Workflow variables.

Spec Requirements for Steady State Check and Verification

Harness requires that the release: {{ .Release.Name }} label be used in every Kubernetes spec to ensure that Harness can identify a release, check its steady state, and perform verification on it.

Ensure that the release: {{ .Release.Name }} label is in every Kubernetes object's manifest. If you omit the release: {{ .Release.Name }} label from a manifest, Harness cannot track it.

The Helm built-in Release object describes the release and allows Harness to identify each release. For this reason, the release: {{ .Release.Name }} label must be used in your Kubernetes spec. For example:

apiVersion: v1
kind: Service
metadata:
name: {{ template "todolist.fullname" . }}
namespace: {{ .Values.namespace }}
labels:
app: {{ template "todolist.name" . }}
chart: {{ template "todolist.chart" . }}
release: {{ .Release.Name }}
heritage: {{ .Release.Service }}
...

You will provide a name to be used in place of {{ .Release.Name }} in the Helm Workflow you create in Harness. The Workflow contains the Helm Deploy step, where you can enter in a release name to replace {{ .Release.Name }} at runtime:

For information on the Helm Deploy step, see Helm Deploy.

Values YAML Override

In the Values YAML Override section, you can enter the YAML for your values.yaml file. The values.yaml file contains the default values for a chart. You will typically have this file in the repo for your chart, but you can add it in the Harness service instead.

The Values YAML dialog has the following placeholders that save you from having to enter in some variables:

  • ${NAMESPACE} - Replaced with the Kubernetes namespace, such as default. You will specify the namespace of the cluster in the Namespace setting when adding the Harness Environment infrastructure details later, and the placeholder will be replaced with that namespace.
  • ${DOCKER_IMAGE_NAME} - Replaced with the Docker image name.
  • ${DOCKER_IMAGE_TAG} - Replaced with the Docker image tag.

For information about how values from different source are compiled at runtime, see Helm Values Priority.

You can override the values using the Local or Remote options.

For Remote, do the following:

  1. In Source Repository, select the Git repo you added as a Source Repo Provider.
  2. For Commit ID, select either Latest from Branch and enter in the branch name, or Specific Commit ID and enter in the commit ID.
  3. In File path, enter the path to the values.yaml file in the repo, including the repo name, like helm/values.yaml.

Next Step


How did we do?