For this chapter, you will need to have the Terraform binary installed on your computer. The source code for this chapter is available at https://github.com/PacktPublishing/Terraform-Cookbook/tree/master/CHAP02.

Check out the following video to see the code in action: https://bit.ly/3hcZNVR

The default behavior of Terraform is that, when executing the terraform init command, the version of the Terraform binary (which we will call the Command-Line Interface (CLI), as explained here: https://www.terraform.io/docs/glossary.html#cli) used is the one installed on the local workstation. In addition, this command downloads the latest version of the providers used in the code.

However, for compatibility reasons, it is always advisable to avoid surprises so that you can specify which version of the Terraform binary is going to be used in the Terraform configuration. The following are some examples:

• A Terraform configuration written with HCL 2 must indicate that it has to be executed with a Terraform version greater than or equal to 0.12.
• A Terraform configuration that contains new features such as count and for_each in modules must indicate that it has to be executed with a Terraform version greater than or equal to 0.13.

In the same vein and for the same reasons of compatibility, we may want to specify the provider version to be used.

In this recipe, we will learn how to specify the Terraform version, as well as the provider version.

Getting ready

To start this recipe, we will write a basic Terraform configuration file that contains the following code:

variable "resource_group_name" {
  default = "rg_test"
}
resource "azurerm_resource_group" "rg" {
  name     = var.resource_group_name
  location = "West Europe"
}
resource "azurerm_public_ip" "pip" {
  name                         = "bookip"
  location                     = "West Europe"
  resource_group_name          = azurerm_resource_group.rg.name
  public_ip_address_allocation = "Dynamic"
  domain_name_label            = "bookdevops"
}

This example code provides resources in Azure (a Resource Group and a public IP address). For more details, read the following documentation about the Terraform AzureRM provider: https://www.terraform.io/docs/providers/azurerm/index.html

Finally, when executing the terraform plan command inside this code, we get the following warning message:

This means that, currently, this Terraform configuration is still compatible with the latest version of the provider but that in a future version of the provider, this property will be changed and therefore this code will no longer work.

Now, let's discuss the steps we need to follow to make the following compliances:

• This configuration can only be executed if Terraform 0.13 (at least) is installed on the local computer.
• Our current configuration can be executed even if the azurerm provider evolves with breaking changes.

We'll take a look at this next.

How to do it…

To specify the Terraform version to be installed on the local workstation, do the following:

1. In the Terraform configuration, add the following block:

terraform {
  required_version = ">= 0.13"
}

2. To specify the provider source and version to use, we need to add the required_provider block inside the same terraform configuration block:

terraform {
  ...
  required_providers {
    azurerm = {
      source = "hashicorp/azurerm"
      version = "2.10.0"
    }
  }
}

How it works…

When executing the terraform init command, Terraform will check that the version of the installed Terraform binary that executes the Terraform configuration file corresponds to the version specified in the required_version property of the terraform block.

If it matches, it won't throw an error as it is greater than version 0.13. Otherwise, it will throw an error:

With regard to the specification of the provider version, when executing the terraform init command, if no version is specified, Terraform downloads the latest version of the provider, otherwise it downloads the specified version, as shown in the following two screenshots.

The following screenshot shows the provider plugin being downloaded from the specified source without us specifying the required version (at the time of writing, the latest version of the provider is 2.20.0):

As we can see, the latest version of the azurerm provider (2.20.0) has been downloaded.

In addition, the following screenshot shows the azurerm provider plugin being downloaded when we specify the required version (2.10.0):

As we can see, the specified version of the azurerm provider (2.10.0) has been downloaded.

In this required_version block, we also add the source property, which was introduced in version 0.13 of Terraform and is documented here: https://github.com/hashicorp/terraform/blob/master/website/upgrade-guides/0-13.html.markdown#explicit-provider-source-locations

There's more…

In this recipe, we learned how to download the azurerm provider in various ways. What we did here applies to all providers you may wish to download.

It is also important to mention that the version of the Terraform binary that's used is specified in the Terraform state file. This is to ensure that nobody applies this Terraform configuration with a lower version of the Terraform binary, thus ensuring that the format of the Terraform state file conforms with the correct version of the Terraform binary.

See also

• For more information about the properties of the Terraform block, go to https://www.terraform.io/docs/configuration/terraform.html.
• For more information about the properties of the providers, go to https://www.terraform.io/docs/configuration/providers.html.
• More information about Terraform binary versioning is documented at https://www.terraform.io/docs/extend/best-practices/versioning.html.
• The upgrade guide for the azurerm provider (to version 2.0) is available at https://www.terraform.io/docs/providers/azurerm/guides/2.0-upgrade-guide.html.

When you write a Terraform configuration file where all the properties are hardcoded in the code, you often find yourself faced with the problem of having to duplicate it in order to reuse it.

In this recipe, we'll learn how to make the Terraform configuration more dynamic by using variables.

Getting ready

To begin, we are going to work on the main.tf file, which contains a basic Terraform configuration:

resource "azurerm_resource_group" "rg" {
  name     = "My-RG"
  location = "West Europe"
}

As we can see, the name and location properties have values written in the code in a static way.

Let's learn how to make them dynamic using variables.

How to do it…

Perform the following steps:

1. In the same main.tf file, add the following variable declarations:

variable "resource_group_name" {
  description ="The name of the resource group"
}
variable "location" {
  description ="The name of the Azure location"
  default ="West Europe"
}

2. Then, modify the Terraform configuration we had at the beginning of this recipe so that it refers to our new variables, as follows:

resource "azurerm_resource_group" "rg" {
  name     = var.resource_group_name
  location = var.location
}

3. Finally, in the same folder that contains the main.tf file, create a new file called terraform.tfvars and add the following content:

resource_group_name = "My-RG"
location            = "westeurope"

How it works…

In step 1, we wrote the declaration of the two variables, which consists of the following elements:

• A variable name: This must be unique to this Terraform configuration and must be explicit enough to be understood by all the contributors of the code.
• A description of what this variable represents: This description is optional, but is recommended because it can be displayed by the CLI and can also be integrated into the documentation, which is automatically generated.
• A default value: This is optional. Not setting a default value makes it mandatory to enter a default value.

Then, in step 2, we modified the Terraform configuration to use these two variables. We did this using the var.<name of the variable> syntax.

Finally, in step 3, we gave values to these variables in the terraform.tfvars file, which is used natively by Terraform.

The result of executing this Terraform configuration is shown in the following screenshot:

There's more…

Setting a value in the variable is optional in the terraform.tfvars file since we have set a default value for the variable.

Apart from this terraform.tfvars file, it is possible to give a variable a value using the -var option of the terraform plan and terraform apply commands, as shown in the following command:

terraform plan -var "location=westus"

So, with this command, the location variable declared in our code will have a value of westus instead of westeurope.

In addition, with the 0.13 version of Terraform released in August 2020, we can now create custom validation rules for variables which makes it possible for us to verify a value during the terraform plan execution.

In our recipe, we can complete the location variable with a validation rule in the validation block as shown in the following code:

variable "location" {
  description ="The name of the Azure location"
  default ="West Europe"
  validation { # TF 0.13
    condition = can(index(["westeurope","westus"], var.location) >= 0)
    error_message = "The location must be westeurope or westus."
  }
}

In the preceding configuration, the rule checks that if the value of the location variable is westeurope or westus.

The following screenshot shows the terraform plan command in execution if we put another value in the location variable, such as westus2:

For more information about variable custom rules validation read the documentation at https://www.terraform.io/docs/configuration/variables.html#custom-validation-rules.

Finally, there is another alternative to setting a value to a variable, which consists of setting an environment variable called TF_VAR_<variable name>. As in our case, we can create an environment variable called TF_VAR_location with a value of westus and then execute the terraform plan command in a classical way.

See also

In this recipe, we looked at the basic use of variables. We will look at more advanced uses of these when we learn how to manage environments in the Managing infrastructure in multiple environments recipe, later in this chapter.

For more information on variables, refer to the documentation here: https://www.terraform.io/docs/configuration/variables.html