Welcome back to the third post of the Terraform series. In this post I will cover, how Terraform can merge multiple configuration and variables files into one. This gives you better transparency, flexibility and control for your Terraform-based deployments. Enjoy!

Terraform Series

1. A first introduction
2. Introducing input variables
3. Using multiple files for configurations and variables (this post)

When Terraform is planning, applying or destroying resources, the CLI searches for valid .tf-files in the directory. Before Terraform does anything, all these files are merged into a single file that then gets used with the fired command. This can help with transparency and management of Terraform files as it allows you to spread different information such as providers, resources and outputs in different, smaller and better-to-read files. In this example I will use 4 Terraform files.

demo7.tfvars – variables values

This file contains 4 variables that are needed by the Azure RM provider to get access to my Azure subscription. Tenant and Subscription IDs are obviously IDs of my Azure tenant and subscriptions I want to work with. The Client ID and Secret are from a service principal (service account) in Azure AD that allows Terraform to authenticate. The service principal can be given the exact permissions hat Terraform will need (e.g. RBAC at management group, subscription or resource group level).

subscription_id = “xxx”
client_id = “xxx”
client_secret = “xxx”
tenant_id = “xxx”

demo7-0.tf – variables

This file contains all variables. Some of them are identical to the ones from the .tfvars-file. By starting the Terraform apply, plan or destroy process, these variables values will be assigned the values from the .tfvars-file (because of the identical name). It also contains additional variables that are hardcoded here (azure_region).

variable “subscription_id”{}
variable “client_id”{}
variable “client_secret”{}
variable “tenant_id”{}
variable “azure_region” {
default = “West Europe”
}

demo7-1.tf – provider

This file creates my provider (azurerm) and uses the variable values to make sure the connection will be successful. It uses variable values.

provider “azurerm” {
subscription_id = “${var.subscription_id}”
client_id = “${var.client_id}”
client_secret = “${var.client_secret}”
tenant_id = “${var.tenant_id}”
}

demo7-2.tf – resource group

This file is used to describe a resource group.

resource “azurerm_resource_group” “demo7” {
name = “weu-dev-rg-terraform-07”
location = ${var.azure_region}
tags {
“Owner” = “Marcel Zehner”
“Department” = “IT”
}
}

demo7-3.tf – resource

This file is used to deploy a resource into the resource group that is described in demo7-2.tf. It also contains a dependency configuration to the resource group to instruct Terraform about the correct sequence when deploying resources.

resource “azurerm_virtual_network” “demo7”
name = “weu-dev-vnet-terrademo-07”
address_space = [“10.0.0.0/16”]
location = “${azurerm_resource_group.demo7.location}”
resource_group_name = “${azurerm_resource_group.demo7.name}”
depends_on = [“azurerm_resource_group.demo7”]
tags {
“Owner” = “Marcel Zehner”
“Department” = “IT”
}
}

Deploy the configuration

To deploy the multi-file configuration, I just need to start a regular plan, apply or destroy task. Terraform will find all the tf.-files, merge them and then executes. If a variables file should be used, the parameter –var-file is needed to point Terraform to the file.

.\terraform.exe plan–var-file .\demo7.tfvars

.\terraform.exe apply –var-file .\demo7.tfvars

As you can see, my files have been automatically merged by Terraform.

One thing I did not mention yet is that you can also have multiple .tfvars.files (e.g. when you want to separate variables). In this case you have to instruct Terraform to use all of them by using the –var-file parameter multiple times:

.\terraform.exe plan –var-file .\demo7-1.tfvars –var-file .\demo7-2.tfvars

To quickly sum up: What are the benefits of having multiple Terraform files?

• Easier to manage
• More transparency
• Flexibility
• Better source control handling (e.g. you can decide not to check in the a variables files into source control that contains personal keys or id’s – of course this is a bad practice I will cover in a later post)

In the next post I will cover how to re-use Terraform configurations by using modules. See you soon!

Cheers
Marcel