Deploy Helm Charts

Updated 3 weeks ago by Michael Cretzman

Typically, Harness Kubernetes deployments using Helm charts involve adding your artifact (image) to Harness in addition to your chart. The chart refers to the artifact you added to Harness (via its values.yaml). During deployment, Harness deploys the artifact you added to Harness and uses the chart to manage it.

For the standard Harness Kubernetes and Native Helm deployments using Helm charts, see Use a Helm Repository with Kubernetes and Helm Quickstart.

In addition to this method, you can also simply deploy the Helm chart without adding your artifact to Harness. Instead, the Helm chart identifies the artifact. Harness installs the chart, gets the artifact from the repo, and then installs the artifact. We call this a Helm chart deployment.

This topic covers the second method: a Helm chart deployment.

Currently, deploying the Helm chart without adding your artifact to Harness is in Beta and 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.

New to Harness Kubernetes and Native Helm Deployments?
Harness includes both Kubernetes and Native Helm deployments, and you can use Helm charts in both. Here's the difference:
Harness Kubernetes Deployments allow you to use your own Kubernetes manifests or a 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.
• Harness Kubernetes deployments also support all deployment strategies (Canary, Blue/Green, Rolling, etc).
• For Harness Native Helm Deployments, you must always have Helm and Tiller running on one pod in your target cluster. Tiller makes the API calls to Kubernetes in these cases.
• Harness Native Helm deployments only support Basic deployments.

In this topic:

Before You Begin

Supported Platforms and Technologies

See Supported Platforms and Technologies.

Step 1: Add a Helm Repository Artifact Server

You connect Harness to a Helm Chart Repository as a Harness Artifact Server and then use it in Harness Kubernetes and Native Helm Services.

To add the Helm Repository Artifact Server for your chart repo, follow the steps in Add Helm Repository Artifact Servers.

Step 2: Create the Harness Service

Deploying Helm charts is supported in both Harness Kubernetes or Native Helm deployments.

  1. In your Harness Application, click Services, and then click Add Service.
  2. Enter a name for the Service.
  3. In Deployment Type, select either Kubernetes or Native Helm. If you select Native Helm, you can enable Helm v3.
  4. Click Submit. The new Service is created.

Now you can add you Helm chart.

Step 3: Add the Helm Chart

The Helm chart is added the same way in both the Harness Kubernetes or Native Helm Services.

Ignore the Add Artifact Source setting. You will not be adding your artifact source this way.

The artifact source is specified in your Helm chart values.yaml using the image block just as you normally configure your Helm files.

  • For a Kubernetes Service, in Manifests, click more options, and then click Edit.
  • For a new Native Helm Service, in Chart Specification, click Add Chart Specification.

Kubernetes Service

  1. In Manifests, click more options, and then click Edit.
  2. In Manifest Format, select Helm Chart from Helm Repository.
    Chart polling is only available for Helm charts in a Helm repository, and not for Helm charts is a source (Git) repository.
  3. In Helm Repository, select the Helm Repository Artifact Server you set up.
  4. In Chart Name, enter the name of the Helm chart to deploy.
    Do not template the Chart Name setting using a Harness expression variable. When you enable Poll Manifest Changes (below), it will need the name of the chart to poll for versions.
  5. Leave Chart Version empty. Harness will poll all versions of the chart so you can select which version you want to deploy.
  6. Click Poll Manifest Changes. This enables Harness to poll all versions of the chart so you can select which version you want to deploy.
    When you deselect Poll Manifest Changes all collected Helm chart versions are deleted.
  7. Click Submit.

The remote Helm chart repository and chart is listed.

Native Helm Service

  1. In Chart Specification, click more options, and then click Edit.
  2. In Location, select Helm Repository.
    Chart polling is only available for Helm charts in a Helm repository, and not for Helm charts is a source (Git) repository.
  3. In Helm Repository, select the Helm Repository Artifact Server you set up.
  4. In Chart Name, enter the name of the Helm chart to deploy.
    Do not template the Chart Name setting using a Harness expression variable. When you enable Poll Manifest Changes (below), it will need the name of the chart to poll for versions.
  5. Leave Chart Version empty. Harness will poll all versions of the chart so you can select which version you want to deploy.
  6. Click Poll Manifest Changes. This enables Harness to poll all versions of the chart so you can select which version you want to deploy.
    When you deselect Poll Manifest Changes all collected Helm chart versions are deleted.
  7. Click Submit.

The remote Helm chart repository and chart is listed.

Option: 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 added in the Harness Service will override the values.yaml in your remote repo.

See Override Values YAML Files and Helm Services.

The Values YAML Override settings can be overwritten by Harness Environments Service Configuration Overrides. See below.

Step 4: Define the Infrastructure Definition

There is nothing unique about defining the target cluster Infrastructure Definition for a Helm chart deployment. It is the same process as a typical Harness Kubernetes or Native Helm deployment.

Follow the steps in Define Your Kubernetes Target Infrastructure or Helm Environments.

Option: Override Helm Chart in Environment

You can override the Helm chart specified in your Harness Service by specifying a different Helm chart in a Harness Environment.

This enables you to have a Service keep its Helm chart but change it when the Service is deployed to different Environments.

For example, you might have a single Service but an Environment for QA and an Environment for Production, and you want to overwrite the chart depending on the Environment.

For details, see Override Harness Kubernetes Service Settings or Helm Environments.

  1. In the Harness Environment, in Service Configuration Overrides, click Add Configuration Overrides.
  2. In Service, select the Harness Service where you added your remote Helm chart.
  3. In Override Type, select helm Chart.
  4. In Helm Repository, select the Helm Repository Artifact Server you set up.
  5. Click Submit.

The remote Helm chart repository is listed.

Option: Override Values YAML in Environment

Harness Service Values YAML Override settings can be overwritten by Harness Environments Service Configuration Overrides.

This enables you to have a Service keep its settings but change them when the Service is deployed to different Environments.

For example, you might have a single Service but an Environment for QA and an Environment for Production, and you want to overwrite the namespace setting in the Service's Values YAML Override values.yaml depending on the Environment.

You can also overwrite Service variables at the Phase-level of a multiple Phase Workflow.

For details, see Override Harness Kubernetes Service Settings or Helm Environments.

  1. In the Harness Environment, in Service Configuration Overrides, click Add Configuration Overrides.
  2. In Service, select the Harness Service where you added your remote Helm chart.
  3. In Override Type, select Values YAML. Click Local or Remote.
    1. Local - Enter in the values.yaml variables and values just as your would in a Service Manifests values.yaml. Ensure the name of the variable you want to overwrite is identical.
    2. Remote - See Override Remote Values YAML Files.
  4. When you are done, click Submit.

Step 5: Create the Workflow

Now that your Service and Infrastructure Definition are set up, you can create the Workflow for your Helm chart deployment.

Harness Native Helm deployments only support Basic Workflow deployments.

You create your Kubernetes or Native Helm Workflows just as you would if the Service you are deploying is using a Artifact Source. There is nothing different you need to do when using a Helm chart exclusively.

The only difference when deploying Helm chart Workflows is that you select the

For steps on creating Kubernetes Workflows, see:

For steps on creating a Native Helm Basic Workflow, see Helm Workflows and Deployments.

Step 6: Deploy

Each Helm chart deployment is treated as a release. During deployment, when Harness detects that there is a previous release for the chart, it upgrades the chart to the new release.

  1. In the Workflow, click Deploy. The Start New Deployment settings appear. Here you will pick the chart version to deploy.
  2. In Version, select a version of the chart to deploy.
  3. Click Submit.

The Helm chart deployment runs.

For a Kubernetes or Native Helm deployment you will see Harness fetch the Helm chart. Here is an example from a Kubernetes deployment:

Fetching files from helm chart repo
Helm repository: Helm Chart Repo
Chart name: chartmuseum
Chart version: 2.14.0
Helm version: V2
Repo url: http://storage.googleapis.com/kubernetes-charts/
Successfully fetched following files:
- helm/repository/repositories.yaml
- helm/repository/local/index.yaml
- helm/repository/cache/local-index.yaml
- helm/repository/cache/b83a7c1d-4cec-3655-9a3c-db9de73510fd-index.yaml
- chartmuseum/values.yaml
- chartmuseum/README.md
- chartmuseum/ci/ingress-values.yaml
- chartmuseum/Chart.yaml
- chartmuseum/templates/ingress.yaml
- chartmuseum/templates/pvc.yaml
- chartmuseum/templates/service.yaml
- chartmuseum/templates/NOTES.txt
- chartmuseum/templates/servicemonitor.yaml
- chartmuseum/templates/serviceaccount.yaml
- chartmuseum/templates/pv.yaml
- chartmuseum/templates/secret.yaml
- chartmuseum/templates/_helpers.tpl
- chartmuseum/templates/deployment.yaml
- chartmuseum/.helmignore

Done.

Next, Harness will initialize and prepare the workloads, apply the Kubernetes manifests, and wait for steady state.

In Wait for Steady State you will see the Kubernetes workloads deployed and the pods scaled up and running:

Deployed Controllers [3]:
Kind:Deployment, Name:doc-chartmuseum (desired: 1)
Kind:ReplicaSet, Name:doc-chartmuseum-75bffc6fc7 (desired: 1)
Kind:ReplicaSet, Name:doc-chartmuseum-766fc995c (desired: 1)

**** Kubernetes Controller Events ****
Controller: doc-chartmuseum
- Scaled up replica set doc-chartmuseum-75bffc6fc7 to 1


**** Kubernetes Pod Events ****
Pod: doc-chartmuseum-75bffc6fc7-k5tfb
- Successfully assigned default/doc-chartmuseum-75bffc6fc7-k5tfb to aks-delegatepool-37455690-vmss000000
- Pulling image "chartmuseum/chartmuseum:v0.7.0"
- Successfully pulled image "chartmuseum/chartmuseum:v0.7.0"
- Created container chartmuseum
- Started container chartmuseum

Waiting for desired number of pods [2/1]
Waiting for desired number of pods [2/1]
Waiting for desired number of pods [2/1]

**** Kubernetes Controller Events ****
Controller: doc-chartmuseum
- Scaled down replica set doc-chartmuseum-766fc995c to 0

Desired number of pods reached [1/1]
Pods are updated with image [chartmuseum/chartmuseum:v0.7.0] [1/1]
Pods are running [1/1]
Pods have reached steady state [1/1]
Pod [doc-chartmuseum-75bffc6fc7-k5tfb] is running. Host IP: 10.240.0.5. Pod IP: 10.244.2.204

Done

You deployment is successful.

Versioning and Rollback

Helm chart deployments support versioning and rollback in the same way as Kubernetes and Native Helm deployments.

For Helm chart deployments, the Helm chart version is selected at runtime, and versioning is based on that selection.

Review: Helm Artifact Variable Expressions

Harness includes several built-in variable expressions that you can use to output Helm chart deployment information:

  • ${helmChart.description} - The description in the Helm chart.
  • ${helmChart.displayName} - The display name of the chart.
  • ${helmChart.metadata.basePath} - The base path used for Helm charts stored in AWS S3 and Google GCS.
  • ${helmChart.metadata.bucketName} - The S3 or GCS bucket name, if used.
  • ${helmChart.metadata.repositoryName} - The name setting for the repo.
  • ${helmChart.metadata.url} - The URL from where the chart was pulled.
  • ${helmChart.name} - The name in the chart.
  • ${helmChart.version} - The version of the chart that was deployed.

You can use these expressions in a Shell Script Workflow step after the deployment step in the Workflow:

echo "description: ${helmChart.description}"
echo "displayName: ${helmChart.displayName}"
echo "basePath: ${helmChart.metadata.basePath}"
echo "bucketName: ${helmChart.metadata.bucketName}"
echo "repositoryName: ${helmChart.metadata.repositoryName}"
echo "metadataURL: ${helmChart.metadata.url}"
echo "Chart name: ${helmChart.name}"
echo "Version: ${helmChart.version}"

The output will be something like this:

description: Host your own Helm Chart Repository
displayName: chartmuseum-2.14.0
basePath: null
bucketName: null
repositoryName: Helm Chart Repo
metadataURL: http://storage.googleapis.com/kubernetes-charts/
Chart name: chartmuseum
Version: 2.14.0

Review: Helm Artifacts in Pipelines and Triggers

You can add your Workflow to a stage in a Harness Pipeline or have it executed by a Harness Trigger.

In both cases, you can select the Helm chart version you want to deploy.

Pipeline

Once you add the Workflow to a stage in a Pipeline, you must select the Helm chart version for deployment when you deploy the Pipeline.

The steps are the same as when deploying the Workflow. You select a chart version:

Trigger

If your Harness Service has polling enabled for its Helm Chart (using the Poll Manifest Changes option), you can create a Trigger for any Workflow or Pipeline to run when a new version of the chart is published.

  1. In your Harness Application, click Triggers.
  2. Click Add Trigger. The Trigger settings appear.
  3. In Name, enter a name for the Trigger. This name will appear in the Deployments page to indicate the Trigger that initiated a deployment.
  4. Click Next.
  5. In Condition, select On Manifest Changes.
  6. In Services, select the Service using the Helm chart. You can use regex to filter names if needed.
  7. Click Next.
  8. In Actions, there are three main settings:
  • From Triggering Manifest: Select this option to use the chart identified in Service you selected in Condition.
  • Last Collected: Select this option to use the last version collected by Harness in the Harness Service. Chart versions are collected automatically every minute by Harness.
  • Last Successfully Deployed: The last chart that was deployed by the Workflow you selected. In Workflow, select the Workflow to run.
  1. Click Submit. The Trigger is created.

Configure As Code

To see how to configure the settings in this topic using YAML, configure the settings in the UI first, and then click the YAML editor button (</>).


How did we do?