Accelerating Harness CD & GitOps Learning for New Users
To address the need of accelerated learning for new users especially when using the Harness CD & GitOps Free plan, we are pleased to announce the public preview of a new “Get Started” UI that takes the user through a guided learning journey. This UI is available for all users (including those in the Team & Enterprise Plans) starting today and uses sample apps that are publicly available at the harnesscd-example-apps repo. This repo is forked from the popular argocd-example-apps repo to remove the burden of learning even a new sample app. Additionally, it automates the necessary setup of Harness resources using the newly announced, open source Harness CLI. Refer to this blog post to learn more about the Harness CLI.
Harness CD & GitOps is easily the most advanced solution on the market today for automating complex application deployments at scale. It supports the automated deployment of multiple types of applications (such as containerized, serverless or traditional/monolithic and more) onto multiple types of infrastructure platforms (such as Kubernetes/GitOps, AWS ECS/Lambda/EC2, Google Cloud Functions/VMs, private data centers and more). And it does so while using golden pipeline templates that codify the governance standards of an organization.
However, this breadth and depth of functionality can come across as intimidating to a new user who wants to learn the basics of Continuous Delivery and Continuous Deployment using a structured, guided path. Note the focus on learning the “Continuous” part here since a manual deployment from your local machine onto your target infrastructure while being the simplest does not provide the ability to automate deployments to test and production environments as soon as new artifacts or container images are available as outputs of your CI pipeline.
Key Features
- Coverage for an extensive breadth of 16 deployment types with more on the way.
- Kubernetes: 4 types covering Kubernetes Manifest, Helm Chart (both Kubernetes Helm & Native Helm) and Kustomize using the push-based CD pipeline approach. Note that pull-based GitOps for these same deployment categories will be available soon on the UI, which will add another 4 types. You can see GitOps deployments in action using the Harness CLI till then.
- Serverless: 4 types covering AWS Lambda (Native as well as via Serverless.com Framework) and Google Cloud (Gen1 and Gen2).
- Traditional App: 4 types covering AWS and Physical Data Center deployments using both SSH and WinRM approaches.
- Easy setup through pre-populated commands specific to your Harness account (such as login using API token) and GitHub username/PAT.
- Use of the Harness CLI to simplify setup of all Harness resources such as pipeline, service, environment, connectors and more.
- Step-by-step tutorials on Harness Developer Hub for the same scenarios with instructions on how to use the sample app as a starting point for bringing your own app to Harness.
Take it for a Spin - Video Tutorial
Thanks to Nicholas Lotz, our new Developer Advocate, you can get started here by simply watching a video.
Take it for a Spin - Step-by-Step Tutorial
For this blog post, we will see how to do a canary deployment of a Kubernetes Helm Chart using the new UI.
Prerequisites
Setup your Kubernetes cluster
You should have access to a Kubernetes cluster. For simplicity, we will use minikube in this post.
Create free Harness account
You will need a Harness SaaS account to complete this tutorial. It is free to sign up if you don’t have one already. After signing up, you will get access to the free tiers of many Harness modules including the Harness CD & GitOps module used in this tutorial. Specifically for Harness CD & GitOps module you will land on the “Get Started” page below.
When you click on the above blue button, you will see the various deployment options available.
Select Helm Chart deployment using Harness Kubernetes Helm
As described in the Native Helm vs Kubernetes Helm comparison doc, Harness supports 2 different approaches for deploying Helm Charts. The Native Helm approach is for users who want Harness to simply delegate the deployment to the helm cli running on the Harness Delegate. In this approach, only Rolling deployments are supported and features such as versioning and rollback are limited to those of helm’s native features. On the other hand, the Kubernetes Helm approach allows a user to leverage Harness to its maximum potential by enabling advanced rollout strategies such as canary and blue/green as well as Harness features such as versioning and rollback. The only downside is that you may have to edit your Helm Chart to confirm to the Harness Kubernetes Helm requirements highlighted here.
Since we want to do a canary deployment of a Helm Chart, we will pick the Kubernetes Helm option as shown below.
Install the Harness Delegate on your Kubernetes Deployment Target
You will need access to a Kubernetes cluster that will be the deployment target for the Helm Chart. In the CD Pipeline approach, you will create a Pipeline that will automate the deployment on your behalf and push the new application version into your target Kubernetes cluster.
You need to install a Harness delegate on your Kubernetes cluster as a prerequisite for the CD Pipeline. This delegate will then receive various tasks (such as secret decryption, connecting to private systems and more) from your CD pipeline and automatically run them on your behalf. The end result of the delegate is that you neither have to open any outbound ports from your cluster to Harness SaaS nor you have to provide Harness SaaS with any special permissions to do deployments on your behalf. The delegate takes care of both the authentication and authorization aspect between Harness SaaS and your cluster.
Note that the delegate itself can be deployed as a Kubernetes service (with its own Helm Chart or Manifest) or a Docker container that has network connectivity and permissions to deploy into your Kubernetes cluster. The in-cluster Kubernetes delegate option is the simplest option so let’s pick that as shown below. Make sure to note the delegate name you give here since that will be used in the next step.
Download Harness CLI and set up GitHub access
We are now ready to set up some prerequisites for creating the Harness resources. First is to download the Harness CLI. Thereafter fork the harnesscd-example-apps repo into your own GitHub account so that you can make modifications as necessary on the path to bringing your own app after you complete this tutorial. You will also create a new Harness API key and GitHub Personal Access Token (PAT). The API key will be used by the CLI to authenticate/authorize with your Harness account while the PAT will be used by Harness to access the sample code for the Helm Chart.
Create the required Harness entities/resources
At this step, all you have to do is simply copy and run the commands on your local machine. The Harness CLI will create a secret, 2 connectors, a service, an environment and an infrastructure on your behalf in your Harness account.
Create the canary deployment pipeline
We want to deploy our guestbook Helm Chart using a canary rollout strategy so that’s what we will pick below. And then we will copy and run the command on our local machine.
Verify the setup
Now we will verify if the pipeline creation was successful.
If there was any issue that led to the pipeline not being created then you will see the following.
If the pipeline creation was indeed successful, then you will see the following. Click Next to move forward.
Run the pipeline
Click on the “View and run your pipeline” button to run the pipeline.
You will see Harness CD & GitOps module in action where the guestbook helm chart is now deployed onto your Kubernetes cluster using a canary rollout strategy.
The Road to GA
Today’s launch is an important first step towards helping new Harness users understand the power of Harness CD & GitOps. In the coming weeks, we will be adding GitOps deployments into the UI so that the same learning journey can be realized even in the GitOps context. Additionally, we will be bringing in advanced Harness pipeline features like triggers, variables, templates, Continuous Verification and Harness Terraform Provider as follow-up to the first deployment. Our end goal is to help new Harness users grow into advanced Harness users in the shortest time possible so that they are able to bring the joy of continuous delivery (think hourly or daily deployments) to their own apps without the need for any manual intervention and with all necessary quality, security and governance gates fully configured into the pipeline.