ARM Templates

Infrastructure as code moved beyond PowerShell scripting with the introduction of Microsoft Azure Resource Manager (ARM) templates. ARM is an Azure management layer that enables resources in Azure to be created, updated, and deleted. Infrastructure as code resources in a template support software-defined networks, load balancers, virtual machines, and container runtimes like Kubernetes.

An often overlooked security feature is Azure role-based access control (RBAC), which is a direct feature of Azure resource management layer integration with Azure Active Directory (AAD) . ARM templates work to create the virtual foundation, and additional tools are used to configure the applications for consistency and compliance.

Tools like Ansible, Chef, and Puppet are excellent applications for management across environments; they often support the cloud operations team after the network, server, and security infrastructure are created. ARM templates use JSON files that define configurations in Microsoft Azure in a declarative manner. Using templates in a software-defined format of JSON files ensures that the deployment is consistent and predictable.

The application programming interface (API) layer of the Azure provider includes the methods, servers, services, applications, and users that interact with the resource. As API features are updated, the changes are reflected in version numbers from the resource provider. Each Azure region has resources supported for deployment that are used when deploying IaC.

An single example of a reusable library template would be the design of an ARM template. The ARM template should include the number of resources required such as a VM. You can create another ARM template that expands features, as an example, support for high availability. Azure Resource Manager supports the Azure API to create, update, and delete cloud resources. ARM templates should include version control. The version of resources then become a known resource supported by the Help Desk. The versioning numbers also support DevOps that includes continuous integration and continuous deployment (CI/CD).

You are not expected to become an ARM expert in this chapter; however, the level of detail is needed to help make informed decisions about investing in the creation of Azure ARM templates. Figure 11-2 provides a view of Azure QuickStart Templates. They are the same as GitHub ARM templates but, in an easy to search format.

Microsoft Visual Studio Code installation was covered in Chapter 8 when you were introduced to the tools and training necessary for an Azure cloud engineer. If needed, return to Chapter 8 to follow the installation instructions.

Installing Azure Resource Manager (ARM) Visual Studio Code Extension

1. 1.

   From your IaC laptop, open Visual Studio Code.

    
2. 2.

   Select the Extensions option.

    

1. 3.

   Search for the Azure ARM extension. Note the one created by Microsoft, and not another developer or corporation. Select the Install option.

    
2. 4.

   Verify that the Terraform extension is installed by using the search bar. Type @installed.

    
3. 5.

   The extension should appear in the list of installed extensions.

    

As Microsoft upgrades extensions and providers, the version numbers continue to increase.

With the installation of the extensions, you have a deeper understanding of the engineering effort between HashiCorp and Microsoft Azure.

HashiCorp Terraform on Azure

HashiCorp Terraform is an excellent cloud-agnostic tool for creating, editing, and versioning infrastructure used by global 2000 companies, as well as mid-size and smaller companies, to deliver CI/CD for IaC. The providers are engineered in a co-engineering agreement with Microsoft Azure teams to ensure a first-class support workflow using TF to deploy IaC libraries.

TF uses configuration files to describe the component needed to run an application, groups of servers, or an entire datacenter. Terraform generates an execution plan that describes the desired state and then executes to create the infrastructure through providers. This configuration syntax is an English-readable language to create blueprints of your datacenter for versioning from development, test, and production environments. Terraform has a core function to graph all resources with dependencies to support changes, additions, and reconfigurations in the correct dependency order.

Terraform leverages a provider, which is code written to support authentication and authorization, is responsible for interactions through a cloud API. This chapter focuses on the Microsoft Azure cloud provider, which has been a collaboration effort, please review Figure 11-3; however, all major clouds, including AWS, GCP, OpenStack, and Alibaba cloud. Terraform providers are not only cloud companies but other platforms as well. To gain a better understanding of the library of providers they include, Azure Stack, VMware, Chef, Cisco, Kubernetes, including directory services like Okta, Azure Active Directory, and databases platforms like MongoDB, MySQL, and network providers like Akamai, Cisco, Cloudflare, Palo Alto and more. Terraform allows the use of community versions of providers and validated providers. HashiCorp validated provider undergoes reviews and is often co-engineered between the two company engineering team.

You want to use HashiCorp Terraform and support the business using the IaC libraries through a standard framework and the Visual Studio Code integrated development environment (IDE). In Chapter 8, you learned the prerequisites and installation procedures for macOS, Linux, and Windows operating systems (OS).

Your IaC laptop must be configured properly to complete the exercises in this chapter if you deploy using HashiCorp Terraform or ARM. We realize your work may focus more on traditional operations, which requires more scripting with PowerShell or Azure CLI. Anyone who would like to become a subject matter expert (SME) will find that adopting developer tools and workflows are essential.

The HashiCorp Terraform community’s open source (OSS) edition is a free download (as a single executable) to install on your local machine, as described in Chapter 8. (Note that this is the same version that is currently configured as the default in the Azure Cloud Shell.)

You can learn HashiCorp Terraform using the integrated command-line terminal from inside the Azure portal and watch the commands execute and validate by typing terraform in the command shell, as shown in Figure 11-4. The Azure cloud shell has the latest version of the Azure, and HashiCorp Terraform providers installed. The Terraform providers have been a joint engineering effort between Microsoft and HashiCorp, please reference Figure 11-5.

To create an IaC laptop for this exercise, download and install Terraform locally. You should follow best practices and update the AzureRM provider to gain the latest functionality.

Installing Hashicorp Terraform Visual Studio Code Extension

1. 1.

   From your IaC laptop, open Visual Studio Code.

    
2. 2.

   Choose the Extensions option.

    

1. 3.

   Use the Azure Terraform extension. Note the one created by Microsoft and not another developer or corporation. Select the Install option.

    
2. 4.

   Verify that the Terraform extension is installed by using the search bar. Type @installed.

    
3. 5.

   The extension should appear in the list of installed extensions.

    

As a note, as Microsoft and HashiCorp upgrade extensions and providers, the version numbers continue to increase.

Once the Terraform template is created, it is deployed from the Visual Studio terminal. Working with HashiCorp Terraform from the view of a DevOps engineer, you gain insight into the code structure now that the extensions are installed in Visual Studio Code (VS Code). Like ARM templates, Terraform uses a configuration file, and it is in one of two formats: HashiCorp Configuration Language (HCL) or JSON.

The HCL format uses less bracketing and is an easy-to-read file structure (easy for humans to read) but a machine-formal file structure. HashiCorp Terraform supports JSON as an alternative configuration file; however, with Terraform version 0.12 and later, the JSON files have a 1:1 mapping to HCL. The HCL configuration language format can be reviewed at www.terraform.io/docs/configuration/syntax.html.

Terraform configuration is the term used for configuring Azure resources like resource groups, VNets, and virtual machines. Terraform is a declarative model used for building code modules and IaC libraries. This means that you write the code to create the desired state, and then Terraform communicates through Azure provide to create and configure Azure resources in your subscription.

Configurations for IaC use file synchronization directories and can be divided into dev, test, uat, or prod, depending on the current testing version of the library module. Plugins and other files used by Terraform are saved in a hidden file folder titled .terraform. Other files that contain configuration files for Azure are identified as the working or home directory.

Terraform persists the multiple sessions of state for the configuration files as they change from the previous state to the current state of Azure resources. As Azure resources are created in a state file, terraform.tfstate is written to manage all the resources. This is how Terraform reapplies the desired configuration after services start to drift out of compliance. There are only a handful of commands needed to deploy infrastructure as code to Microsoft Azure.

Figure 11-6 shows the VS Code to interact with Terraform. It then invokes the Azure cloud shell to continue with the Terraform action.

Once the Terraform command is selected, the next action from VS Code is to open the Azure command shell to invoke the Terraform command in your Azure subsection, as shown in Figure 11-7.

You added the Terraform extensions to Visual Studio Code. You can optionally install NodeJS and GraphViz (not shown for exercises). These basic steps need to be added to a best practice installation guide to run HashiCorp Terraform on Microsoft Azure.

Azure Blueprints

Azure Blueprints enable engineers and developers to build solutions using proven, hardened, templated, architectures that comply with organizational, industry, regulatory, and government requirements and policy. Blueprints enable rapid deployment to a secure and certifiable state of a cloud-hosted service in your organization, regardless of who the consumers of that service are. Blueprints allow architects to define roles, policies, templates, and resource groups. Blueprints enable bringing these components to a common architect to build, test, and deploy, commonly known as CI/CD, which means continuous integration and continuous delivery. Blueprints are what they are called—blueprints from which Azure services can be built.

Azure Blueprints are based on Azure ARM templates. Azure templates are declarative files for creating Azure resources in a reliable, repeatable, and auditable manner. Azure ARM templates let you deploy IaC. They are text files in which you define which Azure resources you want to deploy and how they are configured. ARM templates are test files in the JSON format. These JSON files can be edited in any text editor, and hence, can be versioned. The declarative approaches to infrastructure as code, policy as code, configuration as code, and role-based access as code provide a simple authoring experience that is integrated with Azure policy remediations, GitHub tasks, and provisioning with a variety of third-party solutions such as Terraform, Ansible, SNOW, and so forth. To learn more about defining resources in Azure ARM templates, please refer to https://docs.microsoft.com/en-us/azure/templates/.

The use of the native ARM templates allows Azure administrators to deploy resources as soon as they are available in the Azure cloud. There are no delays in compatibility and capability when ARM templates are the deployment plane. These deployments can be tracked easily in the Azure portal, providing visibility into the success or failure of the deployment. ARM templates perform checks before deployment to validate that they will succeed. These checks are known as what-if checks, which allow administrators to simulate what a change will do when deployed. It is a valuable featuresince there is no way to test in an existing environment, This feature validates preflight.

Multiple ARM template deployments can run concurrently, which is unavailable when using middleware to run IaC deployments. ARM templates can deploy Azure Blueprints across the Azure infrastructure for your organization.

ARM templates can be centrally stored and shared across the Azure ARM control plane in Azure TemplateSpecs, which is very similar to the Azure Shared Image Gallery discussed in Chapter 10. This allows the sharing of Azure templates, customized for your specific organization across Azure regions, subscriptions, and tenants. Azure TemplateSpecs can be deployed with the Azure portal, PowerShell, or CLI, or as nested deployments. Azure template artifacts and template linking will be available soon.

If you would like a tutorial on how to deploy an ARM template, please refer to https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/template-tutorial-create-first-template?tabs=azure-powershell. By leveraging Azure ARM templates and Azure Blueprints, you can deploy cloud-hosted services in your organization to satisfy all of your security, regulatory, and organization requirements.