Introduction:
One great addition to Terraform is Terragrunt, which helps with handling redundant code and managing many environments. By removing redundancy and preserving the dryness of Terraform code, Terragrunt by “gruntwork” guarantees efficiency in infrastructure code maintenance as projects grow. We examine Terragrunt’s installation, unique features, and useful applications for cloud infrastructure provisioning in this investigation.
Let’s begin!
What is Terragrunt?
Terragrunt is an additional wrapper that is built on top of the Terraform. Terraform is a great Infrastructure as a Code tool for managing your cloud infrastructure. But as the project size grows, we may have multiple environments (Development, Testing, Staging, Production, etc..) to manage.
If we are managing multiple environments, then we may face issues like
- Redundancy of code – Multiple copies of the same code for each environment.
- Manual update of code – If there are the same variables that are being used for all the environments then you have to remember and manually update each variable.
Terragrunt by “grunt work” was built to improve the shortcomings around the Terraform for effectively managing the infrastructure code so that developers can use the same code without any kind of duplication by keeping the Terraform code dry.
We write the Terragrunt configuration in the “terragrunt.hcl” file.
Commands:
terragrunt init
terragrunt plan
terragrunt apply
terragrunt output
terragrunt destroy.
Note: Terragrunt will forward almost all commands, arguments, and options directly to Terraform, but based on the settings in your terragrunt.hcl file.
Installation
Before installing Terragrunt we must complete one pre-requisite by installing Terraform because Terragrunt is just a wrapper around Terraform.
- First, install the Terraform:
#sudo yum install -y yum-utils shadow-utils
#https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo
#sudo yum -y install terraform
- Manually download the Terragrunt Binary.
- Goto GitHub releases pages of “gruntwork-io/terragrunt” and download the binary based on the operating system of your choice.
- link: https://github.com/gruntwork-io/terragrunt/releases.
- Rename the downloaded binary file to terragrunt.
$ mv terragrunt_linux_amd64 terragrunt
- Change the binary file permission to make it executable.
$chmod u+x terragrunt
- Move the binary file to /usr/local/bin
$ sudo mv terragrunt /usr/local/bin/terragrunt
Verify the terragrunt installation
$ terragrunt --version
Features of Terragrunt
Terragrunt helped us to
1. Keep our backend configuration DRY
2. Keep our provider configuration DRY
3. Keep our Terraform CLI arguments DRY
Keep our backend configuration DRY.
Terragrunt allows us to keep our backend configuration DRY (“Don’t Repeat Yourself”) by defining it once in a root location and inheriting that configuration in all child modules.
Workspaces (directory) --- terragrunt.hcl | | |____ dev | |--- ec2 - terragrunt.hcl | |--- vpc - terragrunt.hcl | | |____Prod |--- ec2 - terragrunt.hcl |--- vpc - terragrunt.hcl
Here we define our backend configuration just once in the root terragrunt.hcl file (in the Workspaces directory).
terragrunt.hcl file looks like this:
- Path_relative_to_include(): is a built-in function that will automatically set the key to the relative path between the root terragrunt.hcl file and the child module.
- The “generate” attribute is used to inform Terragrunt to generate the Terraform code for configuring the backend.
Finally, we updated the child module terragrunt.hcl files to tell them to include the configuration from the root terragrunt.hcl.
we add the following piece of code in every child module terragrunt.hcl file.
Keep our provider configuration DRY
In the root terragrunt.hcl file, we can define the provider configuration using the generate block:
- This instructs Terragrunt to create the provider.tf file in the working directory (where Terragrunt calls Terraform) before it calls any of the Terraform commands (e.g., plan, apply, validate, etc.)
Note: Both provider. tf and backend.tf files will be created in the “.terragrunt.cache” directory.
Keep our CLI arguments DRY.
In Terraform we use “-var-file” to specify variable files for the commands plan and apply.
ex : $ terraform apply -var-file=../../common.tfvars -var-file=../region.tfvars
Having to remember these -var-file arguments every time can be tedious and error-prone.
Terragrunt allows you to keep your CLI arguments DRY by defining those arguments as code in your child module terragrunt.hcl configuration.
How to use Terragrunt for provisioning the cloud infrastructure?
Note:
- Terragrunt never recommends duplication of code.
- Terragrunt heavily relies on modules, so that we can keep our code dry without polluting with the duplicate code.
- To use Terragrunt we need to know the modules which we are going to use in our project.
Now we are going to set up an EC2 instance on the DEV environment using Terragrunt.
- Here are a few starting lines for our
terrgrunt.hcl
where we need to mention the reference of EC2 Module –
#terraform { source = "tfr:///terraform-aws-modules/ec2-instance/aws? version=4.0.0" }
- We are referring to the remote EC2 Module with –
#Source URI - "tfr:///terraform-aws-modules/ec2-instance/aws?version=4.0.0"
- Next, we need to define the configuration of the input because, for each Terragrunt implementation, we need to provide some mandatory inputs. So, for our case of EC2, we will need the following mandatory parameters – ami, Tags, instance_type
- Here is my final terragrunt.hcl file in the ec2 folder.
Now we can run the following commands.
- terragrunt init
- terragrunt plan
- terragrunt apply
- terragrunt output
- terragrunt destroy.
To create VPC: terragrunt.hcl
Conclusion:
Terragrunt simplifies CLI arguments, backend and provider setups, and transforms the Terraform experience. Its focus on code dryness and modularity makes it an effective tool for smoothly orchestrating cloud infrastructure. It is clear from exploring Terragrunt’s capabilities that it is a major contributor to workflow optimisation for Infrastructure as Code for scalable and effective cloud installations.