Introduction

Hey there Everyone! Welcome to the grand finale of our Terraform on Azure series. If you’ve been with us from the beginning, give yourself a round of applause – you’ve come a long way! 👏

We’ve journeyed through the fundamentals of Terraform, set up our development environment, created our first Azure resources, mastered dependencies, dived deep into state management, and harnessed the power of variables. Now, it’s time to put on the conductor’s hat and orchestrate a symphony of Azure infrastructure using Terraform’s most powerful feature: Modules.

Recapping Our Terraform Journey

Let’s take a quick stroll down memory lane to see how far we’ve come:

1. We started by learning the basics of Terraform and its core concepts for Azure, understanding why it’s a game-changer for cloud infrastructure management.

2. We then set up our local Terraform environment for Azure development, getting hands-on with the essential tools.

3. Next, we created our first Terraform project on Azure, taking our first steps in deploying real Azure resources with code.

4. We delved into Terraform state management in Azure, learning how to keep our infrastructure in check.

5. We then tackled Terraform dependencies in Azure infrastructure, mastering the art of creating robust, interconnected resources.

6. Most recently, we explored Terraform variables for Azure infrastructure, harnessing their power to make our configurations flexible and reusable.

Each of these steps has been a crucial building block, preparing us for this moment – where we bring it all together to orchestrate complex Azure infrastructure using Terraform modules.

What are Terraform Modules?

Now, drum roll, please… 🥁 Enter Terraform Modules!

Imagine if you could take a piece of your Terraform configuration – say, a perfectly crafted Virtual Network setup – package it up, and reuse it across multiple projects. That’s exactly what modules allow you to do. They’re like Lego blocks for your infrastructure, allowing you to build complex, scalable, and maintainable Azure environments.

Modules in Terraform are self-contained packages of Terraform configurations that are managed as a group. They’re a way to make your Terraform code modular, reusable, and shareable. Think of them as functions in a programming language, but for your infrastructure.

Why Modules are a Game-Changer

Modules aren’t just a neat feature – they’re a revolution in how we approach Infrastructure as Code. Here’s why:

1. Reusability: Write once, use many times. Modules allow you to encapsulate common infrastructure patterns and reuse them across projects.
2. Abstraction: Modules can hide complex details behind a simple interface, making your main configuration cleaner and easier to understand.
3. Consistency: By using the same modules across projects, you ensure consistency in your infrastructure setup.
4. Collaboration: Modules can be shared among team members or even with the broader Terraform community, fostering collaboration and best practices.
5. Scalability: As your infrastructure grows, modules help manage complexity by breaking your configuration into manageable, logical units.

What’s Ahead: Our Grand Finale Project

In this article, we’re not just going to learn about modules – we’re going to use them to orchestrate a complex, multi-tier Azure application. We’ll create modules for networking, compute, database, and storage, and then bring them all together in a harmonious Infrastructure as Code masterpiece.

By the end of this guide, you’ll be able to:

• Create and use your own Terraform modules
• Leverage public modules from the Terraform Registry
• Compose complex Azure infrastructure using modular, reusable code
• Apply best practices for large-scale Terraform projects

Are you ready to become a Terraform expert? Grab your beverage ☕, and let’s compose some infrastructure magic! 🚀

Understanding Terraform Modules

Now that we’ve set the stage, let’s dive deeper into the world of Terraform Modules. Think of this as your guide to understanding the building blocks that will take your Infrastructure as Code to the next level.

What Exactly is a Terraform Module?

At its core, a Terraform Module is a container for multiple resources that are used together. But it’s so much more than just a grouping mechanism. A module is a way to package and reuse resource configurations, making your Terraform code more organized, maintainable, and shareable.

In essence, a Terraform Module is a set of Terraform configuration files in a single directory. This directory contains a collection of .tf and/or .tf.json files that work together to define a set of related resources. Here’s what a typical module structure might look like:

1
2
3
4
5
6

my_module/
│
├── main.tf         # Main resource definitions
├── variables.tf    # Input variable declarations
├── outputs.tf      # Output value declarations
└── versions.tf     # (Optional) Provider version constraints

Modules can represent anything from a single Azure resource with a standardized configuration to a full application stack with multiple interconnected resources.

When you run Terraform commands, it treats the current working directory as the root module. Any subdirectories containing Terraform configuration files can be treated as child modules, which can be called from your root module or other modules. Here’s an example of a project structure with modules:

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

project_root/
│
├── main.tf                 # Root configuration file
├── variables.tf
├── outputs.tf
│
└── modules/
    ├── networking/         # Networking module
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    │
    └── compute/            # Compute module
        ├── main.tf
        ├── variables.tf
        └── outputs.tf

In this structure, networking and compute are child modules that can be called from the root main.tf file.

The power of modules lies in their ability to be shared and reused. You can use the same module multiple times within a configuration, or across different projects. This promotes consistency and reduces duplication in your infrastructure code. For example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# In root main.tf
module "network_dev" {
  source = "./modules/networking"
  # ... variable inputs for dev environment
}

module "network_prod" {
  source = "./modules/networking"
  # ... variable inputs for prod environment
}

Modules can also accept input variables and declare output values, allowing them to be flexible and communicate information to other parts of your configuration. This makes them behave somewhat like functions in traditional programming languages, but for your infrastructure.

By using modules, you can build complex, scalable, and maintainable infrastructure configurations from smaller, reusable building blocks.

The Anatomy of a Module

A typical Terraform module consists of several key files:

1. main.tf: This is where you define the main set of resources your module will manage.
2. variables.tf: Here, you declare the input variables for your module.
3. outputs.tf: This file defines the values that the module will return.
4. versions.tf (optional): You can specify required provider versions here.

For example, a simple Azure virtual network module might look like this:

 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

# main.tf
resource "azurerm_virtual_network" "vnet" {
  name                = var.vnet_name
  address_space       = var.address_space
  location            = var.location
  resource_group_name = var.resource_group_name
}

# variables.tf
variable "vnet_name" {
  type        = string
  description = "Name of the virtual network"
}

variable "address_space" {
  type        = list(string)
  description = "Address space for the virtual network"
}

variable "location" {
  type        = string
  description = "Azure region for the virtual network"
}

variable "resource_group_name" {
  type        = string
  description = "Name of the resource group"
}

# outputs.tf
output "vnet_id" {
  value       = azurerm_virtual_network.vnet.id
  description = "ID of the created virtual network"
}

How Modules Promote Code Reuse and Organization

Modules are the secret sauce to writing DRY (Don’t Repeat Yourself) Terraform code. Here’s how they help:

1. Encapsulation: Modules allow you to package related resources together. For instance, you might have a “web-app” module that includes an App Service, a SQL Database, and associated networking components.

2. Abstraction: By using modules, you can hide complex details behind a simple interface. Your main configuration becomes more about high-level architecture than low-level resource details.

3. Reusability: Once you’ve created a module, you can use it multiple times in the same project or across different projects. For example, you could have a “virtual-network” module that you use for all your Azure projects.

4. Consistency: By using the same modules across projects, you ensure that resources are configured consistently, reducing the chance of errors or misconfigurations.

5. Version Control: Modules can be versioned, allowing you to manage changes to your infrastructure components over time.

The Power of Composition

One of the most powerful aspects of modules is that they can be nested. You can use modules within modules, allowing you to build complex infrastructures from simpler building blocks. It’s like using smaller LEGO pieces to build larger, more complex structures.

For instance, you might have a “webapp” module that uses a “networking” module and a “database” module. This compositional approach allows you to build complex, yet manageable, infrastructure configurations.

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

module "networking" {
  source = "./modules/networking"
  # ... input variables ...
}

module "database" {
  source = "./modules/database"
  # ... input variables ...
}

module "webapp" {
  source = "./modules/webapp"
  vnet_id = module.networking.vnet_id
  db_connection_string = module.database.connection_string
  # ... other input variables ...
}

Modules: Local vs Remote

Terraform modules can be sourced from various locations:

1. Local paths: Modules in subdirectories of your main configuration.
2. Terraform Registry: A repository of publicly available modules.
3. GitHub (or other version control systems): Modules can be sourced directly from Git repositories.
4. Azure Storage: For privately stored modules within your Azure environment.

This flexibility allows you to choose the best approach for your needs, whether it’s keeping everything local for a small project or leveraging shared modules for enterprise-scale infrastructure.

By mastering modules, you’re not just writing Terraform code – you’re creating reusable, scalable infrastructure blueprints. In our next section, we’ll roll up our sleeves and create our first Terraform module. Ready to start building? Let’s go! 🚀

Creating Your First Terraform Module

Now that we understand what Terraform modules are, let’s roll up our sleeves and create one. We’ll start with a simple module for an Azure resource group, then build upon it to create a more complex networking module.

Basic Components of a Module

Remember, a typical module consists of three main files:

1. main.tf: Contains the main resource definitions
2. variables.tf: Declares input variables for the module
3. outputs.tf: Defines the values that the module will return

Let’s create these files for our resource group module.

Writing a Simple Azure Module

First, let’s create a directory structure for our modules:

1
2

mkdir -p modules/resource_group
cd modules/resource_group

Now, let’s create our module files:

1. main.tf:

1
2
3
4
5
6

resource "azurerm_resource_group" "rg" {
  name     = var.rg_name
  location = var.location

  tags = var.tags
}

2. variables.tf:

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

variable "rg_name" {
  type        = string
  description = "The name of the resource group"
}

variable "location" {
  type        = string
  description = "The Azure region where the resource group should be created"
}

variable "tags" {
  type        = map(string)
  description = "A mapping of tags to assign to the resource group"
  default     = {}
}

3. outputs.tf:

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

output "rg_name" {
  value       = azurerm_resource_group.rg.name
  description = "The name of the resource group"
}

output "rg_location" {
  value       = azurerm_resource_group.rg.location
  description = "The location of the resource group"
}

output "rg_id" {
  value       = azurerm_resource_group.rg.id
  description = "The ID of the resource group"
}

Using Your Resource Group Module

Now that we’ve created our module, let’s use it in our root configuration. This root configuration acts as the blueprint for our entire infrastructure.

To help visualize our directory structure, it might look something like this:

1
2
3
4
5
6
7
8
9

project_root/
│
├── main.tf                 # Root configuration file
│
└── modules/
    └── resource_group/     # Our resource group module
        ├── main.tf
        ├── variables.tf
        └── outputs.tf

Create a new main.tf file in your project root directory:

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

provider "azurerm" {
  features {}
}

module "resource_group" {
  source   = "./modules/resource_group"
  rg_name  = "my-resource-group"
  location = "East US"
  tags = {
    environment = "dev"
    project     = "terraform-learning"
  }
}

# Use the output from the module
output "resource_group_id" {
  value = module.resource_group.rg_id
}

In this root configuration, we’re using our custom resource group module and passing in the required variables. The source = "./modules/resource_group" tells Terraform where to find our module files relative to this root main.tf file.

Note that we’re using one of the module’s outputs (rg_id) in our root module’s output. While this might seem redundant since we already defined this output in the module, it’s often useful in root configurations to expose specific outputs from modules. This allows other parts of your configuration or external scripts to easily access this information.

Creating a More Complex Module: A Networking Module

Now that we’ve created a simple module, let’s create a more complex one for networking. This module will create a virtual network with a subnet, demonstrating how we can encapsulate more complex resource relationships within a module.

Let’s create a new directory for the networking module, still within our modules folder:

1
2

mkdir -p modules/networking
cd modules/networking

Now, create the module files:

1. main.tf:

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

resource "azurerm_virtual_network" "vnet" {
  name                = var.vnet_name
  address_space       = var.address_space
  location            = var.location
  resource_group_name = var.resource_group_name

  tags = var.tags
}

resource "azurerm_subnet" "subnet" {
  name                 = var.subnet_name
  resource_group_name  = var.resource_group_name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes     = var.subnet_address_prefix
}

2. variables.tf:

 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

variable "vnet_name" {
  type        = string
  description = "Name of the virtual network"
}

variable "address_space" {
  type        = list(string)
  description = "Address space for the virtual network"
}

variable "location" {
  type        = string
  description = "Azure region for the virtual network"
}

variable "resource_group_name" {
  type        = string
  description = "Name of the resource group"
}

variable "subnet_name" {
  type        = string
  description = "Name of the subnet"
}

variable "subnet_address_prefix" {
  type        = list(string)
  description = "Address prefix for the subnet"
}

variable "tags" {
  type        = map(string)
  description = "A mapping of tags to assign to the resources"
  default     = {}
}

3. outputs.tf:

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

output "vnet_id" {
  value       = azurerm_virtual_network.vnet.id
  description = "The ID of the virtual network"
}

output "vnet_name" {
  value       = azurerm_virtual_network.vnet.name
  description = "The name of the virtual network"
}

output "subnet_id" {
  value       = azurerm_subnet.subnet.id
  description = "The ID of the subnet"
}

Now, let’s use this networking module in our root main.tf:

 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

provider "azurerm" {
  features {}
}

module "resource_group" {
  source   = "./modules/resource_group"
  rg_name  = "my-resource-group"
  location = "East US"
  tags = {
    environment = "dev"
    project     = "terraform-learning"
  }
}

module "networking" {
  source              = "./modules/networking"
  vnet_name           = "my-vnet"
  address_space       = ["10.0.0.0/16"]
  location            = module.resource_group.rg_location
  resource_group_name = module.resource_group.rg_name
  subnet_name         = "my-subnet"
  subnet_address_prefix = ["10.0.1.0/24"]
  tags = {
    environment = "dev"
    project     = "terraform-learning"
  }
}

output "vnet_id" {
  value = module.networking.vnet_id
}

output "subnet_id" {
  value = module.networking.subnet_id
}

Our project structure now looks like this:

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

project_root/
│
├── main.tf                 # Root configuration file
│
└── modules/
    ├── resource_group/     # Our resource group module
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    │
    └── networking/         # Our networking module
        ├── main.tf
        ├── variables.tf
        └── outputs.tf

In this root configuration, we’re using both our resource group and networking modules. Notice how we’re using the outputs from the resource group module as inputs for the networking module. This demonstrates how modules can interact with each other, allowing you to build complex, interconnected infrastructure from simpler, reusable components.

By creating these modules, we’ve encapsulated the logic for creating resource groups and networking resources. We can now reuse these modules across different projects or create multiple instances of them within the same project, promoting code reuse and consistency.

In the next section, we’ll discuss best practices for working with modules. Ready to level up your module game? Let’s go! 🚀

Module Best Practices

Now that we’ve created and used some modules, let’s explore best practices that will help you write more effective, maintainable, and reusable modules for your Azure infrastructure.

1. Naming Conventions

Consistent naming helps make your modules more intuitive and easier to use:

• Use clear, descriptive names for your modules, variables, and outputs.
• Stick to lowercase letters, numbers, and underscores for module names.
• Prefix your Azure resource names with a variable to allow customization:

1
2
3
4

resource "azurerm_virtual_network" "vnet" {
  name                = "${var.prefix}-vnet"
  # ...
}

2. Module Structure

Keep your module structure consistent and organized:

1
2
3
4
5
6
7

module_name/
│
├── main.tf         # Main resource definitions
├── variables.tf    # Input variable declarations
├── outputs.tf      # Output value declarations
├── versions.tf     # (Optional) Provider version constraints
└── README.md       # Documentation for your module

3. Documentation

Good documentation is crucial for module reusability:

• Include a README.md file in each module directory.
• Document the purpose of the module, required inputs, outputs, and usage examples.
• Use descriptive comments in your Terraform files.

Example README.md structure:

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

# Azure Networking Module

This module sets up a basic networking configuration in Azure.

## Inputs

- `vnet_name` - The name of the virtual network
- `address_space` - The address space for the VNet

## Outputs

- `vnet_id` - The ID of the created VNet

## Usage

```hcl
module "networking" {
  source       = "./modules/networking"
  vnet_name    = "my-vnet"
  address_space = ["10.0.0.0/16"]
}

4. Input Variables

Design your input variables thoughtfully:

• Use clear, descriptive names for variables.
• Provide a description for each variable.
• Use type constraints to ensure correct input.
• Provide sensible default values where appropriate.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

variable "vnet_name" {
  type        = string
  description = "The name of the virtual network"
}

variable "address_space" {
  type        = list(string)
  description = "The address space for the VNet"
  default     = ["10.0.0.0/16"]
}

5. Outputs

Carefully consider what outputs your module should provide:

• Output values that will be useful for other parts of your configuration.
• Use clear, descriptive names for outputs.
• Provide a description for each output.

1
2
3
4

output "vnet_id" {
  value       = azurerm_virtual_network.vnet.id
  description = "The ID of the created VNet"
}

6. Versioning

Version your modules to manage changes over time:

• Use semantic versioning (e.g., v1.0.0) for your modules.
• Tag releases in your version control system.
• Specify module versions in your root configuration:

1
2
3
4
5

module "networking" {
  source  = "github.com/your-repo/networking"
  version = "1.0.0"
  # ...
}

7. Keep Modules Focused

Each module should have a single, well-defined purpose:

• Avoid creating monolithic “do-everything” modules.
• Break down complex infrastructure into smaller, focused modules.

8. Handle Dependencies

Manage dependencies between resources within your module:

• Use depends_on when implicit dependencies aren’t sufficient.
• Consider using count or for_each for creating multiple similar resources.

9. Use Conditional Creation

Make your modules flexible by allowing conditional resource creation:

1
2
3
4
5

resource "azurerm_public_ip" "pip" {
  count               = var.create_public_ip ? 1 : 0
  name                = "${var.prefix}-pip"
  # ...
}

10. Test Your Modules

Implement testing for your modules:

• Use terraform plan to verify your module behaves as expected.
• Consider using tools like Terratest for automated testing.

11. Avoid Hardcoding

Avoid hardcoding Azure-specific values:

• Use variables for regions, SKUs, and other Azure-specific parameters.
• This makes your modules more flexible and reusable across different Azure environments.

By following these best practices, you’ll create modules that are easier to understand, use, and maintain. Remember, well-designed modules are key to building scalable and manageable Azure infrastructure with Terraform.

In our next section, we’ll explore how to use public modules from the Terraform Registry to further enhance our Azure infrastructure. Ready to leverage the power of the community? Let’s go! 🚀

Using Public Modules

While creating your own modules is powerful, the Terraform community, and especially Microsoft Azure, have developed a vast array of modules that you can leverage in your Azure infrastructure. Let’s explore how to use these public modules effectively, with a focus on Azure Verified Modules.

Introduction to the Terraform Registry and Azure Verified Modules

The Terraform Registry (registry.terraform.io) is a repository of publicly available Terraform modules. It’s a treasure trove of pre-built modules that can significantly speed up your infrastructure development.

Of particular interest for Azure users is the Azure Verified Modules (AVM) initiative. These modules are officially supported by Microsoft and adhere to strict standards for quality, maintenance, and best practices.

Finding Azure Modules

To find Azure-specific modules:

1. Visit the Terraform Registry website.
2. Look for modules in the “Azure” namespace, which are official Microsoft-supported modules.
3. Visit the Azure Verified Modules page for a comprehensive list of verified modules.

How to Use Azure Verified Modules

Using an Azure Verified Module is straightforward. Let’s look at an example using the Azure Virtual Network Module:

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

module "avm-res-network-virtualnetwork" {
  source  = "Azure/avm-res-network-virtualnetwork/azurerm"
  version = "0.2.4"

  address_spaces      = ["10.0.0.0/16"]
  location            = "East US"
  name                = "myVNet"
  resource_group_name = "myResourceGroup"
  subnets = {
    "subnet1" = {
      name             = "subnet1"
      address_prefixes = ["10.0.0.0/24"]
    }
    "subnet2" = {
      name             = "subnet2"
      address_prefixes = ["10.0.1.0/24"]
    }
  }
}

In this example:

• source specifies the module location in the registry.
• version pins the module to a specific version for consistency.
• The rest are input variables required by the module.

Benefits of Using Azure Verified Modules

1. Official Support: These modules are maintained by Microsoft Azure.
2. Best Practices: They implement Azure best practices and are regularly updated.
3. Consistency: They provide a consistent approach to Azure resource deployment.
4. Thorough Testing: AVMs undergo rigorous testing to ensure reliability.

Example: Using a Public Module for Azure Container Registry

Let’s use an Azure Verified Module to create an Azure Container Registry:

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

module "avm-res-containerregistry-registry" {
  source  = "Azure/avm-res-containerregistry-registry/azurerm"
  version = "0.1.0"

  name                = "myacrregistry"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
}

output "acr_id" {
  value = module.avm-res-containerregistry-registry.resource.id
}

output "acr_login_server" {
  value = module.avm-res-containerregistry-registry.resource.login_server
}

This module simplifies the process of creating an Azure Container Registry, handling details like naming rules and network configurations for you.

Considerations When Using Public Modules

While Azure Verified Modules are highly reliable, consider these points for any public module:

1. Version Pinning: Always specify a version to ensure consistency and avoid unexpected changes.
2. Understand the Module: Review the module’s documentation to understand its inputs, outputs, and any assumptions it makes.
3. Test Thoroughly: Always test modules in a non-production environment first.

Balancing Public Modules and Custom Modules

Deciding whether to use a public module or create your own depends on several factors:

• Availability: Check if an Azure Verified Module exists for your needs.
• Customization: If you need highly specific configurations, a custom module might be better.
• Company Policy: Some organizations prefer or require internally developed modules for security or compliance reasons.

Wrapping Up

Azure Verified Modules and other public modules can be a great asset in your Terraform toolkit. They can speed up development, implement best practices, and provide well-tested configurations for Azure services. Always approach them with a balance of trust and verification, and don’t be afraid to create custom modules when you need specific functionality.

In our next section, we’ll dive into some advanced module concepts, including module composition and using Terraform’s count and for_each with modules. Ready to take your module skills to the next level? Let’s go! 🚀

Advanced Module Concepts

Now that we’ve mastered the basics of Terraform modules and explored public modules, it’s time to level up our skills with some advanced concepts. These techniques will help you create more flexible, powerful, and efficient Azure infrastructure configurations.

Module Composition

Module composition is the practice of using modules within other modules. This allows you to create complex, layered infrastructures from simpler building blocks.

Let’s look at an example where we create a “web-app” module that uses both a “networking” module and a “database” module that we’ve already created:

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

project_root/
│
├── main.tf
│
└── modules/
    ├── networking/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    │
    ├── database/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    │
    └── web-app/
        ├── main.tf
        ├── variables.tf
        └── outputs.tf

In the web-app/main.tf, we might have:

 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

module "networking" {
  source               = "../networking"
  resource_group_name  = var.resource_group_name
  vnet_address_space   = var.vnet_address_space
}

module "database" {
  source               = "../database"
  resource_group_name  = var.resource_group_name
  subnet_id            = module.networking.subnet_id
}

resource "azurerm_app_service" "web_app" {
  name                = var.app_name
  location            = var.location
  resource_group_name = var.resource_group_name
  app_service_plan_id = azurerm_app_service_plan.app_plan.id

  site_config {
    dotnet_framework_version = "v4.0"
  }

  app_settings = {
    "DATABASE_URL" = module.database.connection_string
  }
}

Don’t focus too much on the details of the web-app module. The key point here is that this module is referencing other modules we’ve already created (networking and database). This composition allows us to create a complete web application environment with just a few lines in our root main.tf:

1
2
3
4
5
6
7

module "web_app" {
  source              = "./modules/web-app"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  app_name            = "my-azure-web-app"
  vnet_address_space  = ["10.0.0.0/16"]
}

As you can see, our root configuration becomes very high-level and easy to understand, hiding the complexity within the modules.

Passing Complex Data Types to Modules

Modules can accept complex data types like lists and maps as input variables. This is particularly useful for creating flexible, reusable modules.

For example, let’s create a module that sets up multiple subnets:

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

# modules/networking/variables.tf
variable "subnets" {
  type = map(object({
    address_prefixes = list(string)
    service_endpoints = list(string)
  }))
  description = "A map of subnet names to configuration"
}

# modules/networking/main.tf
resource "azurerm_subnet" "subnets" {
  for_each             = var.subnets
  name                 = each.key
  resource_group_name  = var.resource_group_name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes     = each.value.address_prefixes
  service_endpoints    = each.value.service_endpoints
}

In this example, our module accepts a complex variable subnets, which is a map of objects. Each object contains a list of address prefixes and service endpoints.

The for_each expression in the subnet resource creates a subnet for each entry in the subnets map. each.key becomes the name of the subnet, and each.value contains the configuration for that subnet.

You can then use this module like this:

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

module "network" {
  source = "./modules/networking"
  
  resource_group_name = azurerm_resource_group.main.name
  vnet_address_space  = ["10.0.0.0/16"]
  
  subnets = {
    web = {
      address_prefixes = ["10.0.1.0/24"]
      service_endpoints = ["Microsoft.Web"]
    }
    data = {
      address_prefixes = ["10.0.2.0/24"]
      service_endpoints = ["Microsoft.Sql"]
    }
  }
}

Here, we’re creating two subnets: one for web services with the Microsoft.Web service endpoint, and one for data with the Microsoft.Sql service endpoint. This approach allows for a very flexible and reusable networking module.

Using count and for_each with Modules

The count and for_each meta-arguments allow you to create multiple instances of a module.

Using count:

1
2
3
4
5
6
7

module "web_app" {
  count  = 3
  source = "./modules/web-app"
  
  name  = "web-app-${count.index + 1}"
  # ... other variables
}

This creates three instances of the web-app module, named web-app-1, web-app-2, and web-app-3.

Using for_each:

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

locals {
  apps = {
    app1 = { name = "web-app-1", size = "S1" }
    app2 = { name = "web-app-2", size = "S2" }
    app3 = { name = "web-app-3", size = "S3" }
  }
}

module "web_app" {
  for_each = local.apps
  source   = "./modules/web-app"
  
  name = each.value.name
  size = each.value.size
  # ... other variables
}

In this case, we’re creating three web apps, each with a different name and size (S1, S2, S3). This allows for more granular control over each instance of the module.

Dynamic Module Source

You can use expressions in the source argument to dynamically select a module source:

1
2
3
4
5
6
7
8
9

variable "environment" {
  type = string
}

module "network" {
  source = "./modules/network-${var.environment}"
  
  # ... module variables
}

This allows you to use different module implementations based on the environment. For example, you might have different networking configurations for development, staging, and production environments.

Conditional Module Usage

You can use the count meta-argument to conditionally use a module:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

variable "create_database" {
  type = bool
}

module "database" {
  count  = var.create_database ? 1 : 0
  source = "./modules/database"
  
  # ... module variables
}

This creates the database module only if create_database is true. It’s useful when you want to optionally include certain components in your infrastructure. For instance, you might not need a database in a development environment, but you would in production.

By mastering these advanced module concepts, you’ll be able to create highly flexible, reusable, and powerful Terraform configurations for your Azure infrastructure. In our next section, we’ll put all of this knowledge together in our grand finale project. Ready to build something amazing? Let’s go! 🚀

Grand Finale Project: Multi-Tier Azure Application

It’s time to bring everything we’ve learned together in a comprehensive, real-world project. We’re going to build a multi-tier application infrastructure on Azure using Terraform modules. This project will demonstrate how to create a scalable, modular Azure infrastructure that could support a typical web application.

Project Overview

We’ll create an infrastructure that includes:

1. Networking (Virtual Network, Subnets, Network Security Groups)
2. Compute (Azure Kubernetes Service for application hosting)
3. Database (Azure SQL Database)
4. Storage (Azure Blob Storage)

We’ll structure our project using modules to keep our code organized and reusable.

Project Structure

Here’s how we’ll organize our 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

project_root/
│
├── main.tf
├── variables.tf
├── outputs.tf
│
└── modules/
    ├── networking/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    │
    ├── aks/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    │
    ├── database/
    │   ├── main.tf
    │   ├── variables.tf
    │   └── outputs.tf
    │
    └── storage/
        ├── main.tf
        ├── variables.tf
        └── outputs.tf

Step 1: Networking Module

Let’s start with our networking module. This will set up our Virtual Network, Subnets, and Network Security Groups.

File: modules/networking/main.tf

 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

resource "azurerm_virtual_network" "vnet" {
  name                = var.vnet_name
  address_space       = var.address_space
  location            = var.location
  resource_group_name = var.resource_group_name
}

resource "azurerm_subnet" "subnet" {
  for_each             = var.subnets
  name                 = each.key
  resource_group_name  = var.resource_group_name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes     = each.value.address_prefixes
  service_endpoints    = each.value.service_endpoints
}

resource "azurerm_network_security_group" "nsg" {
  name                = "${var.vnet_name}-nsg"
  location            = var.location
  resource_group_name = var.resource_group_name

  security_rule {
    name                       = "AllowHTTP"
    priority                   = 100
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "80"
    source_address_prefix      = "*"
    destination_address_prefix = "*"
  }
}

File: modules/networking/variables.tf

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

variable "vnet_name" {
  type = string
}

variable "address_space" {
  type = list(string)
}

variable "location" {
  type = string
}

variable "resource_group_name" {
  type = string
}

variable "subnets" {
  type = map(object({
    address_prefixes = list(string)
    service_endpoints = list(string)
  }))
}

File: modules/networking/outputs.tf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

output "vnet_id" {
  value = azurerm_virtual_network.vnet.id
}

output "subnet_ids" {
  value = { for k, v in azurerm_subnet.subnet : k => v.id }
}

output "nsg_id" {
  value = azurerm_network_security_group.nsg.id
}

Step 2: AKS Module

Next, let’s create our AKS (Azure Kubernetes Service) module for our compute needs.

File: modules/aks/main.tf

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

resource "azurerm_kubernetes_cluster" "aks" {
  name                = var.cluster_name
  location            = var.location
  resource_group_name = var.resource_group_name
  dns_prefix          = var.dns_prefix

  default_node_pool {
    name       = "default"
    node_count = var.node_count
    vm_size    = var.vm_size
  }

  identity {
    type = "SystemAssigned"
  }

  network_profile {
    network_plugin = "azure"
    service_cidr   = var.service_cidr
    dns_service_ip = var.dns_service_ip
    docker_bridge_cidr = var.docker_bridge_cidr
  }
}

File: modules/aks/variables.tf

 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
37

variable "cluster_name" {
  type = string
}

variable "location" {
  type = string
}

variable "resource_group_name" {
  type = string
}

variable "dns_prefix" {
  type = string
}

variable "node_count" {
  type    = number
  default = 1
}

variable "vm_size" {
  type    = string
  default = "Standard_D2_v2"
}

variable "service_cidr" {
  type = string
}

variable "dns_service_ip" {
  type = string
}

variable "docker_bridge_cidr" {
  type = string
}

File: modules/aks/outputs.tf

1
2
3
4
5
6
7
8

output "kube_config" {
  value = azurerm_kubernetes_cluster.aks.kube_config_raw
  sensitive = true
}

output "cluster_id" {
  value = azurerm_kubernetes_cluster.aks.id
}

Step 3: Database Module

Now, let’s create our database module for Azure SQL Database.

File: modules/database/main.tf

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

resource "azurerm_sql_server" "server" {
  name                         = var.server_name
  resource_group_name          = var.resource_group_name
  location                     = var.location
  version                      = "12.0"
  administrator_login          = var.admin_username
  administrator_login_password = var.admin_password
}

resource "azurerm_sql_database" "db" {
  name                = var.db_name
  resource_group_name = var.resource_group_name
  location            = var.location
  server_name         = azurerm_sql_server.server.name
  edition             = var.db_edition
}

File: modules/database/variables.tf

 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

variable "server_name" {
  type = string
}

variable "resource_group_name" {
  type = string
}

variable "location" {
  type = string
}

variable "admin_username" {
  type = string
}

variable "admin_password" {
  type = string
}

variable "db_name" {
  type = string
}

variable "db_edition" {
  type    = string
  default = "Standard"
}

File: modules/database/outputs.tf

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

output "server_name" {
  value = azurerm_sql_server.server.name
}

output "db_name" {
  value = azurerm_sql_database.db.name
}

output "connection_string" {
  value = "Server=tcp:${azurerm_sql_server.server.fully_qualified_domain_name},1433;Initial Catalog=${azurerm_sql_database.db.name};Persist Security Info=False;User ID=${var.admin_username};Password=${var.admin_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;"
  sensitive = true
}

Step 4: Storage Module

Finally, let’s create our storage module for Azure Blob Storage.

File: modules/storage/main.tf

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

resource "azurerm_storage_account" "storage" {
  name                     = var.storage_account_name
  resource_group_name      = var.resource_group_name
  location                 = var.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

resource "azurerm_storage_container" "container" {
  name                  = var.container_name
  storage_account_name  = azurerm_storage_account.storage.name
  container_access_type = "private"
}

File: modules/storage/variables.tf

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

variable "storage_account_name" {
  type = string
}

variable "resource_group_name" {
  type = string
}

variable "location" {
  type = string
}

variable "container_name" {
  type = string
}

File: modules/storage/outputs.tf

1
2
3
4
5
6
7

output "storage_account_name" {
  value = azurerm_storage_account.storage.name
}

output "primary_blob_endpoint" {
  value = azurerm_storage_account.storage.primary_blob_endpoint
}

Step 5: Bringing It All Together

Now, let’s use these modules in our root main.tf to create our complete infrastructure:

File: main.tf

 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
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

provider "azurerm" {
  features {}
}

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

module "networking" {
  source              = "./modules/networking"
  vnet_name           = "${var.project_name}-vnet"
  address_space       = ["10.0.0.0/16"]
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  subnets = {
    aks = {
      address_prefixes = ["10.0.1.0/24"]
      service_endpoints = ["Microsoft.Sql"]
    }
    db = {
      address_prefixes = ["10.0.2.0/24"]
      service_endpoints = ["Microsoft.Sql"]
    }
  }
}

module "aks" {
  source               = "./modules/aks"
  cluster_name         = "${var.project_name}-aks"
  location             = azurerm_resource_group.rg.location
  resource_group_name  = azurerm_resource_group.rg.name
  dns_prefix           = "${var.project_name}-aks"
  service_cidr         = "10.0.3.0/24"
  dns_service_ip       = "10.0.3.10"
  docker_bridge_cidr   = "172.17.0.1/16"
}

module "database" {
  source              = "./modules/database"
  server_name         = "${var.project_name}-sqlserver"
  resource_group_name = azurerm_resource_group.rg.name
  location            = azurerm_resource_group.rg.location
  admin_username      = var.db_admin_username
  admin_password      = var.db_admin_password
  db_name             = "${var.project_name}-db"
}

module "storage" {
  source               = "./modules/storage"
  storage_account_name = "${lower(var.project_name)}storage"
  resource_group_name  = azurerm_resource_group.rg.name
  location             = azurerm_resource_group.rg.location
  container_name       = "data"
}

File: variables.tf

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

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

variable "resource_group_name" {
  type    = string
  default = "myproject-rg"
}

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

variable "db_admin_username" {
  type = string
}

variable "db_admin_password" {
  type = string
}

File: outputs.tf

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

output "aks_cluster_name" {
  value = module.aks.cluster_id
}

output "db_connection_string" {
  value     = module.database.connection_string
  sensitive = true
}

output "storage_account_name" {
  value = module.storage.storage_account_name
}

This configuration creates a complete multi-tier application infrastructure on Azure, including networking, compute (AKS), database (Azure SQL), and storage (Azure Blob Storage).

To use this configuration:

1. Ensure you have the Azure CLI installed and you’re logged in.
2. Initialize Terraform: terraform init
3. Plan your deployment: terraform plan -out=tfplan -var="db_admin_username=adminuser" -var="db_admin_password=P@ssw0rd123!"
4. Apply the configuration: terraform apply tfplan

Remember to replace the database admin username and password with secure values, and consider using Azure Key Vault to manage sensitive information in a production environment.

This project demonstrates how to use Terraform modules to create a complex, multi-tier Azure infrastructure in a modular and reusable way. By breaking down the infrastructure into modules, we’ve created a flexible and maintainable configuration that can be easily adapted for different projects or environments.

Important: When you’re done experimenting or if you no longer need the infrastructure, remember to destroy the resources to avoid unnecessary Azure costs. You can do this by running:

1

terraform destroy

This command will remove all the resources created by Terraform. Always double-check the resources that will be destroyed before confirming the action. It’s a good practice to regularly review your Azure resources and clean up any that are no longer needed.

In our next and final section, we’ll discuss some best practices for managing large-scale Terraform projects and integrating Terraform into your CI/CD pipeline. Ready for the final piece of the puzzle? Let’s go! 🚀

Best Practices for Large-Scale Terraform Projects

As we wrap up our journey through Terraform modules and Azure infrastructure, let’s explore some best practices for managing large-scale Terraform projects. These tips will help you maintain, scale, and collaborate on your Terraform configurations as your projects grow.

1. State Management in Team Environments

When working in a team, managing Terraform state becomes crucial. Here are some best practices:

• Use Remote State: Store your state file in a shared, secure location. Azure Blob Storage is an excellent option for Azure-based projects.

  1 2 3 4 5 6 7 8

  terraform { backend "azurerm" { resource_group_name = "tfstate" storage_account_name = "tfstate1234" container_name = "tfstate" key = "prod.terraform.tfstate" } }

• Use State Locking: This prevents concurrent state operations, which could lead to conflicts. Azure Blob Storage supports state locking out of the box.

• Separate State per Environment: Use different state files for different environments (dev, staging, prod) to isolate changes and reduce risk.

2. Workspace Management

Terraform workspaces can help manage multiple environments with the same configuration:

• Use workspaces to manage different environments (dev, staging, prod) or different regions.

• Combine workspaces with environment-specific variable files for maximum flexibility.

  1 2 3

  terraform workspace new prod terraform workspace select prod terraform apply -var-file=prod.tfvars

3. Code Organization

As your project grows, good code organization becomes essential:

• Use a Consistent File Structure: Stick to a standard layout for all your modules and root configurations.
• Separate Configurations: Use separate directories for different components or applications.
• Use Consistent Naming: Adopt a naming convention for your resources, variables, and outputs.

4. Version Control Best Practices

Treat your Terraform configurations like any other code:

• Use Git for version control.
• Implement a branching strategy (e.g., GitFlow) for managing changes.
• Use Pull Requests for code reviews before merging changes.

5. CI/CD Integration

Integrating Terraform into your CI/CD pipeline can greatly improve your infrastructure management:

• Automated Testing: Use tools like terraform validate and tflint in your CI pipeline to catch issues early.
• Plan in CI, Apply in CD: Run terraform plan in your CI pipeline to catch potential issues, and terraform apply in your CD pipeline to apply changes.
• Use Terraform Cloud or Azure DevOps: These platforms provide additional features for managing Terraform in a team environment.

Example Azure DevOps pipeline yaml:

 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

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: TerraformInstaller@0
  inputs:
    terraformVersion: '1.0.0'

- task: TerraformTaskV2@2
  inputs:
    provider: 'azurerm'
    command: 'init'
    backendServiceArm: 'Azure-Service-Connection'
    backendAzureRmResourceGroupName: 'tfstate'
    backendAzureRmStorageAccountName: 'tfstate1234'
    backendAzureRmContainerName: 'tfstate'
    backendAzureRmKey: 'prod.terraform.tfstate'

- task: TerraformTaskV2@2
  inputs:
    provider: 'azurerm'
    command: 'plan'
    environmentServiceNameAzureRM: 'Azure-Service-Connection'

- task: TerraformTaskV2@2
  inputs:
    provider: 'azurerm'
    command: 'apply'
    environmentServiceNameAzureRM: 'Azure-Service-Connection'
  condition: succeeded()

6. Handling Secrets and Sensitive Data

Never store sensitive data in your Terraform configurations:

• Use Azure Key Vault to store secrets and retrieve them in your Terraform configurations.
• Use environment variables or CI/CD pipeline variables for sensitive inputs.

Example of using Azure Key Vault:

1
2
3
4
5
6
7
8
9

data "azurerm_key_vault_secret" "db_password" {
  name         = "db-password"
  key_vault_id = azurerm_key_vault.example.id
}

resource "azurerm_sql_server" "example" {
  # ...
  administrator_login_password = data.azurerm_key_vault_secret.db_password.value
}

7. Tagging and Documentation

Proper tagging and documentation are crucial for managing large-scale infrastructures:

• Use tags consistently across all resources for better organization and cost management.
• Document your modules, including inputs, outputs, and usage examples.
• Keep a high-level architecture diagram updated with your Terraform-managed infrastructure.

8. Regular Maintenance

Treat your Terraform configurations as living documents:

• Regularly update your Terraform version and provider versions.
• Refactor and optimize your configurations as your infrastructure evolves.
• Regularly review and update your modules to incorporate new best practices or Azure features.

By following these best practices, you’ll be well-equipped to manage large-scale Terraform projects on Azure. Remember, the key to success with Terraform is treating your infrastructure as code - with all the best practices that come with software development.

As we conclude this series, you now have a solid foundation in Terraform, from basic concepts to advanced module usage and best practices for large-scale projects. You’re well on your way to becoming a Terraform expert! Keep experimenting, keep learning, and most importantly, have fun building amazing infrastructure on Azure with Terraform! 🚀🌟

Conclusion

Wahoo 🎉 We’ve come to the end of our epic journey through the world of Terraform modules and Azure infrastructure management. Let’s take a moment to reflect on the amazing ground we’ve covered:

1. We started by understanding what Terraform modules are and why they’re so powerful for managing Azure resources.
2. We learned how to create our own modules, from simple resource groups to complex networking setups.
3. We explored the treasure trove of Azure Verified Modules, learning how to leverage community expertise in our projects.
4. We dove into advanced module concepts, discovering how to create flexible, reusable infrastructure components.
5. In our grand finale project, we put it all together, orchestrating a multi-tier Azure application using custom modules.
6. Finally, we wrapped up with best practices for managing large-scale Terraform projects in Azure environments.

Throughout this journey, we’ve transformed from Terraform novices to module maestros, capable of composing complex Azure infrastructures with elegance and efficiency.

Key Takeaways

As you continue your Terraform adventures, keep these key points in mind:

1. Modules are Your Friends: They promote code reuse, maintain consistency, and simplify complex infrastructures.
2. Embrace Azure Verified Modules: Don’t reinvent the wheel. The Azure community has created robust, tested modules for many common scenarios.
3. Plan Your Module Structure: Thoughtful module design leads to more maintainable and scalable infrastructure code.
4. Leverage Advanced Features: Techniques like module composition and dynamic module usage can make your configurations incredibly flexible.
5. Follow Best Practices: As your projects grow, practices like proper state management, CI/CD integration, and regular maintenance become crucial.

The Road Ahead

Your Terraform journey doesn’t end here. As Azure continues to evolve and grow, so too will the ways we manage it with Terraform. Here are some areas you might explore next:

1. Policy as Code: Look into tools like Azure Policy and OPA (Open Policy Agent) for enforcing standards across your infrastructure.
2. Infrastructure Testing: Dive deeper into testing your Terraform code with tools like Terratest.
3. Custom Providers: As you become more advanced, you might even consider creating custom Terraform providers for unique needs.

Final Thoughts

Remember, Infrastructure as Code is more than just a technique – it’s a philosophy. It’s about bringing software engineering practices to infrastructure management, enabling us to create more reliable, repeatable, and manageable cloud environments.

As you continue to build and innovate on Azure with Terraform, keep experimenting, keep learning, and most importantly, have fun! The cloud’s the limit, and you now have the tools to shape it to your will.

Thank you for joining me on this Terraform adventure. Here’s to many more exciting Azure projects in your future! Kia kaha and happy Terraforming! 🚀🌟