Terraform Best Practices — Limit resources in your project
When starting out with Terraform it’s hard to know what is considered ‘best practice’ in a number of areas.
This post is the seventh in the series which focuses on points 7 and 8 in the list, ‘Fewer resources in a project are easier and faster to work with’, and ‘Limit resources in the project to reduce the blast radius’.
- Use a consistent file structure across your projects.
- Use modules wherever possible.
- Use a consistent naming convention.
- Use a consistent format and style.
- Hold your state file remotely, not on your local machine.
- Avoid hardcoding variables.
- Fewer resources in a project are easier and faster to work with.
- Limit resources in the project to reduce the blast radius.
- Test your code.
Reasons to limit the number of resources and how to reduce your ‘blast radius’
Separating parts of your Terraform project is recommended best practice, as any bugs, errors or problems will then be restricted to one area, making remediation easier.
It is recommended to separate code by environment, and also by component. For example you might want to separate your networking from your databases. In addition to this you would separate Production, Staging, Development environments.
Changes to code can be deployed independently, then checked and tested, before deploying new code to other areas of the infrastructure. This approach is referred to as ‘reducing the blast radius’, meaning that any issues are contained to a particular area.
Each section of infrastructure would also have its own state file, so any problems or corruption of the state file itself would be restricted to that area.
Problems with this approach include the duplication of config, and increased complexity of operations and management, as terraform will need to be run from each sub directory. Having multiple state files is something Terragrunt aims to make less painless, although it has benefits, think hard before bringing a wrapper into your projects as it brings another layer of overhead. I’ll hope to expand on using Terragrunt in another post.
As well as achieving isolation by modifying the project or file structure, you could also achieve this using Terraform workspaces to store your state files in multiple, separate, named workspaces, all within the same remote storage location if desired.
It is also recommended that any changesets to code are minimal, for example deploying a new VNET in Azure may be one changeset. Deploying a VPN connecting to the VNET may be another changeset. Taking an incremental approach to commits limits the potential issues.
Limiting the number of resources in a project also has be the benefits of being easier to read and understand the code.
Lastly, when Terraform refreshes its state file, because the project has been split by component and environment, it has fewer resources to scan and therefore is quicker to work with. This is less of a problem for large infrastructures since 0.14 Terraform as improvements have been made (e.g. to show the diff, and scanning is quicker).
Want more Terraform content? Check out my other articles on Terraform here!
Cheers! 🍻
Further reading:
