Harness Continuous Delivery Supports Helm V3
The defacto package manager for Kubernetes, Helm, has been going through an evolution since being introduced at the first inaugural KubeCon a few years ago. The latest rendition of Helm is Helm V3 which was released late last year.
An argument against Helm in the past was an elevated Kubernetes Pod named Tiller used for execution. Though the Helm Project certainly took in all the concern and re-architect Helm V3 to not rely on Tiller anymore.
Harness recently released support for Helm V3 inside our platform. Let’s take a look at leveraging your first Helm V3 deployment. Though if you are unfamiliar with Helm, we can take a walk down memory lane.
Helm Refresher
There is a lot of Helm-related resources here at Harness. We have completely broken down Helm and hosted a recent webinar to get you dangerous. Though as a tl;dr Helm is a package manager for Kubernetes similar to Homebrew, RPM, Chocolatey, etc. Helm works off the concept of convention with charts and templates.
In the previous blog series, we leveraged an Amazon EKS cluster for our Kubernetes endpoint and walked through how to set one up using EKSCTL and getting KubeCTL on your machine. We will leverage EKS again. Though you can port this example to a Kubernetes endpoint of your liking. Helm V3 simplifies the steps that are needed.
Your First Helm V3 Deployment
Leveraging Helm V3 is simplified in operational steps since we don’t need to deploy Tiller anymore.
Like always can follow along with the blog and/or watch the video.
Kubernetes Infrastructure
I have an empty EKS Cluster named “Helm-in-a-Handbasket.”
You will need to install a Harness Delegate. We can install a Harness Delegate in a Kubernetes Cluster, EKS in this case. This is made simple can download the needed Kubernetes YAML and apply.
Navigate to the Harness Platform then Setup -> Harness Delegates -> Download Delegates -> Kubernetes YAML.
When prompted, give the Delegate a name of “helm” then click submit.
Once you click submit, a TAR.GZ will be downloaded. Unpack the TAR.
In the unpacked folder, install the harness-delegate.yaml with kubectl apply -f harness-delegate.yaml
After a few moments, the Kubernetes Delegate will be available with the name “helm-*”
Once the Harness Delegate is up, you can leverage a Delegate Profile to install the Helm V3 client on the Delegate. On the Delegate Page, click on Manage Delegate Profiles + Add Delegate Profile.
Create a Delegate Profile with the Display Name “Helm V3 Install” with the script from the Helm Project themselves.
#Install Helm
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh
Once you click Submit, you can run the Delegate Profile on a Delegate. Navigate to Profile and select “Helm V3 Install”.
Once the profile has executed, you now have Helm running on a Harness Delegate.
Next, you will need to wire the EKS Cluster as a Kubernetes Environment for Harness. This can be achieved by going to Setup -> Cloud Providers + Add Cloud Provider
Can fill in the prudent details about your Kubernetes Cluster by adding a type of Kubernetes Cluster and name kubernetes_cluster.
Once you hit Submit, the cluster will be available to deploy to.
Harness and Helm Workflow
With the Kubernetes items out of the way, time to get Harness more in the mix.
Create a new Harness Application by going to Setup -> Applications + Add Application. We can call the application “Helm in a Handbasket”.
Once created, let’s go wire the Helm Repository that we used in part one [https://charts.bitnami.com/bitnami] of the blog series. To add, go to Setup -> Connectors -> Artifact Servers + Add Artifact Server. We will be adding type of Helm Repository with display name of Bitnami Helm Repo.
Once you click Submit, the Helm Repository will be available.
Now you can add a Service by navigating back to the Application. Setup -> Helm in a Handbasket -> Services + Add Service called “Bitnami_Nginx”. This will be a deployment type of Helm and we will enable Helm V3.
Once you hit submit, can now wire the Chart Specifications by scrolling down to the middle of the UI and clicking on “Add Chart Specification”.
Let’s leverage similar details from part one of the original blog series. The Chart Name will be “bitnami/nginx” and the Chart Version will be “5.1.4”.
As time goes on, if you want the latest version of the chart you can leverage your local machine if you have Helm installed to find the latest version by adding the Bitnami Helm Repository by running helm repo add bitnami https://charts.bitnami.com/bitnami and searching by running helm search repo bitnami/nginx.
Click Submit and your Chart Specification will be there.
Now it’s time to give a home for your Helm Chart. Set up a Harness Environment by going to Setup -> Helm in a Handbasket -> Environments + Add Environment. In this case, adding Dev as a Non-Production Environment.
Once you click Submit, add an Infrastructure Definition in the middle of the UI with +Add Infrastructure Definition. Name “Helm_Hand_Basket” with the Cloud Provider as Kubernetes Cluster and Deployment Type as Helm. Select the Kubernetes Cluster that you wired in as a Cloud Provider.
Once you click submit the Infrastructure Definition will be there.
Next, you will create a Harness Workflow by going to Setup -> Helm in a Handbasket -> Workflows + Add Workflow. Add a workflow named “nginx_helm”.
Once you hit submit, you can add a Phase under Deployment Phases
Add the Service, Bitnami_Nginx, to the Workflow Phase.
Once you click submit, complete the Helm Deploy step by adding a Release Name.
Call this Release, “my_helm_release”.
Next, you can wrap the Workflow in a Pipeline by creating a Harness Pipeline by going to Setup -> Helm in a Handbasket -> Pipelines + Add Pipeline. Add a Pipeline named “Helm_Pipeline”.
Once you click Submit, add a Pipeline Stage.
Add an Execution Step named “Go for Gold”.
Once you click Submit, now it is time to run all your hard work and kick off a Harness Deployment. Now it is time to start your Harness Deployment. Can navigate to Continuous Deployment -> Start New Deployment.
Once you hit Submit, watch the magic happen!
Can log into your Kubernetes UI and see your release in the default Namespace.
Perfection and welcome Helm V3!
Onwards with Harness
The Harness Platform makes the adoption of technology crucial to your current and future pipelines simple. At Harness, we are integrating new platforms all the time. If there is not a platform we support we still make integration easy with several methods to integrate with a Harness Pipeline. If you have not had the chance to check out the Harness Software Delivery Platform, feel free to take it for a whirl. Doing something cool with Helm? We would love to hear from you on the Harness Community.