Chapter 6: Infrastructure as Code (IaC) with Terraform

Cloud computing is one of the primary factors of DevOps' enablement today. The initial apprehensions that there were about the cloud are a thing of the past. With an army of security and compliance experts manning cloud platforms 24x7, organizations are now trusting the public cloud like never before. Along with cloud computing, another buzzword is taking the industry by storm – Infrastructure as Code (IaC). This chapter will focus on IaC with Terraform, and by the end of this chapter, you will understand the concept and have enough hands-on experience with Terraform to get you started in your journey.

In this chapter, we're going to cover the following main topics:

• Introduction to IaC
• Setting up Terraform and Azure providers
• Understanding Terraform workflows and creating your first resource using Terraform
• Terraform state and backends
• Terraform workspaces
• Terraform outputs, state...

Technical requirements

For this chapter, you can use any machine to run Terraform. Terraform supports a large number of platforms, including Windows, Linux, macOS, and others.

You will need an active Azure subscription to follow the exercises. Currently, Azure is offering a free trial for 30 days with $200 worth of free credits; you can sign up at https://azure.microsoft.com/en-in/free.

You will also need to clone the following GitHub repository for some of the exercises:

https://github.com/PacktPublishing/Modern-DevOps-Practices

Run the following command to clone the repository into your home directory, and cd into the ch6 directory to access the required resources:

$ git clone https://github.com/PacktPublishing/Modern-DevOps-\
Practices.git modern-devops
$ cd modern-devops/ch6

So, let's get started!

Introduction to IaC

IaC is the concept of using code to define infrastructure. While most people can visualize infrastructure as tangible, virtual infrastructure is already commonplace and has existed for around two decades. Cloud providers provide a web-based console through which you can manage your infrastructure intuitively. But the process is not repeatable or recorded.

If you spin up a set of infrastructure components using the console in one environment and want to replicate it in another, it is a duplication of effort. To solve this problem, cloud platforms provide APIs to manipulate resources within the cloud and some command-line tools that can help trigger the APIs. You can then start writing scripts using commands to create the infrastructure and parameterize them to use the same scripts in another environment. Well, that kind of solves the problem, right?

Not really! Writing scripts is an imperative way of managing infrastructure. Though you can still call it IaC...

Terraform providers

Terraform has a decentralized architecture. While the Terraform CLI contains Terraform's core functionality and provides all functionalities not related to any specific cloud provider, Terraform providers provide the interface between the Terraform CLI and the cloud providers themselves. This decentralized approach has allowed public cloud vendors to offer their Terraform providers so that their customers can use Terraform to manage infrastructure in their cloud. Such is Terraform's popularity that it has now become an essential requirement for every public cloud provider to offer a Terraform provider.

We will be interacting with Azure for this chapter's entirety; therefore, we will use the Azure Terraform provider for our activity.

To access the resources for this section, cd into the following:

$ cd ~/modern-devops/ch6/terraform-exercise/

Before we go ahead and configure the provider, we need to understand how Terraform needs to authenticate...

Terraform variables

To declare variables, we will need to create a vars.tf file with the following data:

variable "subscription_id" {
  type        = string
  description = "The azure subscription id"
}
variable "client_id" {
  type        = string
  description = "The azure service principal appId"
}
variable "client_secret" {
  type        = string
  description = "The azure service principal password"
  sensitive   = true
}
variable "tenant_id" {
  type        = string
  description = "The azure tenant id"
}

So, we've defined four variables here using variable blocks. Variable blocks typically have a type and a description. The type attribute...

Terraform workflow

The Terraform workflow typically consists of the following:

• init – Initializes the Terraform workspace and backend (more on them later) and downloads all required providers. You can run the init command multiple times during your build as it does not make changes to your workspace or state.
• plan – Runs a speculative plan on the requested resources. This command typically connects with the cloud provider, then checks whether the objects managed by Terraform exist within the cloud provider and whether they have the same configuration as defined in the Terraform template. It then shows the delta in the planned output that an admin can review and change the configuration if they are not satisfied. If they are satisfied, they can apply the plan to commit the changes to the cloud platform. The plan command does not make any changes to the current infrastructure.
• apply – This applies the delta configuration to the cloud platform. When...

terraform state

Terraform uses a state file to track what it has deployed and what resources it is managing. The state file is essential as it contains a record of all the infrastructure Terraform is maintaining, and if you lose it, Terraform will lose track of what it has done so far and start treating resources as if they are new and need to be created again. Therefore, you should protect your state as you would protect code.

Terraform stores state in backends. By default, Terraform stores the state file as a file called terraform.tfstate within the workspace directory, which is called the local backend. However, that is not one of the best ways of managing the state. There are several reasons why you should not store state in a local system:

• Multiple admins cannot work on the same infrastructure if the state file is stored within someone's local directory.
• Local workstations are not backed up, and therefore even if you have a single admin doing the job, the risk...

Terraform workspaces

Software development requires multiple environments. You develop software within your workspace, deploy it into the development environment, unit test it, and then promote the tested code to a test environment. Your QA team will test the code extensively in the test environment, and once all test cases pass, you can promote your code to production.

Well, that means you need to maintain a similar infrastructure in all environments. With an IaC tool such as Terraform, infrastructure is represented as code, and we have to manage our code to fit multiple environments. But Terraform is not just code, it also contains state files, and we have to maintain state files for every environment.

Let's suppose you need to create three resource groups, terraform-exercise-dev, terraform-exercise-test, and terraform-exercise-prod. Each resource group will contain a similar set of infrastructure with similar properties. For example, let's say each resource group...

Terraform output, state, console, and graphs

While we understand that Terraform uses state files to manage resources, let's look at some advanced commands that will help us appreciate and make more sense of the Terraform state concept.

To access the resources for this section, cd into the following:

$ cd ~/modern-devops/ch6/terraform-workspaces/

Now, let's go ahead and look at our first command – terraform output.

terraform output

So far, we've looked at variables, but we haven't yet discussed outputs. Terraform outputs are return values of a Terraform configuration that allow users to export configuration to users or any modules that might use the current module. We won't be creating modules in this book, however, to learn more about it, refer the official documentation at https://learn.hashicorp.com/tutorials/terraform/module.

For now, let's go with the last example and add an output variable that exports the private IP of the...

Summary

In this chapter, we've discussed Terraform's core and understood some of the most common commands and functionalities from a hands-on perspective. We started with understanding IaC, introduced Terraform as an IaC tool, installed Terraform, understood Terraform providers, and used the Azure Terraform provider to manage infrastructure in Azure.

We then looked at Terraform variables and multiple ways of supplying values to the variables. We discussed the core Terraform workflow, where we talked about several commands that you would use to manage infrastructure using Terraform. We then looked at Terraform state as an essential component that helps Terraform keep track of the infrastructure it is managing.

We looked at local and remote state storage and used Azure Blob Storage as the remote state backend. We then discussed Terraform workspaces and how they enable us to use the same Terraform configuration to build multiple environments with hands-on exercises.

...

Questions

1. Why should we constrain the provider version?
2. You should always use the fmt and validate functions before a Terraform plan – True/False?
3. What does the Terraform plan command do? (Multiple answers are possible.)

   A. Refreshes the current state with the existing infrastructure state

   B. Gets the delta between the current configuration and the expected configuration

   C. Applies the configuration to the cloud

   D. Destroys the configuration in the cloud

4. What does the terraform apply command do? (Multiple answers are possible.)

   A. Refreshes the current state with the existing infrastructure

   B. Gets the delta between the current configuration and the expected configuration

   C. Applies the configuration to the cloud

   D. Destroys the configuration in the cloud

5. Why should you never store state files in source control? (Multiple answers are possible.)

   A. State files are plaintext, and therefore you expose sensitive information to unprivileged users.

   B. Source control does...

Answers

1. Because Terraform providers are released separately to the Terraform CLI, different versions might break the existing configuration
2. True
3. A, B
4. A, B, C
5. A, B
6. A, B, C, E, F
7. The taint command
8. terraform.tfstate.d
9. terraform state rm <resource>
10. terraform import <resource> <id>