How Infra Teams can leverage Harness!

Harness Experts
1

Some customers want to leverage Harness to provision infrastructure for them. They only want to provision infrastructure and maintain the infrastructure separate from the Application development team. A common sample is that the infra team manages the Terraform and CloudFormation provisioned resources and configures the cloud provider for App teams to leverage. Any resource requirements for those Cloud Providers can be managed through the Infrastructure Provisioning Workflows.

Before You Begin

  • You must have working Terraform of CloudFormation
  • Configure an Infrastructure Provisioner
  • Create an Infra Provisioning Application

Review: Concepts to Review

Please review the Harness Documentation on provisioning infrastructure: Infrastructure Provisioners Overview - Harness.io Docs

For those interested in creating a Kubernetes Cluster via Terraform or CloudFormation please review this document: Provision Kubernetes Infrastructures - Harness.io Docs

Step 1: Setting Up the Workflow

  1. Create a Canary Workflow in your Infrastructure Application

  2. Canary Workflow is not associated with a service, so the workflow can be leveraged freely.

  3. Add the Terraform Provision Step to the Pre Deployment Phase

  4. Set the Provision step as the Terraform plan

1600Ă—548 42.6 KB

  1. Add an Approval Step for the Plan

  2. The idea is that the user will need to verify that the terraform plan checks out before applying the new resources

  3. Add the Terraform Apply Step in the Pre Deployment Phase and provision the infrastructure

  4. This will actually provision the defined infrastructure with the desired configuration passed into the terraform via tfvars, ${workflow.variables.var_name}, etc.

1548Ă—481 29.8 KB

  1. At the Post Deployment phase, configure a Terraform Destroy step

  2. Add a conditional variable to that step, if ${workflow.variables.destroy}==true please destroy the infrastructure

The reason why we have a destroy step is that some infrastructure engineers want to test out and view their infrastructure before actually doing the apply of their infrastructure.

1184Ă—520 34.8 KB
’

  1. In the Workflow, we will add a workflow variable called to destroy. For its value by default, we will say true so that by default it destroys the provisioned infrastructure. If we don’t want to destroy the infrastructure we can set the overriding variable to false.

1020Ă—524 39.7 KB

Note:

An alternative method to using the conditional technique is just adding an approval before they destroy step. This forces a developer to navigate into AWS or their desired cloud provider and view the resources created in the respective console. If something doesn’t look right, reject the approval, and Harness will rollback Terraform to the previous state. If the Approval is accepted then run the Terraform destroy.

This technique is designed for testing the Terraform configuration. The other method is more for continuous minor updates to an existing Terraform or CloudFormation configuration.

Alternative Terraform Setup

Opinionated Terraform Provisioning

Some development teams want to manage all their Terraform configuration in Github. Any changes to the terraform happen in Github and can be traced via the commit. On top of that, there is an added benefit of defined variables. User’s don’t have to pass in input based on a workflow variable. Everything will be picked up via their tfvars file or hardcoded values in the terraform.

By keeping the approval of changes at the GitHub level, development teams can manage their Terraform code and mitigate unapproved configurations before provisioning with Harness. This would reduce the number of approval steps required in the workflow. It makes the workflow execution more self-service and developers don’t have to rely on another team or another user to approve the workflow because the configuration was approved via PR in Github.

Step 2: Configuring Overrides

  1. In CloudFormation or Terraform the most common way to override configuration can be with Workflow Variables.

  2. These workflow variables can be passed as input

1. This technique can be very valuable when playing around with instance size, instance type, or number of instances an infrastructure engineer wants to provision
  1. Some users leverage that tfvars files as the input so they don’t need to pass in variables at runtime, they can just edit a tfvars file and have Harness pull the desired configuration from it.
1. This reduces the manual input into Harness, it also keeps everything in version control so the user can revert a change they didn’t like with the tfvars file.

Step 3: Running the Deployment and view Outputs

  1. Run the Canary Deployment and go through the Workflow approvals and logs. You should be able to view the plan, apply and destroy.

1600Ă—660 214 KB

Next Steps

Till next time my fellow canaries keep on building and deploying! :smile:

1 Like