Have one simpleinfra IaC solution

Right now we both have terragrunt and terraform. This is due to a migration to terragrunt that was not finished.

Pain points of having two tools

• having to deal with two tools depending on the project, which makes scripting harder and adds cognitive load
• having duplicated modules. Eg in the modules directories we have common duplicated modules, such as bastion, ecs-task, and so on. Maintaining copy pasted code is painful. See:
  • Terraform: https://github.com/rust-lang/simpleinfra/tree/master/terraform/shared/modules
  • Terragrunt: https://github.com/rust-lang/simpleinfra/tree/master/terragrunt/modules

Pain points of terragrunt

Finishing the migration to terragrunt would be one solution (use terragrunt for everything), but our terragrunt setup assumes that we have must use aws to keep the state, which is not suitable for projects deployed on other cloud providers, where it would make sense to have the state there, eg https://github.com/rust-lang/simpleinfra/tree/master/terraform/assets-backup-prod

Also, it's a wrapper of terraform, so if we can automate our IaC with only terraform we remove one layer of abstraction.

Deploying from the cloud

Running terraform from the cloud could be safer then deploying locally because we all run software that could compromise our laptop (npm and crates-io packages, vscode with extensions installed).

The evaluation of the tool should also keep in mind that we want to run plan and apply from the cloud at some point, instead of using our laptops.

Solutions

Deploying from GitHub Actions

do we trust Github Actions to deploy infrastructure?

Deploying from AWS itself

• there's aws cloudshell where we can ssh into and deploy from there
• we could have the AMI that refreshes (it restarts every X hours)
• we could have a VM in every AWS account, and an account that refreshes that VMs with the AMIs.

Con:

• we pay an EC2 for every aws account

What do to

I would love to:

• understand why we are using terragrunt (what feature was terraform missing)
• understand if in these years (after we decided to migrate to terragrunt) these features are available in terraform or in other tools (such as opentofu) and evaluate the tool that works best for us.
• take a decision and migrate our codebase to use one tool only (either terragrunt or terraform or whatever else).

Compare the duplicated modules under terraform/shared/modules and terragrunt/modules, then review the terraform/assets-backup-prod setup and the listed cloud deployment options. Investigate why terragrunt was adopted and whether Terraform or other tools now cover those needs. Done means choosing one IaC approach, documenting the decision, and migrating the codebase accordingly.