Tuesday, 31 May 2022

Terraform Modules


Terraform considers every .tf file in configuration directory as configuration file. This means that we can define all resources in a single .tf file or divide them into multiple .tf files. 
In practice, there can be hundreds of resources and both options above prevent reusability. 

Terraform module is any configuration directory which contains configuration files.

A module where we run Terraform commands is called a root module.

To include a module A (in directory A) in a configuration file in module B (in directory B) we can do the following:


where ../my-projects/B/main.tf:
module "project-B" {
    source = "../A"
Module A is a child module of module B. project-B is the logical name of the module. source is a a required argument in module block. Its value is a relative or an absolute path to the child directory. 

In practice, all reusable modules should be stored in a modules directory, grouped by their projects:

This example shows the project outline and configuration for provisioning resources for application that needs to be deployed in various AWS regions.
resource "aws_instance" "my_app_server" {
    ami = var.ami
    instance_type = "t2.medium" 
    tags = {
        Name = "${var.app_region}-my-app-server"
    depends_on= [
resource "aws_s3_bucket" "products_data" {
    bucket = "${var.app_region}-${var.bucket}"

resource "aws_dynamodb_table" "orders_db" {
    name = "orders_data" 
    billing_mode = "PAY_PER_REQUEST"
    hash_key = "OrderID"
    attribute {
        name = "OrderID" 
        type = "N"

variable "app_region" {
    type = string

variable "bucket" {
    default = "product-manuals"

variable "ami" {
    type = string

If we want to deploy this infrastructure stack to e.g. eu-west-1 region (Ireland) we can create a directory ../my-projects/my-app-ie/ and in it:
provider "aws" {
    region = "eu-west-1"
module "my_app_ie" {
    source = "../modules/my-app"
    app_region = "eu-west-1"
    ami = "ami-01234567890"
We can see that there are only two variables that differentiate deployment to each region. To provision this infrastructure stack in this region we just need to cd into ../my-projects/my-app-ie/ and execute:
$ terraform init
$ terraform apply

If we want to deploy it in e.g. Brasil, we'll have:
provider "aws" {
    region = "sa-east-1"

module "my_app_br" {
    source = "../modules/my-app"
    app_region = "sa-east-1"
    ami = "ami-3456789012"

Using modules from the public registry

Apart from provider plugins, Terraform registry also contains modules:

Modules are grouped by the provider for which they are created. There are two types of modules:

  • verified - tested and maintained by Hashicorp
  • community - not validated by Hashicorp
Example of verified module: AWS module security-group, used to create EC2-VPC security groups on AWS. 

To use it in our own configuration we can first copy-paste code snippet which can be found under Provision Instructions section:

module "security-group" {
  source  = "terraform-aws-modules/security-group/aws"
  version = "4.9.0"
  # insert the 3 required variables here

module security-group has ssh submodule which can be used to create predefined security groups like this one which allows inbound SSH:

module "security-group_ssh" {
    source  = "terraform-aws-modules/security-group/aws//modules/ssh"
    version = "4.9.0"
    # insert the 2 required variables here
    vpc_id = "vpc-0123456789" 
    ingress_cidr_blocks = [ "" ]
    name = "ssh-access"
terraform get only downloads module from the registry:
$ terraform get

When using 3rd party modules, terraform apply might be provisioning additional resources (on top of those we explicitly add to the configuration), as per module's configuration.

No comments: