Harness Infrastructure Provisioners define deployment infrastructure blueprints from known infrastructure as code technologies, such as Terraform and CloudFormation, and map their output settings to provision the infrastructure. Infrastructure Provisioners enable Harness Workflows to provision infrastructure on the fly when deploying Services. In this blog, we will learn about the Harness ARM provisioner. But before that, let’s understand the basic concept of Azure ARM.
Azure Resource Manager (ARM) is the native platform for infrastructure as code (IaC) in Azure. ARM templates are a form of infrastructure as code – a concept where you define the infrastructure that you need to deploy. You no longer have to click around the portal, creating virtual machines or writing scripts to deploy a storage account. Instead, the template defines the resources, and the ARM management layer creates the infrastructure.
Using ARM templates when managing your Azure environment has many benefits. For example, using declarative syntax removes the requirement of writing complicated deployment scripts to handle multiple deployment scenarios.
Furthermore, these templates provide repeatable results and are idempotent, meaning that you can write and deploy the same template many times to get the same result. In turn, can take the same template that you used for the development infrastructure and use it to deploy the production environment. Using the same template makes sure that the resources and settings are identical.
ARM also handles the order of operations for deployment. As a result, ARM deploys dependent resources in the correct order and, when possible, deploys in parallel for faster deployments. Moreover, you can extend the templates with deployment scripts written in PowerShell or Bash for a complete end-to-end environment setup.
Templates use declarative syntax. In this way, you can specify what to deploy without writing a series of commands that specify how to deploy it. In particular, templates specify the resources to be deployed and their properties.
The template is ready for deployment only after it is validated by the Resource Manager. This makes it unlikely that the deployment will fail midway.
The template includes the following parts:
The following is an ARM template for creating a storage account.
Parameters let you pass different values to the ARM template for use during deployment. Some common examples include the names of resources, or which Azure region to host them. Parameters enable your templates to be more dynamic and used across different environments.
ARM deployments can be done in the following modes:
To illustrate the difference between the incremental and complete modes, consider the following scenario:
The Resource Group contains:
The Template contains:
When deployed in Incremental mode, the Resource Group has:
When deployed in Complete mode, Resource C is deleted. The Resource Group has:
First, the user must define the ARM provisioner, which is essentially providing the ARM template definition.
Step 1: Define ARM Provisioner
This can be defined as:
Note: Harness also supports Azure Blueprint deployments. Users need to select the ARM resource type as ARM. We will have a separate blog for discussion on how Harness supports Azure Blueprint.
Step 2: Define ARM Workflow
During workflow execution, Harness will download the template and Parameter files. These files are downloaded in the Delegate working directory. Then, the Harness Delegate will send a request for deployment to Azure using these files.
We must create a workflow and select the above ARM Provisioner.
Once the workflow execution is over, all of the resources mentioned in the template will be provisioned in Azure.
The following steps are performed:
Deployment Flow for Inline Templates:
When you create an inline ARM provisioner, the template is saved in the Harness Mongo.
Deployment Flow for Remote Templates:
Multiple instances of the Delegate service would be running.
You might be wondering why the delegate didn’t send the request for deployment after Step 4 instead of sending the templates to the Manager, since the delegate already has the ARM templates. As it turns out, these templates may have Harness in-built variables (which we’ll cover in the second part of this blog series). A Delegate is stateless, meaning that it knows nothing about variables. It only knows how to execute the task. The Manager has all of the relevant details required to resolve these variables. Therefore, after downloading the templates, they are sent to the Manager so that it can resolve any Harness variables to which the templates are referring. Then, these rendered templates are sent to the Delegate for execution as a separate Task.
In this post, we learned the basics of ARM templates, and how we can deploy them using the Harness workflow engine. Furthermore, we learned the Harness deployment process and how communication happens between UI, Manager, and Delegate. In the next part of this series, we’ll learn about using Harness variables inside of the ARM template, and how Harness provides rollback support.
Stay tuned! And until then, perhaps you’d be interested in this piece on how Harness uses Harness CD?
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.