Dear all-wise and all-knowing Drone Community! Recently I wrote up a how:to guide to create your first Drone Plug-in, integrating into Harness CD.
Final Solution from Post: GitHub - ravilach/drone-harness-trigger: Sample Drone Plug-in to Trigger Harness CD Workflow
Cross-Post of: Your First CI/CD Plugin | Harness
The goal of this example is to have Harness CI / Drone build a Python-based plugin then push a GoLang Docker Image to Docker Hub. Once the push step is over, Harness CI / Drone will call Harness CD directly and deploy the artifact to an awaiting Kubernetes cluster. Supercharging your DevOps skills to an elite level going from idea to production.
Let’s Get Started – Background and Approach
There are a few moving pieces that we will be working through in the example. You need a Harness CI / Drone instance, a Docker Hub Account, a GitHub account, and of course a Kubernetes cluster which could even be Minikube.
Harness CI / Drone has a robust plugin architecture that allows for almost anyone to create and leverage plugins. Harness CI / Drone plugins are pre-defined tasks that are configured as steps in your pipeline. In this example, we are going to create a Harness CI / Drone plugin in Python that will call the Harness CD API to trigger a Harness Workflow.
If leveraging the example Harness CI / Drone GitHub project, you will have to edit the information to be your own Docker Registry for where the Docker Push goes. I will be referencing mine below.
If leveraging the example, we will assume that we know the name of the artifact that eventually we want to deploy. If you bring your own, can modify the Harness CD steps to match your own artifact.
Harness CD Prep
If this is your first time leveraging the Harness Platform, the quickest way to get started is to leverage a Kubernetes Delegate.
The first step of getting a Harness Delegate installed in your Kubernetes Cluster is pretty straight forward. Once signed up / signed up, can install a Harness Delegate.
Setup → Harness Delegates → Install Delegate. Then Select Kubernetes YAML and give a name such as “cicd”.
Once downloaded, can expand the TAR and install the Harness Kubernetes Delegate. Instructions to install will be in a README.txt inside the expanded folder.
To Install the Kubernetes Delegate, run kubectl apply -f harness-delegate.yaml .
After a few moments, your Harness Delegate will be ready. You can validate by going back to Setup → Harness Delegates and seeing your new Delegate on the list.
Next can wire up a Kubernetes cluster for Harness to deploy to by adding the Kubernetes cluster as a Cloud Provider.
Setup → Cloud Providers + Add Cloud Provider → Kubernetes Cluster.
Since the Harness Delegate is deployed on the cluster, we can easily inherit the details from the Delegate itself. Name the cluster something such as “CICD Kubernetes Cluster”, hit Test then Next, then Submit.
With the Kubernetes cluster wired into Harness, the next step is to start to define the Workflow that Harness will execute. Harness works on an abstraction model where you define the pieces needed to complete your Workflow. The first step of that is to create a Harness Application which is the home to all of the associated abstraction pieces.
Setup → Applications + Add Application. Can name the Harness Application “DevOps Dojo”.
Once the Harness Application has been created, can start to build out the abstraction model. A good starting point is the Harness Service.
Setup → DevOps Dojo → Services + Add Service. Can name the Harness Service “Amazing App”. The Deployment Type will be Kubernetes.
Inside the Amazing App Service, + Add Artifact Source from a Docker Registry.
Here you can wire together our example application/project or one that you have created. If you don’t have an existing artifact that you want to build, can return to this step later on during the Harness CI / Drone configuration. I have an application on public Docker Hub called “rlachhman/amazingapp”.
Once you hit Submit, the scaffolding will be there for the deployment and no need for additional configuration.
With the Service out of the way, we can wire a Harness Environment to deploy to.
Setup → DevOps Dojo → Environments + Add Environment with the name of “The Greatest Environment”.
Once you hit Submit, next can wire an Infrastructure Definition to define an environment to deploy to.
Next click + Add Infrastructure and add the Kubernetes cluster. The Cloud Provider Type and Deployment Type will be Kubernetes. Can give the name “The Greatest K8s Cluster”.
Once you hit Submit, can wire together a Harness Workflow to define the steps to deploy.
Setup → DevOps Dojo → Workflows + Add Workflow. The Workflow Type will be Rolling Deployment. Select the Environment, Service, and Infrastructure Definition that was created in the previous steps. Can give the name “Deploy Amazing App”.
Once you hit Submit, the Workflow Overview should look like the following.
Lastly, let’s create a Harness Trigger so that our Harness CI / Drone Plugin has an endpoint to execute on. The Harness Trigger will execute the Workflow that has just been created.
Setup → DevOps Dojo-> Triggers + Add Trigger with a name of “Web Deploy Trigger”.
Once you hit Next, the Condition will be on a Webhook Event which we will generate from the Harness CI / Drone Plugin that we will be creating.
Once you click Next, the Action will be to execute the Harness Workflow which was just created. In the payload of the webhook will define the version/tag.
Once you click Next can validate the Harness Trigger configuration.
When you click Submit, the trigger will be created and expose the Payload Information you need.
Can get the Payload information which we will build the Harness CI / Drone Plugin to by clicking on Manual Trigger.
Lastly, we can set up an API Key to authenticate a remote call to the Harness Trigger. To create an API Key, head to Security → Access Management → API Keys + Add API Key. Can name the API Key “Harness CI / Drone API Key”.
Once you hit Submit, you can view the masked key.
With the Harness CD steps out of the way, its time to look at what you could/will be building to deploy then looking at creating a plugin to trigger the deployment.
Creating an Application to Deploy
If you do not have a don’t have a running Harness CI / Drone instance don’t worry, not difficult to accomplish. We have a detailed blog and video to get you started. We will split the GitHub projects into two. One will be for the creation of the Harnes CI /Drone to Harness CD Trigger Plugin and another will be a more typical project publishing an artifact and leveraging your newly created plugin.
If you do not have an existing application to deploy and want to seed one in your Docker Registry, can modify a few lines in the example repository. Fork the repository into your own GitHub and can make a few changes to the Drone.yaml. If you do that make sure to following the activating Harness CI / Drone steps for your specific repository and credentials.
To kick off an initial Harness CI / Drone Build and Push, simply modify the configuration / Drone.yaml. To explicitly build to a specific version, can add tags to Drone.yaml which works well with the example. In the example, let’s start by pushing build version 1.0.1. Make sure to update your repository information also.
Once you make a change to the Drone.yaml you are on your way to starting to automate the deployment.
When the publish step completes, a new version of an artifact will be on your Docker Registry.
With the ability to create an artifact and the Harness CD wirings in place, now it is time to create your first Harness CI / Drone Plugin.
Harness CI / Drone Plugin Creation
The example plugin will be a Dockerized Python application that will formulate a request to call the Harness CD API to deploy. If you are new to writing Python, a good development environment for Python is Pycharm.
There are several ways to call the Harness API, for example, you can use the GraphQL API but in my example, I am taking advantage of CURL like payload with JSON.
The main mechanism of passing items between your YAML configuration and the plugin itself can be described in the GoLang example in the documentation. In the “settings” section of the YAML configuration that references the plugin, getting environmental variables that follow “PLUGIN_FIELD” is the wiring between the two.
Looking at the completed example plugin project, the structure is almost identical to if you are writing a custom application and leveraging Harness CI / Drone to deploy. In the plugin Drone.yaml we have easily switched to a Python Build and publishing our newly minted artifact to a new location.
Making modifications or initially committing your Harness CI / Drone YAML will kick off a build once wired to the repository.
The plugin is ready to rock.
With the plugin all ready, you can now start to leverage the plugin in your other projects.
Configure Your First Plugin
After all the work you put into the plugin creation, time to enjoy the spoils of victory. For this Harness specific example, there are a few fields that have to be wired in through the plugin. You can decide what makes sense to expose in the YAML vs using the Harness CI / Drone secrets facilities. Items such as the build/tag ID are safe to include but most account specific items should be referenced as a secret.
A reminder of the Manual Trigger pane which contains most of the details.
Harness CD → Setup → DevOps Dojo → Triggers → Web Deploy Trigger then click on Manuel Trigger.
| Field | Where to Find |
|---|---|
| Account_ID | In Harness CD, your Harness Account ID, in the URL of your account, or the Manual Trigger view of your Harness Trigger. |
| API_Key | In Harness CD, under Security → Access Management → API Keys |
| Application_ID | In Harness CD, in the Manual Trigger view of your Harness Trigger. |
| Artifact_Version | Either defined by what you want to deploy. Usually in your Docker Registry or Harness CI / Drone configuration. |
| Harness_Webhook_ID | In Harness CD, in the Manual Trigger view of your Harness Trigger. |
| Harness_Service_Name | Your Service you are deploying to. In this example was “Amazing App”. |
| Harness_Artifact_Name | The artifact name given to your Service. In this example was “rlachhman_amazingapp” representing the repository and image. |
With the prudent details, you can start to build in the scaffolding on how the plugin will execute.
With the scaffoldings in place, you can now start to wire in the secrets into the repository that you wish to build and publish.
With the secrets wired in, all that is left is to include the scaffolding into an existing or sample Harness CI / Drone Pipeline.
Executing Your First Pipeline
Coming to the conclusion of this example. All we need to do now is append the scaffolding/plugin configuration at the end of a Harness CI / Drone Pipeline. Will be leveraging the same pipeline that produced version 1.0.1 of the Amazing App. Let’s let the newly minted plugin take care of deploying version 1.0.2.
Commit and you are off to the races!
Great job sticking through the example, can validate in the Harness CD Platform that your deployment was kicked off.
Best,
-Ravi