Refactor Terraform Repository to Modular structure

Image Credits: Cloudzero

Introduction

Most of the organizations when they start working on terraform to build cloud resources, they usually go with the traditional approach. Where all resource configurations are specified in a single directory. So with the traditional monolithic approach, it becomes very difficult to manage the codebase as it grows. As per best practice given by HashiCorp for production workloads terraform reusable modular structure should be used to build infrastructure.

Now there are two ways from which code can be refactored into DRY modules.

1. Terraform state mv command

Let’s understand the first approach, With the state mv command we will be making changes in terraform state file to move resource block to the modular structure.

e.g.

terraform state mv packet_device.worker module.worker.packet_device.worker

When your workload running in production through CI/CD pipeline you don’t want to make changes manually by running the state mv command to refactor the code, A small mistake can lead to losing track of terraform managed resources, which can eventually compromise the security of our operations. So we have to be very careful while making changes to the state file.

2. Moved block

Now let’s talk about the Second approach, Moved block feature recently released with terraform v1.1 will also be used for refactoring the terraform code.

Terraform has brought one of the best features to refactor the code by simply providing Moved block in your code where we can easily move from the traditional single directory structure to the DRY Module structure.

Let me give you an example,

Here we have deployed a single Azure resource group containing one virtual network and one subnet in it.

Now we want to move it to the following modular structure.

¦  +-- RG
¦  ¦ +-- main.tf
¦  ¦ +-- output.tf
¦  ¦ +-- variables.tf
¦  +-- VNET
¦  ¦ +-- main.tf
¦  ¦ +-- output.tf
¦  ¦ +-- variables.tf
+-- main.tf
+-- output.tf
+-- variables.tf
+-- README.md

We will prepare the Modular terraform code with the same configuration along with “Moved Block”. Now we need to comment out all existing code.

When we run again the terraform plan command will see no changes are required.

After verifying we can run terraform apply command and state file will be updated with modular resource configurations.

With state list command we can see the updated information in the state file.

Now the best thing is after migrating to the modular structure, we can remove the Moved block and existing terraform code.

Conclusion

Here we learn that even if the organization does not follow core best practices of Terraform, they can still walk towards achieving an efficient and consistent result in the future. If you have any feedback or suggestions you can ask in the comments.

Full code is available on github :- github.com/ajinkya101/tf-move.git

You can connect me @Ajinkya Bhabal | LinkedIn

Reference links

Structuring HashiCorp Terraform Configuration for Production

Refactoring | Terraform by HashiCorp

Join FAUN: Website 💻|Podcast 🎙️|Twitter 🐦|Facebook 👥|Instagram 📷|Facebook Group 🗣️|Linkedin Group 💬| Slack 📱|Cloud Native News 📰|More.

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇