Introduction

Hey there Everyone! 👋 Welcome back to our exciting journey through the world of Infrastructure as Code with Terraform on Azure. If you’ve been following along, you’re already a Terraform trooper - you’ve set up your environment, created your first Azure resources, and mastered dependencies. Awesome work so far! 🎉

Today, we’re going to unlock two powerful features of Terraform: input and output variables. But don’t worry if that sounds a bit techy - by the end of this article, you’ll be using variables like a pro to make your Azure infrastructure code more flexible, reusable, and informative!

What are Terraform Variables?

In Terraform, we have two types of variables to discuss:

1. Input Variables: These allow you to customize your Terraform configurations without changing the main code.

2. Output Variables: These allow you to extract and display important information about the resources you’ve created.

Why are Variables Important?

Variables are game-changers for several reasons:

1. Reusability: Write your Terraform code once, use it many times with different inputs.
2. Flexibility: Easily adjust your infrastructure without diving into the main configuration.
3. Collaboration: Make it easier for team members to understand and modify configurations.
4. Security: Keep sensitive data out of your main Terraform files and version control.
5. Information Sharing: Outputs provide an easy way to get important details about your resources.
6. Integration: Outputs can be used to pass information to other tools or scripts in your deployment pipeline.

What We’ll Cover

In this article, we’ll explore:

• The different types of input variables and how to use them
• How to declare and use input variables in your configurations
• Various ways to provide values for input variables
• How to define and use output variables
• Best practices for using both input and output variables with Azure resources
• A hands-on example of refactoring an Azure configuration to use variables

By the end of this article, you’ll have a solid grasp on how to use both input and output variables to make your Terraform configurations for Azure more dynamic, maintainable, and informative. This knowledge will make you more confident in designing flexible infrastructure-as-code solutions, and it’ll be a valuable addition to your Terraform toolkit.

Ready to add some flexibility and insight to your Terraform skills? Let’s dive in! 🏊‍♂️

Understanding Terraform Variables

Let’s dive deeper into the world of Terraform variables. In Terraform, we have two main types of variables: input variables and output variables. Each plays a crucial role in making your Terraform configurations powerful and informative.

What are Input Variables?

Input variables are like the settings you can adjust before running your Terraform configuration. They allow you to customize your infrastructure without changing your main configuration code. Here’s what you need to know about input variables:

• They let you pass values into your Terraform module or configuration.
• You can change these values each time you run Terraform, allowing you to use the same code for different scenarios.

For example, you might use an input variable to specify the Azure region for your resources:

1
2
3
4
5
6
7
8
9

variable "azure_region" {
  type    = string
  default = "Australia East"
}

resource "azurerm_resource_group" "example" {
  name     = "my-resources"
  location = var.azure_region
}

If you decide to deploy to a different Azure region, simply update the input variable to reflect the new region. For instance, we are currently using Australia East, if we want to switch to Australia Southeast or Australia Central just modify the variable accordingly. The next time you deploy your Terraform configuration your resource group will be created in the selected Azure region, easy right 😊

What are Output Variables?

Output variables are used to extract information about your resources after Terraform has created them. They’re particularly useful for getting data that isn’t known until the resource is actually created. Here’s what you should know about output variables:

• They allow you to access specific attributes of your resources after they’ve been created.
• Output variables are crucial for getting information that’s generated during resource creation, like IP addresses or resource IDs.

For instance, you might use an output variable to get the IP address of a newly created VM:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

resource "azurerm_public_ip" "example" {
  name                = "vm-public-ip"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  allocation_method   = "Dynamic"
}

output "vm_public_ip" {
  value = azurerm_public_ip.example.ip_address
}

In this example, Azure assigns the IP address when it creates the public IP resource. The output variable allows you to access this IP address after it’s been assigned.

It’s important to note that output variables are for accessing information about resources managed by your current Terraform configuration. If you need to get information about existing resources that were created outside of your current Terraform project, you’d use data sources, which we’ll cover in a more advanced tutorial.

Understanding these two types of variables is your first step towards creating flexible and informative Terraform configurations. As we progress through this article, you’ll see how these variables can be used to customize your environment, create consistent naming conventions, handle sensitive information, and much more.

In the next section, we’ll explore the different types of input variables you can use in your Terraform configurations. Ready to add more tools to your Terraform toolkit? Let’s go! 🚀

Types of Input Variables

Now that we understand what input variables are, let’s explore the different types you can use in your Terraform configurations. Knowing these types will help you structure your Azure infrastructure code more effectively.

1. String Variables

String variables hold text values. They’re perfect for resource names, tags, or any value that’s expressed as text.

Example:

1
2
3
4
5
6
7
8
9

variable "resource_group_name" {
  type    = string
  default = "my-azure-resources"
}

resource "azurerm_resource_group" "example" {
  name     = var.resource_group_name
  location = "Australia East"
}

In this example, we’re using a string variable to set the name of our Azure Resource Group. This allows us to easily change the name without modifying the main configuration.

2. Number Variables

Number variables store numeric values. Use these for things like counts, sizes, or any numerical configuration.

Example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

variable "vm_count" {
  type    = number
  default = 2
}

resource "azurerm_virtual_machine" "example" {
  count               = var.vm_count
  name                = "vm-${count.index + 1}"
  # ... other VM configuration ...
}

Here, we’re using a number variable to specify how many virtual machines to create. In this case, Terraform will create two VM instances because vm_count is set to 2.

3. Boolean Variables

Boolean variables hold true/false values. They’re great for enabling or disabling features in your configuration.

Example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

variable "enable_public_ip" {
  type    = bool
  default = false
}

resource "azurerm_public_ip" "example" {
  count               = var.enable_public_ip ? 1 : 0
  name                = "my-public-ip"
  # ... other public IP configuration ...
}

In this example, we’re using a boolean variable to decide whether or not to create a public IP address. If enable_public_ip is true, one public IP will be created; if false, none will be created.

4. List Variables

List variables store multiple values of the same type. They’re useful for things like specifying multiple subnet ranges or VM sizes.

Example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

variable "allowed_ip_ranges" {
  type    = list(string)
  default = ["10.0.0.0/24", "10.0.1.0/24"]
}

resource "azurerm_network_security_group" "example" {
  # ... other NSG configuration ...

  dynamic "security_rule" {
    for_each = var.allowed_ip_ranges
    content {
      name                   = "allow-${security_rule.key}"
      priority               = 100 + security_rule.key
      direction              = "Inbound"
      access                 = "Allow"
      protocol               = "Tcp"
      source_address_prefix  = security_rule.value
      destination_port_range = "*"
      # ... other rule configuration ...
    }
  }
}

This example uses a list variable to specify multiple IP ranges for a network security group. Don’t worry too much about the details of the security group configuration – the key point is that we’re using a list variable to create multiple, similar resources.

5. Map Variables

Map variables are key-value pairs. They’re perfect for setting up multiple related configurations at once.

Example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

variable "vm_sizes" {
  type = map(string)
  default = {
    "dev"  = "Standard_B1s"
    "test" = "Standard_D2s_v3"
    "prod" = "Standard_D4s_v3"
  }
}

resource "azurerm_virtual_machine" "example" {
  # ... other VM configuration ...
  vm_size = var.vm_sizes[var.environment]
}

In this example, we’re using a map variable to specify different VM sizes for different environments. This allows us to easily set the appropriate VM size based on whether we’re deploying to development, testing, or production.

Putting It All Together

In real-world scenarios, you’ll often use a combination of these variable types to create flexible, powerful Terraform configurations. Here’s a quick example that uses all types:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

variable "resource_group_name" {
  type    = string
  default = "my-azure-project"
}

variable "location" {
  type    = string
  default = "Australia East"
}

variable "vm_count" {
  type    = number
  default = 2
}

variable "enable_monitoring" {
  type    = bool
  default = true
}

variable "allowed_ip_ranges" {
  type    = list(string)
  default = ["10.0.0.0/24", "10.0.1.0/24"]
}

variable "vm_sizes" {
  type = map(string)
  default = {
    "dev"  = "Standard_B1s"
    "test" = "Standard_D2s_v3"
    "prod" = "Standard_D4s_v3"
  }
}

# These variables can now be used throughout your Terraform configuration
# to create a flexible, environment-specific Azure infrastructure

Don’t worry if some of these examples seem complex – the important thing is to understand the different types of variables and when you might use them. As you progress in your Terraform journey, you’ll become more comfortable with these patterns and how to use them effectively in your Azure infrastructure configurations.

In the next section, we’ll look at how to declare these variables in your Terraform files and how to use them in your configurations. Ready to put these variable types into action? Let’s go! 🚀

Declaring Input Variables

Now that we understand the types of input variables available in Terraform, let’s look at how to declare them in your configuration. Declaring a variable is like setting up a container to hold a value - you’re telling Terraform, “I’m going to need this piece of information, and here’s what it should look like.”

The ‘variable’ Block

In Terraform, we declare variables using the variable block. Here’s the basic structure:

1
2
3
4
5

variable "variable_name" {
  type        = string
  default     = "default_value"
  description = "This is what my variable does"
}

Let’s break this down:

• variable_name: This is how you’ll refer to your variable in your configuration. Choose a name that’s clear and descriptive.
• type: This specifies what kind of variable it is (string, number, bool, list, or map).
• default: This is the value the variable will have if you don’t specify one elsewhere. It’s optional but often useful.
• description: A human-readable description of what the variable is for. It’s optional but highly recommended for documentation purposes.

Variable Attributes

Let’s look at each attribute in more detail:

1. Type The type attribute tells Terraform what kind of data the variable will hold.

   1 2 3 4 5 6 7

   variable "azure_region" { type = string } variable "vm_count" { type = number }

2. Default The default attribute sets a default value for your variable. If you don’t provide a value when using the variable, Terraform will use this default.

   1 2 3 4

   variable "environment" { type = string default = "development" }

3. Description The description attribute is like a comment for your variable. It’s super helpful when others (or future you) are reading your code.

   1 2 3 4

   variable "admin_username" { type = string description = "The username for the VM admin account" }

Where to Declare Variables

While you can declare variables in any .tf file in your Terraform configuration, it’s a common practice to put them all in a file called variables.tf. This keeps your variable declarations organized and easy to find.

Here’s what a variables.tf file might look like for an Azure project:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

# variables.tf

variable "resource_group_name" {
  type        = string
  default     = "my-azure-project"
  description = "Name of the Azure resource group"
}

variable "location" {
  type        = string
  default     = "Australia East"
  description = "Azure region for resource deployment"
}

variable "vm_size" {
  type        = string
  default     = "Standard_B1s"
  description = "Size of the Azure VM"
}

variable "enable_public_ip" {
  type        = bool
  default     = false
  description = "Whether to create a public IP for the VM"
}

variable "allowed_ip_ranges" {
  type        = list(string)
  default     = ["10.0.0.0/24", "10.0.1.0/24"]
  description = "List of allowed IP ranges for NSG rules"
}

By putting all your variables in one file, you create a single source of truth for all the customizable parts of your Terraform configuration. It’s like having a control panel for your entire Azure infrastructure!

In the next part, we’ll look at how to use these declared variables in your Terraform configuration. Ready to put your variables to work? Let’s go! 🚀

Using Input Variables in Your Configuration

Now that we’ve declared our input variables, it’s time to put them to work in our Terraform configuration. This is where the magic happens - we’ll use our variables to make our Azure infrastructure flexible and customizable.

Referencing Variables

To use a variable in your Terraform configuration, you reference it using the var. prefix followed by the variable name. It’s like calling your variables to action in your infrastructure play.

Here’s a simple example:

1
2
3
4

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

In this snippet, we’re using two variables: resource_group_name and location. Terraform will replace these with their actual values when it creates the resource group.

Practical Examples: Variables in Action

Let’s look at some more practical examples of how we can use variables to make our Azure configurations more flexible and reusable.

Example 1: Configurable Virtual Network

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

variable "vnet_name" {
  type    = string
  default = "my-vnet"
}

variable "vnet_address_space" {
  type    = list(string)
  default = ["10.0.0.0/16"]
}

resource "azurerm_virtual_network" "example" {
  name                = var.vnet_name
  address_space       = var.vnet_address_space
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
}

In this example, we can easily change the name and address space of our virtual network by adjusting the variables, without touching the resource configuration itself.

Example 2: Environment-Specific VM Sizes

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

variable "environment" {
  type    = string
  default = "dev"
}

variable "vm_sizes" {
  type = map(string)
  default = {
    dev  = "Standard_B1s"
    test = "Standard_D2s_v3"
    prod = "Standard_D4s_v3"
  }
}

resource "azurerm_virtual_machine" "example" {
  name                  = "my-vm"
  location              = azurerm_resource_group.example.location
  resource_group_name   = azurerm_resource_group.example.name
  vm_size               = var.vm_sizes[var.environment]
  # ... other VM configuration ...
}

Here, we’re using a map variable to select the appropriate VM size based on the environment. By changing the environment variable, we automatically get the right VM size.

Example 3: Conditional Resource Creation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

variable "enable_public_ip" {
  type    = bool
  default = false
}

resource "azurerm_public_ip" "example" {
  count               = var.enable_public_ip ? 1 : 0
  name                = "my-public-ip"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  allocation_method   = "Dynamic"
}

This example uses a boolean variable to conditionally create a public IP. If enable_public_ip is true, one public IP is created; if false, none are created.

String Interpolation: Combining Variables and Static Text

Sometimes you need to combine variables with static text or other variables. You can do this using string interpolation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

variable "project_name" {
  type    = string
  default = "myproject"
}

variable "environment" {
  type    = string
  default = "dev"
}

resource "azurerm_network_security_group" "example" {
  name                = "${var.project_name}-nsg-${var.environment}"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
}

In this example, if project_name is “myproject” and environment is “dev”, the resulting NSG name would be “myproject-nsg-dev”.

Using Variables with Count and For Each

Variables work great with Terraform’s count and for_each features for creating multiple similar resources:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

variable "vm_names" {
  type    = list(string)
  default = ["web", "app", "db"]
}

resource "azurerm_virtual_machine" "example" {
  count               = length(var.vm_names)
  name                = "${var.project_name}-${var.vm_names[count.index]}-vm"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  # ... other VM configuration ...
}

This configuration would create three VMs with names like “myproject-web-vm”, “myproject-app-vm”, and “myproject-db-vm”.

By effectively using variables in your Terraform configurations, you’re creating a flexible, reusable blueprint for your Azure infrastructure. It’s like having a Swiss Army knife for cloud deployment – adaptable to a variety of scenarios with just a few tweaks!

In our next section, we’ll explore the different ways to assign values to these variables. Ready to give your Terraform configurations even more flexibility? Let’s go! 🚀

Variable Input Methods

Now that we know how to declare variables, let’s explore the different ways we can give our variables actual values. But first, let’s clarify an important distinction.

Declaring vs. Assigning Values to Variables

In Terraform, we have two separate processes:

1. Declaring Variables: This is where we define what variables exist, their types, and optionally, their default values. This typically happens in the variables.tf file.

2. Assigning Values to Variables: This is where we give our declared variables specific values. There are several methods to do this, which we’ll explore below.

Think of declaring variables as setting up empty boxes with labels, and assigning values as filling those boxes with specific items. Now, let’s look at the ways we can fill our variable boxes!

1. Default Values: The Starting Point

When declaring a variable, you can give it a default value:

1
2
3
4

variable "location" {
  type    = string
  default = "Australia East"
}

If you don’t specify a value for this variable elsewhere, Terraform will use “Australia East”. It’s like having a go-to Azure region unless you decide to deploy somewhere else.

2. Command-Line Flags: Quick Changes 🏃‍♂️

You can override variable values directly from the command line when you run Terraform commands. This is great for quick changes without modifying your code.

1

terraform apply -var="location=Australia Southeast"

This command would use “Australia Southeast” as the location, overriding any default value.

3. Environment Variables: Local, Temporary Settings

Environment variables are settings on your local machine that Terraform can use. They’re useful for development and testing, especially for information you don’t want in your code files.

To use an environment variable for a Terraform variable, prefix it with TF_VAR_. For example, in your local terminal:

1
2

export TF_VAR_location="Australia Central"
terraform apply

This sets a local environment variable that Terraform will use for the “location” variable.

Important Note: While convenient for learning and development, environment variables are typically temporary and local to your machine. For production environments and sensitive data, more secure methods like Azure Key Vault should be used.

4. Variable Definition Files (.tfvars): Environment Configurations 📚

.tfvars files allow you to specify sets of variable values. These are particularly useful for managing different environments (development, testing, production).

Create a file named production.tfvars:

1
2
3

location = "Australia East"
vm_size  = "Standard_D2s_v3"
environment = "production"

Then apply your configuration using this file:

1

terraform apply -var-file="production.tfvars"

This is like having different pre-set configurations for your Azure resources – one for development, one for testing, one for production, etc.

The Order of Precedence: Who Wins?

What happens if you specify a variable value in multiple places? Terraform has a specific order of precedence:

1. Command-line flags (-var and -var-file)
2. .tfvars files specified on the command line
3. Environment variables
4. Default values in variable declarations

Think of it as a VIP list for your Azure party – command-line flags get in first, then the specially invited .tfvars files, and so on.

Practical Example: Configuring Different Environments

Let’s say we’re managing a web application on Azure with different settings for development and production environments.

First, we declare our variables in variables.tf:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

variable "environment" {
  type    = string
}

variable "location" {
  type    = string
}

variable "vm_size" {
  type    = string
}

Then, we create a dev.tfvars file:

1
2
3

environment = "development"
location    = "Australia Southeast"
vm_size     = "Standard_B2s"

And a prod.tfvars file:

1
2
3

environment = "production"
location    = "Australia East"
vm_size     = "Standard_D2s_v3"

Now, we can easily switch between environments:

1
2
3

terraform apply -var-file="dev.tfvars"
# or
terraform apply -var-file="prod.tfvars"

This setup allows us to maintain a single set of Terraform configurations while easily deploying to different environments.

A Word of Caution: Sensitive Information

While variables are great for making your configurations flexible, be careful with sensitive information like passwords or API keys. For production environments, use secure methods like Azure Key Vault to manage sensitive data, rather than including them in .tfvars files or environment variables.

By mastering these variable input methods, you’re adding powerful flexibility to your Terraform configurations. You’re not just writing infrastructure code – you’re creating adaptable, environment-aware Azure deployment recipes!

In our next section, we’ll explore output variables and how they can help us extract important information from our Azure resources. Ready to see the results of your Terraform magic? Let’s go! 🚀

Understanding and Using Output Variables

We’ve mastered input variables, now let’s explore their counterpart: output variables. Think of outputs as the treasure you unearth after Terraform has worked its magic on your Azure resources.

Purpose of Output Variables

Output variables serve several crucial purposes:

1. Information Retrieval: They allow you to extract important details about your resources after Terraform has created or updated them.
2. Visibility: Outputs provide an easy way to see critical information without digging through the Terraform state file.
3. Integration: You can use outputs to pass information to other parts of your infrastructure or to other tools in your DevOps pipeline.

Declaring Output Variables

Declaring an output variable is straightforward. Here’s the basic syntax:

1
2
3
4
5

output "output_name" {
  value       = [resource_type.resource_name.attribute]
  description = "Description of the output"
  sensitive   = false
}

Let’s break this down:

• output_name: A unique identifier for this output.
• value: The data you want to output. This can be a simple value or a complex expression.
• description: An optional field to describe what this output represents.
• sensitive: Set this to true if the output contains sensitive data that shouldn’t be displayed in logs.

Practical Examples in Azure

Let’s look at some real-world examples of using output variables with Azure resources.

Example 1: Resource Group ID

1
2
3
4
5
6
7
8
9

resource "azurerm_resource_group" "example" {
  name     = "my-resources"
  location = "Australia East"
}

output "resource_group_id" {
  value       = azurerm_resource_group.example.id
  description = "The ID of the created Resource Group"
}

This output will display the ID of the created resource group, which can be useful for referencing in other parts of your configuration or in external scripts.

Example 2: VM Public IP Address

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

resource "azurerm_public_ip" "example" {
  name                = "vm-public-ip"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  allocation_method   = "Dynamic"
}

output "vm_public_ip" {
  value       = azurerm_public_ip.example.ip_address
  description = "The public IP address of the VM"
}

This output will show the public IP address assigned to your VM. This is particularly useful because the IP address isn’t known until Azure actually assigns it during resource creation.

Example 3: Storage Account Access Key

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

resource "azurerm_storage_account" "example" {
  name                     = "mystorageaccount"
  resource_group_name      = azurerm_resource_group.example.name
  location                 = azurerm_resource_group.example.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

output "storage_account_primary_access_key" {
  value       = azurerm_storage_account.example.primary_access_key
  description = "The primary access key for the storage account"
  sensitive   = true
}

Note the sensitive = true in this output. This tells Terraform to hide this value in the console output, which is important for security when dealing with sensitive information like access keys.

Accessing Output Values

After applying your Terraform configuration, you can view the outputs by running:

1

terraform output

If you want to see the value of a specific output, you can use:

1

terraform output output_name

For sensitive outputs, you’ll need to explicitly request to see the value:

1

terraform output -json storage_account_primary_access_key

Using Outputs in Practice

Outputs become particularly powerful when:

1. Working with Modules: Outputs allow child modules to expose specific values to the root module.
2. CI/CD Pipelines: You can use outputs to pass information to subsequent steps in your deployment process.
3. Documentation: Outputs serve as self-documenting features of your infrastructure.

For example, you might use the VM’s public IP output in a script that configures DNS:

1
2

IP=$(terraform output -raw vm_public_ip)
az network dns record-set a add-record -g MyResourceGroup -z example.com -n www -a $IP

Best Practices for Outputs

1. Be Selective: Only output information that’s truly useful. Avoid cluttering your outputs with unnecessary data.
2. Use Descriptive Names: Like with input variables, use clear and descriptive names for your outputs.
3. Add Descriptions: Always include a description for each output to explain what it represents.
4. Handle Sensitive Data Carefully: Use the sensitive = true attribute for outputs containing sensitive information.

By mastering output variables, you’re not just building infrastructure – you’re creating informative, integrated Azure deployments with Terraform. It’s like having a detailed report card for your cloud resources!

In our next section, we’ll look at some best practices for using both input and output variables effectively. Ready to polish your Terraform skills to a shine? Let’s go! 🌟

Best Practices for Using Variables

Now that we’ve explored both input and output variables, let’s dive into some best practices that will help you use them effectively in your Azure infrastructure code. These tips will help you write cleaner, more maintainable, and more secure Terraform configurations.

1. Use Clear, Descriptive Naming Conventions 🏷️

Good variable names are like good road signs - they should clearly indicate what’s ahead.

• Use lowercase letters and underscores for readability.
• Be specific but concise.
• Consider prefixing variables with their purpose or scope.

1
2
3
4
5
6
7
8
9

# Good
variable "primary_azure_region" {
  type = string
}

# Avoid
variable "r" {
  type = string
}

2. Document Your Variables 📚

Future you (and your teammates) will thank you for good documentation.

• Always use the description field for both input and output variables.
• Explain the purpose, any constraints, and expected format if applicable.

1
2
3
4
5

variable "vm_size" {
  type        = string
  default     = "Standard_D2s_v3"
  description = "The size of the Azure VM. Affects compute capacity and pricing."
}

3. Use Variable Validation 🔍

Terraform allows you to add validation rules to your input variables. This can help catch configuration errors early:

1
2
3
4
5
6
7
8
9

variable "environment" {
  type        = string
  description = "The deployment environment (dev, test, prod)"
  
  validation {
    condition     = contains(["dev", "test", "prod"], var.environment)
    error_message = "Environment must be 'dev', 'test', or 'prod'."
  }
}

4. Leverage Default Values Wisely 🎛️

• Provide defaults for non-critical settings to make your modules easier to use.
• Avoid defaults for critical or environment-specific values.

5. Group Related Variables 🗂️

Keep your variables organized by grouping related ones together. You can do this in your variables.tf file or even split them into multiple files for larger projects.

6. Use Variables for Consistent Naming 🔤

Use variables to enforce consistent naming across your Azure resources:

1
2
3
4

resource "azurerm_resource_group" "example" {
  name     = "${var.project_name}-${var.environment}-rg"
  location = var.azure_region
}

7. Handle Sensitive Data Carefully 🔒

• Never store sensitive data like passwords or API keys directly in your Terraform files or version control.
• Use environment variables for local development.
• For production, use Azure Key Vault or similar secure storage solutions.
• Mark sensitive outputs with sensitive = true.

1
2
3
4
5

variable "db_password" {
  type        = string
  sensitive   = true
  description = "Database password. Should be provided via environment variable."
}

8. Use Maps for Related Sets of Values 🗺️

When you have sets of related values, consider using map variables:

1
2
3
4
5
6
7
8

variable "vm_sizes" {
  type = map(string)
  default = {
    "small"  = "Standard_B1s"
    "medium" = "Standard_D2s_v3"
    "large"  = "Standard_D4s_v3"
  }
}

9. Be Selective with Outputs 🎯

Only output information that’s truly useful. Avoid cluttering your outputs with unnecessary data.

10. Keep Your Configurations DRY (Don’t Repeat Yourself) 🔁

Use variables to avoid repetition in your configurations. If you find yourself repeating the same value multiple times, it’s probably a good candidate for a variable.

11. Leverage Variable Files for Different Environments 🌍

Use .tfvars files to manage configurations for different environments:

1

terraform apply -var-file="prod.tfvars"

By following these best practices, you’ll create Terraform configurations for Azure that are easier to read, maintain, and reuse. Remember, good variable management is key to flexible and robust Infrastructure as Code!

In our final section, we’ll troubleshoot some common variable-related issues. Ready to become a Terraform troubleshooting pro? Let’s go! 🚀

Conclusion

We’ve journeyed through the land of Terraform variables, and what an adventure it’s been! Let’s take a moment to recap our expedition and look ahead to the exciting terrain that awaits us.

What We’ve Covered

In this article, we’ve explored:

1. The power of input variables in making our Terraform configurations flexible and reusable
2. Different types of input variables (string, number, bool, list, and map) and when to use each
3. How to declare and use input variables in your Azure infrastructure code
4. Various methods for assigning values to variables, from default values to .tfvars files
5. The magic of output variables in extracting and displaying important information about our Azure resources
6. Best practices for using both input and output variables effectively

You’ve now got a powerful set of tools to make your Terraform configurations for Azure more dynamic, maintainable, and informative. Whether you’re spinning up a simple resource group or orchestrating a complex multi-tier application, variables will be your trusty sidekicks in your Infrastructure as Code journey.

Putting It All Together

Remember, effective use of variables can help you:

• Create reusable Terraform modules
• Easily manage different deployment environments (dev, test, prod)
• Keep sensitive information out of your main configuration files
• Make your Terraform code more readable and maintainable
• Extract and share important information about your Azure resources
• Integrate your Terraform-managed infrastructure with other tools and processes

As you continue to work with Terraform and Azure, you’ll find even more ways to leverage variables to streamline your infrastructure management and enhance your workflows.

What’s Next? The Grand Finale! 🎭

But wait, there’s more! 🎉 We’re not done yet with our Terraform exploration. In our next and final article of this series, we’re pulling out all the stops for a grand finale that will knock your socks off!

We’ll be diving into one of the most powerful features of Terraform: Modules. These are like the ultimate building blocks for your infrastructure, allowing you to create reusable, shareable components of your Azure setup.

But that’s not all! We’ll also be presenting a grand finale project that brings together everything we’ve learned in the series. We’re talking variables, outputs, dependencies, state management, and now modules - all coming together in a symphony of Infrastructure as Code!

Imagine creating a multi-tier Azure application with:

• A flexible networking setup
• Scalable compute resources
• Secure storage solutions
• All orchestrated with reusable Terraform modules

It’s going to be epic, and you’re not going to want to miss it!

So, pat yourself on the back for mastering Terraform variables, take a quick breather, and get ready for the grand finale. The world of Infrastructure as Code is at your fingertips, and you’re about to compose your masterpiece!

Keep exploring, keep learning, and most importantly, keep having fun with Terraform and Azure. The cloud’s the limit! ☁️🚀

Stay strong 💪, and happy Terraforming! See you at the grand finale!