Custom Deployment Templates for Harness and AWS CodeDeploy: A Technical Guide to Setup and Configuration

Custom Deployment Templates are an essential feature within the Harness Continuous Delivery platform, enabling users to define tailored deployment workflows for environments that fall outside of the supported platforms like Kubernetes and AWS. These templates offer a high degree of flexibility, allowing users to script interactions with target instances, manage artifact deployment, and integrate with cloud services such as AWS CodeDeploy. This guide provides a structured overview of how to create, configure, and implement Deployment Templates, with a specific focus on AWS integration and prerequisites such as Harness Delegate and infrastructure setup.

This article draws from technical documentation provided by the Harness and Timefold platforms, emphasizing installation, configuration, and deployment strategies for users aiming to build scalable and reliable deployment pipelines. All information is based on the source materials provided.

Overview of Harness Deployment Templates

Harness Deployment Templates are used to define custom deployment strategies, particularly for environments not natively supported by the platform. These templates are composed of two primary sections: Infrastructure and Execution.

Infrastructure includes settings for fetching a JSON array of target instances, mapping attributes such as instance names, and defining variables for dynamic substitution during deployment.
Execution encompasses the steps that are executed as part of the deployment process. These steps are typically created as separate Step Templates, allowing for modular and reusable workflows.

Deployment Templates allow users to work with a wide range of artifact providers, including Nexus3, Artifactory, Jenkins, Amazon S3, Docker Registry, AWS ECR, and custom repositories. However, it's important to note that these templates lack features such as steady-state checks and release tracking that are available in native Harness deployment types.

Creating and Configuring a Deployment Template

To create a Deployment Template in Harness, follow these key steps:

Create the Template: Start by creating a new Deployment Template in the Harness UI. Assign a name and version label (e.g., v1), and optionally upload a logo to represent the template visually.
Define Variables and Fetch Script: In the Infrastructure section, define variables and write the Fetch Instances Script, which is responsible for retrieving a JSON array of target instances from a server or service. This script can be stored in the Harness File Store to be reused across multiple templates.
Map Instance Attributes: Specify the Instance Object Array Path, which is the JSON path to the list of instances. Additionally, define the Instance Attributes such as instance name and IP address. Mapping the instancename field to a JSON path is mandatory.
Add Execution Steps: In the Execution section, add the steps required for deployment. These can include steps such as running shell scripts, deploying artifacts, or invoking APIs. These steps are automatically converted into Step Templates when saved.
Save the Template: Once the template is configured, click Save to finalize the settings.

The template can then be used in a Harness Pipeline by selecting it as the deployment type when creating a new stage.

Example: AWS ElasticBeanstalk Deployment Template

An example of a Deployment Template is one that integrates with AWS ElasticBeanstalk. This template includes a Create Version Step that is responsible for creating a new application version in ElasticBeanstalk. The script assumes an IAM role, sets environment variables, and checks if the version already exists before creating a new one.

Key elements of this script include:

AWS CLI setup: The script uses AWS CLI commands to interact with ElasticBeanstalk. It assumes an IAM role if specified and sets AWS credentials accordingly.
Version existence check: Before creating a new version, the script checks if a version with the same label already exists. If it does, the step is skipped.

This script is an inline Bash script that runs on a Harness Delegate configured to support AWS CLI commands.

AWS CodeDeploy Deployment Template Sample

AWS CodeDeploy is another supported integration within Harness, and a sample Deployment Template is provided in the documentation. This template enables users to deploy applications using AWS CodeDeploy by specifying key parameters such as:

AWS Connector: A pre-configured AWS connector in Harness with the necessary permissions to perform CodeDeploy operations.
Region: The AWS region where the deployment will occur.
Application Name: The name of the CodeDeploy application.
Deployment Group: The deployment group used by CodeDeploy to manage the deployment lifecycle.
Deployment Configuration: A configuration that defines deployment rules, such as whether to deploy one instance at a time.

The deployment process is initiated by creating a Deployment Template that includes steps for fetching instances and deploying the application. The AWS CLI must be installed on the Harness Delegate, typically via the INIT_SCRIPT environment variable.

Harness Delegate Setup for Custom Deployments

A crucial component of custom deployments is the Harness Delegate. The Delegate acts as a lightweight agent that executes deployment scripts and interacts with external systems. For AWS-based deployments, the Delegate must be installed in a Kubernetes cluster and configured to communicate with AWS services and target instances.

Key considerations for Delegate setup include:

Network Configuration: The Delegate should be installed in an environment where it can connect to the artifact repository and target instances. In most cases, this means placing the Delegate in the same subnet as the target instances.
Script Requirements: If the deployment scripts require utilities or software not included in the Delegate by default, these can be installed manually or via the INIT_SCRIPT environment variable.
Artifact Support: The Delegate supports a wide range of artifact providers, including Docker, ZIP, and Jenkins artifacts. This allows for flexible deployment of various application types.

For more information on installing and configuring a Harness Delegate, refer to the official Harness documentation.

Pipeline Configuration Using Deployment Templates

Once a Deployment Template is created, it can be used in a Harness Pipeline to define a deployment stage. The process involves:

Creating a Pipeline: In the Pipelines section of the Harness UI, create a new pipeline and select the Deployment Template as the deployment type.
Adding a Service: Define a Harness Service using the Deployment Template and specify the artifact to be deployed. For example, a Docker image can be added as the primary artifact.
Setting Up an Environment: Create an Infrastructure Definition that uses the Deployment Template and maps it to the target instances. This includes specifying the cloud provider and any required configuration parameters.
Configuring Execution Steps: In the Execution section of the stage, review the automatically added Fetch Instances step and move it to the appropriate location in the workflow. Add a deployment step to deploy the artifact to the target instances.

By following these steps, users can create a fully automated deployment pipeline that leverages custom scripts and external services.

Limitations of Deployment Templates

While Deployment Templates offer a high degree of flexibility, they come with certain limitations compared to native deployment types:

No Steady-State Checks: Unlike deployments for supported platforms such as Kubernetes, Deployment Templates do not include built-in steady-state checks to monitor the health of the deployed services.
No Release Tracking: Harness does not track releases for deployments created using Deployment Templates.
Manual Scripting Required: Users must manually write and maintain the scripts used for fetching instances and executing deployment steps.

Despite these limitations, Deployment Templates remain a powerful tool for deploying to custom or unsupported environments.

Best Practices for Using Deployment Templates

To ensure a successful deployment using Harness Deployment Templates, consider the following best practices:

Test Scripts Locally: Before integrating scripts into a Deployment Template, test them locally to ensure they work as expected.
Use the Harness File Store: Store commonly used scripts in the Harness File Store to promote reuse and maintain consistency across multiple templates.
Leverage Step Templates: Break down complex deployment steps into reusable Step Templates to improve maintainability and reduce redundancy.
Monitor and Log: Implement logging within scripts to capture detailed information about the deployment process. This helps in troubleshooting and auditing.

By following these best practices, users can streamline their deployment workflows and reduce the risk of errors during execution.

Conclusion

Harness Deployment Templates provide a flexible and customizable approach to deploying applications in environments that are not natively supported by the platform. By leveraging these templates, users can define custom workflows, integrate with external services such as AWS CodeDeploy, and manage deployments across a wide range of artifact providers. The setup process involves creating and configuring the template, setting up the Harness Delegate, and integrating it into a deployment pipeline.

While Deployment Templates require a higher level of manual configuration compared to native deployment types, they offer the flexibility needed to support complex and unique deployment scenarios. By following best practices and understanding the limitations, users can effectively utilize Deployment Templates to build scalable and reliable deployment pipelines.