Chapter 4: Infrastructure Deployment

In Chapter 3, Infrastructure Design, we had a 360-degree view of the Azure and AKS infrastructure, but we have not yet seen how to get infrastructure components provisioned in Azure. This chapter focuses on one of the major enablers of the cloud, namely, Infrastructure as Code (IaC). More specifically, we will cover the following topics:

• Introducing Continuous Integration and Continuous Deployment (CI/CD)
• The Azure deployment map
• Getting started with the Azure CLI, PowerShell, and Azure Cloud Shell
• Diving into ARM templates
• Getting started with Azure Bicep
• Getting started with Terraform
• Zooming in on a reference architecture with Azure DevOps

By the end of this chapter, we expect you to be acquainted with IaC concepts and technologies and you should be able to make the right choices for your own organization and your customers.

Technical requirements

If you want to practice the explanations provided in this chapter, you will need the following:

• An Azure subscription: To create your free Azure account, follow the steps explained at https://azure.microsoft.com/en-us/free/.
• The Azure CLI, PowerShell, and/or Azure Cloud Shell: If you want to practice them all, you need access to all three. Otherwise, you can just pick your preferred choice. Azure Cloud Shell is the easiest option because you only need a browser to use it.
• An Azure DevOps organization: To create an organization, follow the steps explained at https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/create-organization.
• Microsoft Visio: You will need this to open the diagrams, or use the Visio viewer available at https://www.microsoft.com/en-us/download/details.aspx?id=51188.

All the code samples and diagrams are available at https://github.com/PacktPublishing/The-Azure-Cloud-Native-Architecture-Mapbook/tree...

Introducing Continuous Integration and Continuous Deployment (CI/CD)

Before diving into CI/CD, let's first step back and reflect on what DevOps means. In most large organizations, the IT department is still divided into siloes. The most common ones are the developers, on the one hand, and the infrastructure teams on the other. You might as well have a separate security team and some middle ground bodies, overseen by a governance body and an enterprise architecture practice. The purpose of DevOps is to act as a bridge between the teams and to break the silo mentality. DevOps is part of a broader digital transformation program that may take years to achieve. The whole point behind digital transformation and DevOps is to gain extra agility and efficiency. However, that's easier said than done!

While the theory is promising, the reality often tends to prove otherwise: resistance of the different teams, misunderstandings on the part of management, a lack of proper skills, people...

The Azure deployment map

Unlike the other topics, the Azure deployment map is rather small. We will first elaborate on its different top-level groups, but this time we will be a little more hands-on with a few of our topics. We will compare the different options at our disposal, and then we will show you a real-world example of an advanced IaC implementation with Azure DevOps. We lightly touched on your deployment options in Chapter 2, Solution Architecture. Figure 4.3 shows a more elaborate view of the Azure deployment landscape:

Figure 4.3 – The Azure deployment map

Figure 4.3 has seven top-level groups:

• DSC (Desired State Control)
• PAAS AND FAAS, which largely encompasses both vendor-neutral and native technologies
• COMMAND LINE
• DEVOPS & PIPELINES
• CAAS
• VENDOR NEUTRAL refers to deployment tools and techniques that can be used with other platforms than Azure
• NATIVE refers to deployment tools and techniques that...

Getting started with the Azure CLI, PowerShell, and Azure Cloud Shell

In this section, we will give you a glimpse of the Azure CLI and PowerShell from within Azure Cloud Shell. Our goal is not to make you become a scripting rock star, but to just make you familiar with the two approaches. Of course, client tools may be used to provision resources, but they can also interact with Azure in general. Even if you provision everything through CI/CD pipelines, with ARM templates or Terraform, you will still need to retrieve information about the deployed resources. Therefore, we will first focus on getting Azure insights with the client tools in our next section.

Playing with the Azure CLI from within Azure Cloud Shell

As stated before, the Azure CLI should be your default choice when interacting with Azure. If you want to install the Azure CLI locally on your machine, follow the instructions given at https://docs.microsoft.com/en-us/cli/azure/install-azure-cli. For the sake of simplicity...

Understanding the one that rules them all

Before jumping into our declarative deployment options, it is important to first step back and understand what is the single endpoint that rules everything.

No matter which tool or language you choose, they will ultimately all talk to the same Azure API, namely, the Azure Resource Manager (ARM) endpoint. The commercial endpoint is https://management.azure.com/. Any call to this endpoint requires the caller to provide a valid access token, retrieved from Azure Active Directory. Remember, in our Understanding the ARM template deployment scopes section, we discussed the least privilege approach and the empowerment of the deployment tools. That is what this access token will be validated against, for any interaction with the ARM API.

Terraform, Azure Bicep, native ARM templates, and imperative client tools all talk to the ARM endpoint. This is important, because if a feature is not exposed through the ARM endpoint, none of the tools will...

Diving into ARM templates

ARM templates are Azure's native way of provisioning resources in Azure. Almost everything can be deployed through ARM templates, although they do not cover all the Azure services. In this section, we will dive into the ARM world and will provision some services, so as to have a more hands-on experience. Let's get started!

Getting started with ARM

In the real world, it is unlikely that you will ever build an ARM template from scratch. To get you started with ARM, here are a few important handy sources and tools:

• ARM Quickstart Templates is a repository of about 950 templates, and is available here: https://azure.microsoft.com/en-us/resources/templates/.
• The export wizard of the Azure portal. You can create an Azure resource with the portal and export the template afterward. While this method can be interesting in some situations, where the documentation is a little unclear, exported templates cannot be reused as-is to provision...

Getting started with Azure Bicep

At the time of writing, Azure Bicep is still in early development and not production ready yet, but this could change by the time you read this.

The main purpose of Azure Bicep is to do the following:

• Alleviate the complexity of the ARM template language to make it less verbose and to bring a more developer-friendly approach.
• Compiling Bicep files to produce a single ARM template. This prevents the use of a storage account or any other publicly available location for storing linked templates.

Unlike Terraform, Bicep remains Azure-specific. You can think of it as the next generation of the ARM language. To know more about Bicep and to stay tuned, you should subscribe to the Azure Bicep repo at https://github.com/Azure/bicep. Now we will redeploy exactly what we deployed previously, but we'll use raw ARM templates and evaluate the benefits of using Bicep. In order to perform this exercise, you must go through the following steps...

Getting started with Terraform

Terraform is HashiCorp's star IaC product. They define it as a tool that can be used to provision and manage any cloud, infrastructure, or service. Terraform's architecture is based on hundreds of providers, among which is the Azure provider. The value proposal of Terraform is to propose a common way to define IaC templates, no matter the target platform. The least we can say is that HashiCorp succeeded in making a very broad and good product. In addition to the official providers, there are also dozens of community-provided providers. Terraform's most important commands are the following:

• init: Used only when referencing a new provider or a new provider version
• plan: An optional step for comparing the known state with the new desired state
• apply: A command to apply the new desired state for the resources defined in the template

Templates are written in HCL (HashiCorp configuration language – https://www.terraform...

Zooming in on a reference architecture with Azure DevOps

So far, we have reviewed the fundamentals of Terraform, ARM templates, and Azure Bicep. It is now time to see how you can concretely set up a factory that's designed to provision resources and deploy applications in an industrial manner. Of course, we will not walk you through the complete setup, but we will describe the possible approaches.

Beware that it takes time to get a fully industrialized factory up and running, and it is a significant investment. So far, we have largely focused on the IaC bits, but of course the infrastructure components that we provision are used by applications that have their own life cycle. At the end of the day, you need to find a way to deploy both the application code and the infrastructure together, while still being able to test your own infrastructure work, independently of the applications that will consume your components. Therefore, we must distinguish the authoring and versioning...

Summary

In this chapter, we briefly explained what the benefits are of a CI/CD pipeline and of DevOps tooling in general. We also highlighted how challenging it can be to have a fully functioning factory.

We made it clear that there is only one ruler in Azure's IaC world: the ARM endpoint. All the imperative and declarative tools and languages ultimately talk to the ARM endpoint. We shed some light on Terraform, native ARM templates, and Azure Bicep, ARM's next-generation language. Beyond imperative tools and declarative languages, we explored how to set the different elements to music with Azure DevOps. Concepts explained for Azure DevOps also apply to other platforms. By now, you should have understood that a fully functioning factory leveraging IaC is a vital element for building and provisioning cloud solutions. You should have gained sufficient knowledge to get started with your own factory, or to accompany DevOps teams on their CI/CD journey.

IaC is a key part...