Basics of Infrastructure as Code

Even though this book is mostly related to administrative tasks in Azure, some other topics are worth knowing. One of those is Infrastructure as Code – often abbreviated as IaC. You might be wondering why this topic is so important. Is the Azure administrator somebody who deploys infrastructure? Well, while an administrator may be loosely related to infrastructure deployment and configuration, in Azure, you cannot just ignore various ways for provisioning. What’s more, in an advanced Azure environment containing multiple resources, policies, and rules, it’s much easier to leverage infrastructure automation and management using an IaC approach.

In this chapter, we’ll focus on the basics of IaC, which will help you learn topics that will be covered in the next few chapters:

• What is IaC?
• ARM templates
• Migrating to Azure Bicep
• Using Azure Container Registry (ACR) as a repository of modules

Let’...

Technical requirements

To get the most from this chapter, you’ll need the following components:

• The Azure CLI (https://learn.microsoft.com/en-us/cli/azure/install-azure-cli)
• Any kind of IDE that allows you to work with text files

The Code in Action video for this book can be viewed at: https://packt.link/GTX9F

What is IaC?

In the previous chapter, we talked about using the Azure CLI and Azure Powershell for managing and deploying Azure resources. We also mentioned that you can use the Azure portal for manual provisioning and configuration. Unfortunately, those methods are not always solutions that allow automation.

Imagine the following scenario – you need to deploy a cluster of virtual machines (VMs) that will be used by some teams for their projects. You could do everything step by step using the Azure portal (the easiest option for beginners as it’ll show you all the necessary resources), use the command line to deploy components one by one, or even prepare a simple shell script that contains all the commands:

az vm create \
    --resource-group <resource-group-name> \
    --name <vm-name> \
    --image Win2022AzureEditionCore \
    --public-ip-sku Standard \
   ...

Exploring ARM templates

ARM templates are the oldest IaC solution for Azure and the most popular (we’re still talking about native solutions). They are based on JSON documents, which can be sent to ARM as deployments. Once a deployment is received by ARM, it parses the document and orchestrates the required changes to our Azure infrastructure.

Template schema

The high-level structure of each template looks like this:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "",
  "apiProfile": "",
  "parameters": {  },
  "variables": {  },
  "functions": [  ],
  "resources": [  ],
  "outputs": {  }
}

As you can see, it contains a couple of blocks that can be used for defining...

Migrating to Azure Bicep

Even though ARM templates have become very popular among people and companies working with Microsoft Azure, they’re hardly an ideal solution. As templates are simply JSON documents, they tend to become too verbose and difficult to maintain over time. It’s also difficult to develop a good ecosystem around such a tool because of the characteristics of JSON being a data format, not a real domain-specific language (DSL).

This is why Microsoft decided to take a step forward and proposed a new tool called Bicep. It is 100% compatible with ARM templates but provides a much smoother DevEx experience, better tooling, and IDE support with clean and easy-to-learn syntax. In this section, we’ll try to learn the main Bicep concepts and compare them to the template we created using ARM templates.

Bicep language

Bicep is a DSL, which is somewhat like the Hashicorp Configuration Language (HCL) language used by Terraform (which is another IaC tool...

Using ACR as a repository of modules

One of the important topics when talking about IaC in a company is building a central registry of modules that can be reused by other teams. Such a registry satisfies a couple of requirements:

• An authorization mechanism
• Integration with the chosen IaC tool
• Easy to use and manage

There are lots of different tools on the market that can act as such solutions, but in this chapter, we’ll focus on using one of the Azure services for that.

What is ACR?

ACR is a managed service in Azure that was originally meant to be a private container repository. You could prepare a container image (for example, Docker) and push it to your instance of ACR. Then, you could set up access policies and allow other users or applications to pull images from your registry.

Throughout ACR’s development, it has gained additional features and functionalities. You can use it to run jobs, store Helm charts, or act as a registry for...

Summary

In this chapter, you learned the basics of IaC. We talked about the use of ARM templates and Azure Bicep, their use cases, and the differences between them. You also had a chance to practice not only deployments but also using remote modules. The last topic is especially important from the point of Azure administration since, in many scenarios, you may need to set up and manage a central repository of modules. Such modules are then used by development teams, so it’s important to set up proper access policies (using RBAC) and think about the proper architecture of such a repository (including networking setup).

In the next chapter, we’ll be starting Part 2 of this book and taking a deep dive into Azure Virtual Networks. This topic will be extremely important to you as networks are part of most Azure solutions and act as one of the core infrastructure components that are used to secure and segment services.