Decoupling the Helm Chart from the Deployment Artifact

Harness Experts
1

Decoupling the Helm Chart from the Artifact

Introduction

Some platform teams build out standardized Helm Charts so the development teams can deploy a majority of their applications without having to write their own helm charts. This approach allows a standardization on Helm Charts, less maintenance of those Helm Charts, and application teams can just focus on the values.yaml inputs for their specific application. The same helm chart can be deployed into any environment and leverage Harness’ templatization techniques, can extend the reusability of these charts to different services.

Implementation

Pre-Requisites

  1. Helm Chart

  2. Sits in a Helm Repository

  3. Or a Source Repo

  4. Git Connector

  5. Helm Repo Connector

  6. Harness Application

  7. Service

  8. Environment

  9. Rolling Workflow

Step 1 Configuring the Service

In the Helm Chart, we are going to need to manipulate some fields. One is the Container Image Spec in the Deployment.yaml file and the Values.yaml file “baked in with the chart”.

We are also going to configure the service so that container Image refers to

${artifact.metadata.image}

Image: {{.Values.image}}

In the values.yaml

Image: ${artifact.metadata.image}

Or

In the Deployment Spec:

image: {{ .Values.image.repository }}:{{ .Values.image.tag }}

In the Values.yaml

Image:
  Repository: ${artifact.source.repositoryName}
  Tag: ${artifact.buildNo}

This will give the user to select the artifact they want to deploy at runtime rather than using a hardcoded image baked into the chart.

We can also templatize the namespace we want to deploy this into, we can set namespace to namespace: {{.Values.Namespace}}

In the values.yaml:

namespace: ${serviceVariable.namespace}

This allows dev teams to deploy their artifact using the same chart to a different namespace
In the UI:

In the Harness UI we can templatize the Version of the chart we wish to pass in by passing in a ${workflow.variables.version}.

Configure a second service to link to the same Helm Manifests. Just select a different artifact source and define a different namespace.

To pass these configurations into the built-in the chart, rebuild and bake the Chart via your desired CI Tool and push it to the Helm Chart Repository.

Step 2: Workflow Variables Configuration

This allows platform teams to maintain a subset of charts and can control which versions of charts can be deployed. Or in most use cases it’s one core chart that can deploy numerous services. However, with a controlled set of versions, it allows dev teams more time to make sure the application fits the charts configuration.

For this example, I’m doing a Rolling Workflow for Kubernetes and Helm deployments, for a Helm V3 deployment I would configure via Basic Deployment

In this example, I’m locking 5.1.4, 5.1.3, and 5.1.2 to the workflow.variables.version as allowed values.

755×325 19.4 KB

Step 3: Environment Overrides

Dev teams will only have to maintain their values.yamls per environment. The platform team would own the base chart and the values.yaml would be per environment dictated by the team. In the Environment section, we can configure an environment override and target the values-dev.yml for this example to override the base values.yaml baked into the chart.

This approach allows secs to focus on their values.yaml inputs and application code, while the platform team only maintains the manifests to deploy.

Make sure the namespace is also templatized to the serviceVariable.namespace-dev

Step 4: Deploy the workflow and see the action

Deploy the workflow and view the output, you will see Harness pass in the templated values. By templating out the service in the workflow you can deploy a second service with different configuration (values.yaml) with the same chart and same workflow into the same environment.

You can leverage values.yaml overrides like so:

image

We can take it a step further and target different branches at run time.

I hope these ideas around templatization around decoupling Helm Charts from Artifacts, Helm users out as you journey through Harness.

1 Like