TerraWeek Day 5

Task 1:

• What are modules in Terraform and why do we need modules in Terraform?You already write modulesEven when you don't create a module intentionally, if you use Terraform, you are already writing a module – a so-called "root" module. Any Terraform configuration file (.tf) in a directory, even just one, forms a module.

What does a module do?

A Terraform module allows you to create logical abstraction on the top of some resource set. In other words, a module allows you to group resources together and reuse this group later, possibly many times.

Let's assume we have a virtual server with some features hosted in the cloud. What set of resources might describe that server? For example:

• the virtual machine itself, created from some image
• an attached block device of a specified size for additional storage
• a static public IP mapped to the server's virtual network interface
• a set of firewall rules to be attached to the server
• other things like another block device, additional network interface, and so on

Task 2:

Now let's assume that you need to create this server with a set of resources many times. This is where modules are really helpful – you don't want to repeat the same configuration code over and over again.

Here is an example that illustrates how our "server" module might be called. "To call a module" means to use it in the configuration file.

Here we create 5 instances of the "server" using single set of configurations (in the module):

module "server" {
    
    count         = 5
    
    source        = "./module_server"
    some_variable = some_value
}        

Module organisation: child and root

Of course, you would probably want to create more than one module. Here are some common examples:

• a network like a virtual private cloud (VPC)
• static content hosting (i.e. buckets)
• a load balancer and it's related resources
• a logging configuration
• or whatever else you consider a distinct logical component of the infrastructure

Let's say we have two different modules: a "server" module and a "network" module. The module called "network" is where we define and configure our virtual network and place servers in it:

module "server" {
    source        = "./module_server"
    some_variable = some_value
}

module "network" {  
    source              = "./module_network"
    some_other_variable = some_other_value
}        

Once we have some custom modules, we can refer to them as "child" modules. And the configuration file where we call child modules relates to the root module.

Task 3:

Module Composition

In a simple Terraform configuration with only one root module, we create a flat set of resources and use Terraform's expression syntax to describe the relationships between these resources:

resource "aws_vpc" "example" {
  cidr_block = "10.1.0.0/16"
}

resource "aws_subnet" "example" {
  vpc_id = aws_vpc.example.id

  availability_zone = "us-west-2b"
  cidr_block        = cidrsubnet(aws_vpc.example.cidr_block, 4, 1)
}
        

When we introduce module blocks, our configuration becomes hierarchical rather than flat: each module contains its own set of resources, and possibly its own child modules, which can potentially create a deep, complex tree of resource configurations.

However, in most cases we strongly recommend keeping the module tree flat, with only one level of child modules, and use a technique similar to the above of using expressions to describe the relationships between the modules:

module "network" {
  source = "./modules/aws-network"

  base_cidr_block = "10.0.0.0/8"
}

module "consul_cluster" {
  source = "./modules/aws-consul-cluster"

  vpc_id     = module.network.vpc_id
  subnet_ids = module.network.subnet_ids
}
        

We call this flat style of module usage module composition, because it takes multiple composable building-block modules and assembles them together to produce a larger system. Instead of a module embedding its dependencies, creating and managing its own copy, the module receives its dependencies from the root module, which can therefore connect the same modules in different ways to produce different results.

Module Versioning :

Module versioning allows you to specify the exact version of the charting module in your application's dependencies. This ensures that your application remains stable and unaffected by any changes introduced in subsequent versions. If you decide to upgrade to a newer version, you can do so intentionally, knowing that it might require adjustments to your code.

In situations where the same module is used across multiple environments, it's common to see that some necessary object already exists in some environments but needs to be created in other environments.

For example, this can arise in development environment scenarios: for cost reasons, certain infrastructure may be shared across multiple development environments, while in production the infrastructure is unique and managed directly by the production configuration.

Rather than trying to write a module that itself tries to detect whether something exists and create it if not, we recommend applying the dependency inversion approach: making the module accept the object it needs as an argument, via an input variable.

For ex:

data "aws_vpc" "main" {
  tags = {
    Environment = "production"
  }
}

data "aws_subnet_ids" "main" {
  vpc_id = data.aws_vpc.main.id
}

module "consul_cluster" {
  source = "./modules/aws-consul-cluster"

  vpc_id     = data.aws_vpc.main.id
  subnet_ids = data.aws_subnet_ids.main.ids
}
        

Task 4:

• What are the ways to lock Terraform module versions? Explain with code snippets.

There are several ways to lock Terraform module versions to ensure that the same module version is used consistently across different deployments or team members. Here are the common methods:

Explicit Version Constraint: You can specify an explicit version constraint in your Terraform configuration files. For example:

module "example" {
   source  = "git::https://github.com/example/repo.git?ref=v1.2.0"
 }        

In this example, the module version v1.2.0 is explicitly specified in the module source URL. This ensures that Terraform always uses that specific version of the module.

Terraform Configuration Lock File: Terraform can generate a lock file, often named terraform.lock.hcl or terraform.tf.lock.hcl, which captures the exact versions of all modules and providers used in your configuration. This file can be committed to version control, allowing you to recreate the exact infrastructure state with the specified module versions. You can generate the lock file using the terraform init command.

lock {
  version = "0.1.0"
  dependencies {
    example = {
      version = "1.2.0"
      source  = "git::https://github.com/example/module.git"
    }
  }
}        

Module Registry: If you're using a module registry service like the Terraform Registry, you can specify the module version directly in the module source.In this case, the module version 1.2.0 is specified explicitly in the version attribute. The module registry ensures that the specified version is used for the module. For example:

 module "example" {
   source  = "registry.example.com/example/repo/aws"
   version = "1.2.0"
 }        

Private Module Registries: If you're using a private module registry, you can set up access controls and permissions to manage module versions and restrict access to specific versions.

Using version locking, terraform deployments can be consistent, easy to manage and maintain. Using locking technique you can use the same version of module.

Happy Learning!!