Introducing Harness Custom Deployments

Updated

Harness recently launched a brand new feature called Custom Deployments. Custom Deployments, as the name suggests, is a way for users to perform any kind of deployment that might not be natively supported and provided by Harness out of the box. These technologies include traditional technologies like Weblogic, WebSphere, Google Cloud Functions, etc. Like other natively supported deployment types in Harness, Custom Deployments allow instances (or workloads) to be tracked on the services dashboard and kept updated as the actual underlying infrastructure might change. These instances that are deployed are also candidates to benefit from our Continuous Verification Integrations. Additionally, users can capture the deployed instance and leverage it in the CV tool of their choice.

Let’s See How This Can Be Achieved

Defining the Custom Deployment Type

Deployment types should be like a template that can be used across an account. Hence, we decided to leverage the Account Level Template Library for defining these deployment types. Like other template types in the Template Library, these are versioned. A new version is generated if any of the following are changed:

Infrastructure Variables
Fetch Instances Command Script
Host Object Array Path
Host Attributes

Creating a Custom Deployment Template in the Harness UI:

Explanation of Fields

Display NameName for the Custom Deployment TypeInfrastructure VariablesVariables that help identify the infrastructure. Examples:. Project, Cluster Name, Namespace, secret token, password, etc. These are like a template, and values can be provided later. Defaults can be specified here. Fetch Instances Command ScriptScript expected to query infrastructure to fetch live instances. These instances can be consumed by CV for verification and by the services dashboard.Host Object Array PathFull path to the JSON array containing instance information. his value should be "items" in the below example. If this is a nested field, we can use "." as a delimiter to specify the full path. Example: "foo.bar.items."Host AttributesKey in each JSON object which can be used to store instance attributes. The hostname is a mandatory attribute since it is the basis for the identification of instances across the platform. Example: The hostname should be set to listenAddress and we can set another property like Staging Mode. The field name can be set to a more human-readable string like staging_mode and JSON path should be set to Mode.staging.

Host Object Array Path configuration sample:

{
"items": [
{
"Mode": {
"staging": "nostage"
},
"listenAddress": ""
},
{
"Mode": {
"staging": "external_stage"
},
"listenAddress": "172.17.0.3"
},
{
"Mode": {
"staging": "stage"
},
"listenAddress": {
"staging": "172.17.0.5"
}
}
]
}

Now that we have created the deployment type, it is ready to be used across the applications for deployments.

Defining A Service

In Harness, we consider "what you are deploying?" to be known as the service. Similar to how someone would configure any other service in Harness, they can create a service for their custom deployments. Just choose the name of your new deployment type from the Deployment Type dropdown and you are ready to go. You can add any kind of artifact and configure service configuration variables.

Defining Infrastructure

Creating an infrastructure definition in Harness with a Custom Deployment Type:

Explanation of Fields

Display NameName for the Custom Deployment TypeCloud Provider TypeSet this to Custom Since there is no dedicated cloud provider in this case. Deployment typeChoose one of the custom deployment types that exist in the account.VersionDeployment Type is a template in the Template Library. It is versioned. The Infrastructure definition can refer to a static version or the latest version to pick up the latest changes. Variables from that version will show up here.VariablesSet Values to Infrastructure Variables to define the concrete infrastructure. Values can use any built-in Harness expression. Example: Service variables, secrets, config files, etc.

Setting up a Workflow

Both Multi-Phase (Canary) and Single Phase (Basic) Workflows can be created. There is a step named Fetch Instances which is added to the workflow by default in the Deploy phase step. Let us discuss this step in detail since this is the most crucial part of the entire Custom Deployment Flow.

Sample Custom Deployment Workflow with the base step setup:

This step will run the Fetch Instance Command Script corresponding to the version configured in the Infrastructure Definition along with substituting the values as defined. This will run on the Delegate and the response will be sent to the Harness Manager, where the response will be parsed using the Host Object Array Path and Host Attributes defined in the custom deployment template. Instance Objects would be created and will be available for consumption in subsequent steps via expressions ${instance.hostName}. In the subsequent sections, steps like:

Shell Script
Service Commands
Log Analysis (ELK, Google Operations, etc.)
Metric Analysis (AppDynamics, Datadog, NewRelic, etc.)

can be added to perform required actions on the deployed instance. Oftentimes, users want to verify their deployed instance is successfully receiving traffic, or running load tests to make sure the application can handle significant traffic.

Note: These Workflows are customizable. Phase steps, like Deploy, Verify, etc., can be added, deleted, and reordered as per choice.

Service Dashboard

The Service Dashboard allows our users to view their deployed instances and track hat has been deployed,when it was deployed, and where it has been deployed. Harness stores the Fetch Instance Command Script to be able to run it in the background so that the service dashboard is up to date. If, for example, the script makes API calls to fetch the current state of the infrastructure and dumps it in the required JSON format, the service dashboard will reflect any updates to the deployed instances/workloads.

If the script needs to be updated, the workflow can be re-run to update the background script.

The Wrap Up

Our Harness team has already began getting creative with our Custom Deployment feature and has come up with some pretty neat use cases for deployment. Some of our users are already using this feature for their legacy workloads, like Websphere and Weblogic. Check out the Harness Community, where our team shares these implementations with our users. Below are some of the recent examples:

Google Functions
https://community.harness.io/t/google-cloud-functions-with-harness-custom-deployment/598

Google Cloud Run
https://community.harness.io/t/google-cloud-run-workloads-with-custom-deployments-in-harness/597

AWS Elastic Beanstalk
https://community.harness.io/t/aws-elastic-beanstalk-with-harness-custom-deployment/619

We can't wait to see what you all come up with while using Custom Deployments. Feel free to share with the community for feedback. It’s exciting to see the cool ideas our users come up with!