Been a while, old friend..!

So recently I decided to refactor my Terraform code (did some improvements, eg. the possibility to dynamically add 0..n number of data disks of various sizes to the template). In the process, I came across Terragrunt. So what does a curious IT guy do when finds a new toy? Dives in!

This is the repo structure

(1) this is the module folder; there are currently two modules:

  • one for tags (as I create tags and categories to mark the deployments made with Terraform
  • and the other is for the VM-s I deploy on vSphere

(2) I have created a prod and a dev folder for the two types of workloads

(3) this is for example the prod_dc folder, where I have deployed 2x domain controllers

(4) and there are a few common files, which contain the things that are global

these are needed in order to connect to the vSphere

An example

Let’s look at a simpler resource deployment, such as a tag with a category

the tags module in the repo

These are the 3x files in the module. They dictate, what resource we will create, what variable parameters it will have, and what outputs we will get out from the module.

enter Terragrunt – repo

So far this was just Terraform. But since I do not want to duplicate the module elements each time I run the script, I create a .hcl file, where I just refer to the module, load the common .hcl (in order to connect to vSphere), and input the variables. The above is for production, but a similar file is in the dev/dev_tags folder too, where the inputs are prefixed with development rather than production.

Lets talk about VM-s

While it might not be super useful for a simple thing like a tag, as you most likely not going to create many categories and tags (I sure won’t plan to), the same process is much more useful for VM-s. As in the case of a VM, it would be much more duplication to create a,, and .tfvars for each VM set…

Instead of copying all of these…

…I only have one set.
Then I just refer to the module and provide inputs for the variables.

It is only needed to copy and update the .hcl file for a new deployment. Of course, you also need to update the module reference too, but still only need to edit this .hcl, if you move between prod and dev environments. The actual module files should not be edited.

Next steps

I am still to move the module folder to a separate Github repo and let Terragrunt check it out for subsequent runs. But for the shake of simplicity, they are still mono-repo


Now I know my structure might not be perfect, and seasoned DevOps personnel probably even frown upon it, but it is still a work-in-progress. And given that a week ago I did not have much of an idea how Terragrunt works, I might even consider this a small achievement in my devops journey!