Gajanan
Day 70(DevOps) - Terraform Modules🚀🚀

Day 70(DevOps) - Terraform Modules🚀🚀

Gajanan Barure's photo
Gajanan Barure
·

8 min read

Table of contents

Terraform Modules

What Is a Terraform Module?

In Terraform, Modules are groups of .tf files that are kept in a different directory from the configuration as a whole. A module’s scope encompasses all of its resources. So, if the user needs information about the resources that a module creates, the module must be explicitly stated. To do this, declare an output on the module that exposes the necessary data and permits references to that output from outside the module.

  • Modules are containers for multiple resources that are used together. A module consists of a collection of .tf and/or .tf.json files kept together in a directory

  • A module can call other modules, which lets you include the child module's resources into the configuration in a concise way.

  • Modules can also be called multiple times, either within the same configuration or in separate configurations, allowing resource configurations to be packaged and re-used.

A typical module would resemble this:

. 
├── LICENSE 
├── README.md 
├── main.tf 
├── variables.tf 
├── outputs.tf

Types of Terraform Modules

With Terraform, you are most likely to come across one of three main categories of modules:

  1. Root Module

  2. Child Module

  3. Published Modules

Benefits of Module:

  • Organise Configuration: Easier to navigate, understand, and update your configuration

  • Encapsulate Configuration: Helps prevent unintended consequences

  • Re-use Configuration: Share modules that you have written with your team or the general public

  • Consistency: help to provide consistency in your configurations

e.g.for EC2 instance creation by using module

Check status by command tree:

main.tf(ec2)

provider.tf

main.tf(module)

Below file will create two instances by using below configuration file if need more modules it can be declared under module in same file.

Below is the format on how to use modules:

# Creating a AWS EC2 Instance
resource "aws_instance" "server-instance" {
  # Define number of instance
  instance_count = var.number_of_instances

  # Instance Configuration
  ami                    = var.ami
  instance_type          = var.instance_type
  subnet_id              = var.subnet_id
  vpc_security_group_ids = var.security_group

  # Instance Tagsid
  tags = {
    Name = "${var.instance_name}"
  }
}

# Server Module Variables
variable "number_of_instances" {
  description = "Number of Instances to Create"
  type        = number
  default     = 1
}

variable "instance_name" {
  description = "Instance Name"
}

variable "ami" {
  description = "AMI ID"
  default     = "ami-xxxx"
}

variable "instance_type" {
  description = "Instance Type"
}

variable "subnet_id" {
  description = "Subnet ID"
}

variable "security_group" {
  description = "Security Group"
  type        = list(any)
}

# Server Module Output
output "server_id" {
  description = "Server ID"
  value       = aws_instance.server-instance.id
}

Terms you should know:

  • resource "aws_instance" "server-instance": This line declares a new resource of type aws_instance with the name "server-instance".

  • instance_count = var.number_of_instances: This line sets the number of instances to create based on the value of the number_of_instances variable which will be defined in Server Module Variables section.

  • ami = var.ami: This line sets the ID of the Amazon Machine Image (AMI) to use for the instance based on the value of the ami variable.

  • instance_type = var.instance_type: This line sets the instance type of the instance based on the value of the instance_type variable.

  • subnet_id = var.subnet_id: This line sets the ID of the subnet where the instance will be launched based on the value of the subnet_id variable.

  • vpc_security_group_ids = var.security_group: This line sets the security group(s) that will be associated with the instance based on the value of the security_group variable.

  • tags = { Name = "${var.instance_name}" }: This line sets a tag with the key "Name" and the value of the instance_name variable on the instance.

  • subnet_id: This variable is used to set the ID of the subnet where the EC2 instance will be launched. It does not have a default value, meaning that the user must provide a value for this variable.

  • security_group: This variable is used to set the security group(s) that will be associated with the EC2 instance. It has a type of list(any) to allow the user to specify one or more security groups. It does not have a default value, meaning that the user must provide a value for this variable.

  • output "server_id": This line declares a new output named "server_id".

  • value = aws_instance.server-instance.id: This line sets the value of the output to the ID of the EC2 instance created earlier with the aws_instance resource. The format aws_instance.server-instance.id refers to the attribute id of the resource aws_instance named "server-instance".

    Write about different modules Terraform.

  • With Terraform, you are most likely to come across one of three main categories of modules:

    1. Root Module

    2. Child Module

    3. Published Modules

1. Root Module

As the name implies, this module is the root of any configuration. Every Terraform configuration consists of the root module as the main directory that works with the .tf files. You can call any number of child modules or published modules from the root module.

Calling a Module from the Root Module

# Call the server module

module "server-module" {

source = "modules/server-module"

instance_name = "test-web-server"

instance_type = "t3a.small"

subnet_id = "sub-00001"

vpc_security_group_ids = ["sg-00001"]

}

The above code block calls a “server-module,” which is stored locally and passes the required configuration options to create the ec2 instance.

2. Child Module

Any module that can be called by another module (usually the Root module) is considered a child module. A child module can be any module that originates from different locations, including;

  • Local modules defined in the local Terraform configuration.

  • The Terraform registry which stores publicly available modules that can be used by any user in their configurations.

  • Git repository consisting of the module. You can use tags or branch names to select a specific version of a module when calling a module from a git repository.

  • Generic mercurial repository.

  • HTTP URL pointing to a zip archive with the module.

  • Cloud Storage like Amazon S3 or Google Cloud Storage buckets

3.Published Modules are modules pushed to a private or public repository. Terraform registry is the primary public repository. It hosts freely-accessible modules that can be used by anyone within their configurations. Terraform will automatically download the necessary modules from the registry when the appropriate source and version are defined in the module block.

Difference between Root Module and Child Module.

  • A Terraform module (usually the root module of a configuration) can call other modules to include their resources into the configuration. A module that has been called by another module is often referred to as a child module.

  • A root module is the top-level module of a Terraform configuration. It serves as the entry point for your entire Terraform configuration and typically includes your provider configuration and any variables that are needed to define your infrastructure resources. A root module is responsible for initializing Terraform, configuring providers, and declaring resources.

    On the other hand, a child module is a sub-module that is nested within the root module or another child module. It is used to group related resources and configurations together for easier management. A child module is typically created to encapsulate a set of resources that perform a specific function. Child modules are reusable components that can be used in multiple root modules.

  • Child modules can be defined within a root module using a module block, which specifies the source of the module and any input variables that need to be set. The source can be a local file path or a remote location, such as a version control system or a Terraform Module Registry.

  • Another difference between root modules and child modules is their visibility of variables. A root module can declare and reference variables that are visible to all child modules, while a child module can declare and reference

  • variables that are only visible within that module.

    Is modules and Namespaces are same? Justify your answer for both Yes/No

No, modules and namespaces are not the same concept, although they may share some similarities in certain contexts.

A module in Terraform is a self-contained unit of infrastructure code that encapsulates a set of related resources and can be reused across multiple configurations. Modules help to promote code reuse, modularity, and abstraction in Terraform, allowing users to manage complex infrastructures more easily.

On the other hand, a namespace is a way of organizing names or identifiers in a way that avoids naming conflicts. Namespaces are commonly used in programming to avoid naming conflicts between different modules, functions, or variables. They provide a way to group related names together under a common prefix or label.

While both modules and namespaces are used for organization and abstraction, they serve different purposes in different contexts. Modules in Terraform are used to organize and reuse infrastructure code, while namespaces are used to organize and avoid naming conflicts between different identifiers in programming.

On the other hand:

Yes, they can be considered similar in certain contexts:

  1. Namespace-like behaviour: When using modules within Terraform, there is a level of namespace-like behaviour that allows for logical separation and organization of resources. Each module can have its own set of input variables and output values, providing a degree of isolation and encapsulation.

  2. Reusability and abstraction: Both modules and namespaces facilitate reusability and abstraction. Namespaces help prevent naming conflicts by providing a unique context or scope for identifiers, while modules enable code reuse and encapsulation of infrastructure components.

linkdin:https://www.linkedin.com/in/gajanan-barure-7351a4140

***Happy Learning :)***✌✌

Keep learning,Keep growing🎇🎇

Thank you for reading!! Hope you find this helpful.

#day73#90daysofdevops#devopscommunity#

Shubham Londhe

TerraformAWS
Â