Building Reusable Terraform Modules

1. What are Terraform Modules and Why Use Them?

At a high level, a Terraform module is a container for multiple resources that are used together. If you have a background in programming, the easiest way to think about a module is as a function. It encapsulates a set of logic, accepts input parameters to customize its behavior, and returns values.

In every Terraform configuration you've written, you've already been using a module: the root module. This is simply the main set of .tf files in your working directory. Today, we're focusing on creating child modules, which are separate, reusable components that your root module can call.

The primary benefits of using modules are:

• Reusability: Define a set of infrastructure once (e.g., a secure S3 bucket or a web server cluster) and reuse it multiple times across different environments (dev, staging, prod) or projects.
• Maintainability: When you need to update a piece of infrastructure, you only need to change it in one place—the module. All instances that use the module will inherit the change.
• Abstraction: Modules hide the complexity of the underlying resources. A consumer of your module only needs to know what inputs it requires, not the intricate details of how it's implemented.

To begin, let's explore the core idea of refactoring existing code into a module.

2. The Anatomy of a Module

A well-structured Terraform module follows a standard file layout to make it easy for others to understand and use.

The three most important files in a module are:

• main.tf: Contains the core resource blocks that the module manages (e.g., aws_instance, aws_s3_bucket).
• variables.tf: Defines the input variables for the module. This is the "API" of your module, specifying what can be configured from the outside.
• outputs.tf: Defines the output values that the module exposes. These are the "return values" that the calling module can use.

Let's watch a video that demonstrates creating this structure and populating it with code.

3. Inputs, Outputs, and Locals: The Module's Interface

Modules communicate with the outside world through input and output variables. For internal calculations and to keep your code clean, you use local values. Let's examine each of these components.

Input Variables: Parameterizing Your Module

Input variables make your module flexible. Instead of hardcoding values like instance types or names, you define variables that can be passed in when the module is called.

This allows you to use the same module to create a t2.micro instance in your dev environment and a m5.large instance in prod.

Here’s a quick example. Inside your module's variables.tf:

# modules/ec2-instance/variables.tf
variable "instance_type" {
  description = "The EC2 instance type."
  type        = string
  default     = "t2.micro"
}

Inside your module's main.tf:

# modules/ec2-instance/main.tf
resource "aws_instance" "this" {
  ami           = "ami-0c55b159cbfafe1f0" # Example AMI
  instance_type = var.instance_type



  # ...
}

And in your root module's main.tf:

# main.tf
module "web_server" {
  source = "./modules/ec2-instance"

  instance_type = "t3.small" # Overrides the default
}

Output Values: Exposing Resource Attributes

Once your module creates resources, you often need to access their attributes (like an instance ID or an S3 bucket's ARN) from your root module. This is done with output values.

Example. Inside your module's outputs.tf:

# modules/ec2-instance/outputs.tf
output "instance_id" {
  description = "The ID of the created EC2 instance."
  value       = aws_instance.this.id
}

And in your root module's outputs.tf to pass it through:

# outputs.tf
output "web_server_instance_id" {
  description = "The ID of the web server instance."
  value       = module.web_server.instance_id
}

Local Values: Internal Helper Variables

Sometimes you need to create a complex value or use a value multiple times within a module, but you don't want to expose it as a configurable input. This is the perfect use case for locals. They help keep your code DRY and improve readability by giving a name to a complex expression.

Example. Inside your module's main.tf:

# modules/ec2-instance/main.tf

locals {



  # Create a common set of tags to be applied to all resources in the module
  common_tags = {
    ManagedBy = "Terraform"
    Project   = var.project_name
  }
}

resource "aws_instance" "this" {



  # ...
  tags = local.common_tags
}

4. Best Practices and Gotchas

When writing modules, a few best practices will make them more powerful and easier to use.

Key takeaways from this section:

1. File Paths: When a module needs to read a local file (e.g., a user data script for an EC2 instance), always use the path.module variable to construct the path. This ensures the path is relative to the module's directory, not the root directory.

   user_data = templatefile("${path.module}/user-data.sh", {})
   

2. Inline Blocks vs. Separate Resources: For resources like security groups, you can define rules either as inline ingress/egress blocks or as separate aws_security_group_rule resources. In modules, always prefer separate resources. This makes your module more flexible, as it allows the consumer of the module to add additional rules to the security group from outside the module.

5. Behavioral Interview Preparation

Being able to discuss how you've used modularity to improve infrastructure code is a key competency for a DevOps role.

Interview Question: "Describe a time you improved the reusability and maintainability of your team's infrastructure code. What was the impact?"

Here's how you could structure an answer using the STAR method:

• Situation: "In a previous project, our team was managing infrastructure for dev, staging, and production environments. We noticed significant code duplication in our Terraform repository, especially for common resources like creating EC2 instances for our application servers. Each environment had nearly identical code blocks, with only minor differences in instance sizes, tags, and AMI IDs. This made updates tedious and error-prone."
• Task: "My objective was to refactor this duplicated code to improve maintainability, enforce consistency, and reduce the risk of configuration drift between our environments."
• Action: "I designed and implemented a reusable Terraform module for our application server. The module encapsulated the logic for creating an aws_instance, its associated aws_security_group, and an IAM instance profile. I parameterized the module using input variables for things like instance_type, ami_id, environment, and subnet_id. Crucially, I used a locals block inside the module to generate a consistent naming scheme based on the environment variable. The module then exposed the instance's ID and private IP as output values. After developing the module, I refactored our dev, staging, and prod configurations to simply call this one module, passing in the environment-specific variables."
• Result: "This effort reduced our EC2-related Terraform code by over 70%. It made our configurations much cleaner and easier to read. The biggest impact was on maintainability; when we needed to update our security group rules, we only had to change it in the module, and the change was safely propagated to all environments on the next apply. This not only saved time but also significantly increased the reliability of our deployments."

Conclusion

You now have the knowledge to create powerful, reusable infrastructure components with Terraform. By encapsulating logic into modules, you can build complex systems from simple, composable, and testable building blocks.

Key Takeaways:

• Modules are Terraform's primary tool for creating reusable and maintainable infrastructure code.
• A standard module consists of main.tf, variables.tf (for inputs), and outputs.tf (for return values).
• Input variables define the configurable API of your module.
• Output values expose resource attributes to the calling configuration.
• Local values are used for internal expressions and logic to keep your code DRY.

In our next lesson, we will put these modules to practical use. We'll learn how to use Terraform workspaces and directory structures to manage multiple environments (dev, staging, prod), a crucial pattern for any real-world project.