30days of Terraform

Advanced Terraform Module Usage: Versioning, Nesting, and Reuse Across Environments

Dwayne Chima's photo
Dwayne Chima
·

4 min read

Today we'll look into advanced strategies for working with Terraform modules. We'll go over how to handle module versioning, layer modules for more complicated use cases, and reuse modules in many contexts such as development, staging, and production. By the conclusion of this tutorial, you'll understand how to manage modules efficiently in a dynamic infrastructure architecture.

Terraform Module Versioning

Module versioning is essential when working with infrastructure as code. As your project progresses, you'll want to make sure that modifications to your modules do not abruptly disrupt current deployments. Terraform allows you to easily define which version of a module to use in your setup.

Why Versioning Matters

  • Consistency: When you specify a version, you ensure that the module behaves consistently across environments and deployments.

  • Compatibility: Versioning allows you to lock specific features and changes in the module, helping avoid unexpected changes that could disrupt your infrastructure.

  • Reproducibility: If you need to reproduce an environment at a later time, versioning ensures you're using the same version of the module you originally used.

You may version a module by using the version parameter in your module source settings. Here's an example of how to specify a version:

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "1.0.0"
}

By specifying the version, you ensure that the infrastructure will always be created using the version of the module that matches the configuration, providing stability and predictability.

Nesting Terraform Modules

Nested modules help to arrange your infrastructure more effectively by combining similar resources into logical pieces. For example, you may build a VPC module with submodules for subnets, route tables, and security groups. This method makes your configuration more structured and modular.

Benefits of Nesting

  • Simplification: Breaking down complex configurations into smaller, manageable components.

  • Code Reusability: By reusing the same submodules across different projects, you avoid duplicating code and reduce maintenance.

  • Scalability: As your infrastructure grows, you can scale each module independently, allowing for better control and adaptability.

module "vpc" {
  source = "./modules/vpc"
}

module "subnet" {
  source = "./modules/vpc/subnet"
  vpc_id = module.vpc.vpc_id
}

Versioning Your Own Terraform Modules

To version your own module, you can follow semantic versioning (SemVer) practices. This includes updating the version number whenever you introduce changes.

For example:

  • Major Version: Change when you introduce breaking changes.

  • Minor Version: Change when you add new features without breaking existing functionality.

  • Patch Version: Change for bug fixes or minor improvements.

Once you've determined how your module should be versioned, you can host it on GitHub. GitHub serves as an excellent platform to share, manage, and version control your Terraform modules. Here's how to do it:

Hosting Your Module on GitHub

  1. Create a GitHub Repository: Start by creating a new repository on GitHub where your Terraform module will live. You can name it according to the functionality it provides, for example, terraform-vpc-module.

  2. Commit Your Module Code: After creating the repository, commit your module code to it. You can structure the module in the same way you would in your local setup, with files such as main.tf, variables.tf, and outputs.tf.

  3. Tagging the Version: Once your module is hosted on GitHub, it's important to tag your releases with the appropriate version numbers. Use Git's tag feature to mark stable versions of your module.

    For example, to tag version v1.0.0, use the following commands:

     git tag v1.0.0
 git push origin v1.0.0

Referencing Your Versioned Module in Terraform

Now that your module is hosted on GitHub and versioned, you can easily reference it in other Terraform configurations. To do this, use the source argument in your module block and point it to your GitHub repository. You can also specify the version of the module you want to use.

Example: Using a Versioned Module in Terraform

module "vpc" {
  source  = "git::https://github.com/yourusername/terraform-vpc-module.git//vpc?ref=v1.0.0"
}

Using Different Versions for Different Environments

You may want to use different versions of your module for different environments. Here's how you can manage that:

Development Environment (Using Version v1.0.0)

module "vpc_dev" {
  source  = "git::https://github.com/yourusername/terraform-vpc-module.git//vpc?ref=v1.0.0"
}

Production Environment (Using Version v2.0.0)

module "vpc_prod" {
  source  = "git::https://github.com/yourusername/terraform-vpc-module.git//vpc?ref=v2.0.0"
}

By doing this, you can test new features in the development environment using version v1.0.0 while ensuring stability in production with version v2.0.0.

Conclusion

Versioning your Terraform module and putting it on GitHub is an organized, scalable way to manage your infrastructure code. Using Git tags for versioning allows you to monitor changes and ensure that different environments utilize the proper version of your module. This allows for a more robust and consistent deployment of infrastructure with Terraform, which improves both workflow and project cooperation.

TutorialAWS