HashiCorp Terraform is a tool for creating and managing infrastructure through code. It allows us to describe cloud and on-premises resources using easily understandable configuration files that can be versioned, reused, and shared.
With Terraform, we can establish a standardized workflow to provision and oversee our infrastructure at every stage. This includes managing fundamental elements such as computing resources, storage, networking, and more complex components like DNS entries and features offered by the software as a service (SaaS) providers.
Let's discuss how we can structure a terraform module. When structuring a Terraform module, following best practices for maintainability, reusability, and readability is important. Here is a recommended structure for organizing our Terraform module:
Root directory
Main configuration file
Variables
Outputs
Resources
Modules
Data structures
Examples
README and documentation
First, create a root directory for the module with a meaningful name that describes the purpose or functionality of the module.
Within the root directory, create a main configuration file that defines the inputs, resources, and outputs of the module. This file typically has the .tf
or .tf.json
extension.
A subdirectory named variables
is used to store variable definitions. We can define input variables in separate files within this directory, using a naming convention that reflects their purpose. For example, a variable file for AWS resources could be named aws_variables.tf
.
A subdirectory named outputs
is used to store output definitions. We can define output variables in separate files within this directory, following a similar naming convention as the variables directory. For example, an output file for AWS resources could be named aws_outputs.tf
.
A subdirectory named resources
is used to store resource configurations. Group related resources into separate files within this directory based on their functionality or purpose. For example, a file for AWS EC2 instances could be named ec2_instances.tf
, and a file for AWS S3 buckets could be named s3_buckets.tf
.
If our module uses other modules, create a subdirectory named modules
to store these dependencies. Each submodule should have its own directory with its own Terraform files and a README.md
file describing its usage and purpose.
If our module requires data from external sources, create a subdirectory named data_sources
to store the data source configurations. Separate files can be created for each data source using a naming convention that describes their purpose.
Consider creating an examples
directory that provides usage examples and demonstrates how to consume the module. These examples can be helpful for users of the module and can showcase different configurations and scenarios.
Include a README.md
file at the root level to provide an overview of the module, its purpose, and instructions on how to use it. Consider adding additional documentation files to explain the module's inputs, outputs, and usage more detailedly.
Here is a simple example that will demonstrate the use of vars.tf
, output.tf
, and main.tf
:
output filename { value = var.filename } output content { value = var.content }
Here is a recommended structure for organizing our Terraform module:
In main.tf
, resource block is:
Getting content
from variable content
present in vars.tf
file.
Getting filename
from variable filename
present in vars.tf
.
In vars.tf
, two variables are defined:
content
, which will store all the content which will store in the file.
filename
, which will store the name of the file.
In output.tf
, two outputs are defined:
content
and filename
. When Terraform applies the configuration, it will expose the value of var.filename
and var.content
as an output, which can be accessed and used elsewhere.
By following this directory structure, we can organize our Terraform module in a logical and modular manner, making it easier to manage, reuse, and maintain. This is just the beginning of what you can do with Terraform module. By utilizing outputs, variables, resources, etc., you can enhance the flexibility, integration, and reusability of your infrastructure code.
Free Resources