To Helm and Back with
Harness Continuous Delivery
Helm helps you manage Kubernetes applications; Harness helps you deploy and verify them.
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:
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.
Step 3: Create Our Helm Deployment Workflow
Setup > My Application > Create 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.
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
Leave a Reply