To Helm and Back with
Harness Continuous Delivery

Helm helps you manage Kubernetes applications; Harness helps you deploy and verify them.

By Steve Burton
April 26, 2018

As good as Kuberenetes is, it’s not a magical silver bullet.

Applications today are as complex as they have ever been. Despite the buzz around independent microservices, most architectures and services have many dependencies.

Helm allows you to package up and manage those service dependencies. Instead of managing multiple artifacts, config, and scripts, you declare and bundle everything into something called a Helm Chart.

Charts describe and encapsulate all the complex stuff in your apps. They make Kubernetes deployments and rollbacks easy, repeatable, and consistent.

Two weeks ago, Harness shipped support for Helm Charts. This is how it works in four easy steps:

Step 1: Create Our Helm Service

As an example, let’s deploy Jenkins to an environment using Helm and Harness.

Navigate to: Setup > My Application > Create Service

First, we enter the name of our service (Helm Jenkins) and then reference the Jenkins docker image from our artifact repository.

Second, we check “Helm” as our deployment specification:

create_service

From here we enter our Helm Chart URL, name, and version (optional). If no version is entered, Harness will just pull the latest.

Lastly, you can optionally override your Helm Value YAML with a simple cut and paste.

Step 2: Create Our Environment To Deploy To

Setup > My Application > Create Environment

We simply select “Helm Jenkins” from the Service drop-down menu, pick “Helm” as our deployment type and select “GCP” as the Cloud Provider account we want to use.

Next, we select the Cluster and Namespace from GCP we wish to deploy to and click “Submit.” All done.

helm_environment

Step 3: Create Our Helm Deployment Workflow

Setup > My Application > Create Workflow

helm_workflow

Step 4: Verify Our Helm Jenkins Deployment

Helm itself does not perform any deployment checks or wait for resources to attain a steady-state. It simply kicks off the deployment process.

Harness adds several polling checks on top of Helm to ensure a Helm application reaches its steady-state and all pods/resources are available. If anything fails we provide deep logging and visibility so you know why your Helm deployment failed.

In addition, we can then add verification criteria to make sure our Jenkins app was deployed correctly so it reached a successful steady-state. At Harness, we call this process “Continuous Verification” so customers know whether their deployments were successful.

For example, I’ve added three simple verifications to our Jenkins app deployment workflow:

  • HTTP assertion (check Jenkins app is up)
  • AppDynamics (check performance of pages is good)
  • Splunk (check no new errors or exceptions are observed)

If all our verifications pass, then our Helm Jenkins deployment will succeed. If any fail, Harness will automatically roll back to the previous working artifact and configuration (assuming these existed). Helm automatically version controls all artifacts, specifications, and configuration. Harness simply initiates the rollback.

Helm_Rollback

Rollback is entirely optional, of course; you can add your own command or manual intervention.

That’s it. You can build a Helm deployment pipeline in about 56 seconds.

Cheers,
Steve.

@BurtonSays

 

➞ Back to Blog

Leave a Reply

avatar
  Subscribe  
Notify of