10 Terraform File Structure Best Practices

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions.

The file structure of a Terraform project is important for two reasons:

1. Use a single file for each resource

When you have multiple files for each resource, it can be difficult to track changes and know which file needs to be updated. This is especially true when you have many resources and files.

By using a single file for each resource, you can easily see which file needs to be updated when a change is made. This makes it much easier to manage your Terraform files, and it also makes it easier for others to understand your file structure.

2. Organize files into directories by type

When you have a lot of files in your Terraform project, it can be difficult to find the one you’re looking for if they’re all stored in the same directory. If you organize them by type, it will be much easier to find the file you need. For example, you could have a directory for Terraform configuration files, another directory for Terraform state files, and another directory for Terraform modules.

Organizing your files by type also makes it easier to collaborate with others on your Terraform project. If someone needs to make a change to your Terraform configuration, they’ll know exactly where to find the file they need to edit.

Finally, organizing your files by type can help you automate parts of your Terraform workflow. For example, you could set up a script that runs Terraform fmt on all of your Terraform configuration files every time you commit changes to your version control system.

3. Create an “outputs” directory to store output variables

When you run Terraform, it will generate a lot of files in the “.terraform” directory. These files are important and should not be deleted, but they can be ignored for the most part. The only file in the “.terraform” directory that is really important is the “terraform.tfstate” file.

The “terraform.tfstate” file contains all of the information about your infrastructure that Terraform knows about. This includes things like the IDs of resources that have been created, the IP addresses of servers, etc.

If you ever need to destroy your infrastructure and start over from scratch, the “terraform.tfstate” file is what you will use. Terraform will use this file to know what resources need to be destroyed and recreated.

The “outputs” directory is where you should store any output variables that you want to save. For example, if you have a web server with an IP address, you might want to store the IP address in an output variable so you can easily access it later.

To create an “outputs” directory, simply create a new directory called “outputs” in your project’s root directory. Then, add a file called “outputs.tf” in this directory with the following contents:

output “ip” {
value = “${aws_instance.web.public_ip}”
}

This will store the value of the “public_ip” attribute of the “web” instance in an output variable called “ip”.

4. Consider using modules

Modules help you organize your code and keep your project DRY (Don’t Repeat Yourself). By creating modules, you can abstract away the details of your infrastructure so that you can reuse them across multiple projects. This is especially useful if you have common infrastructure components that are used in different environments (e.g. development, staging, and production).

Modules also make it easier to share your code with others. If you put your Terraform code in a public repository, others can easily use your modules by specifying the source when they instantiate the module.

If you decide to use modules in your project, there are a few things to keep in mind. First, each module should be self-contained and should not rely on resources defined in other modules. Second, try to limit the number of input variables for each module. Too many input variables can make a module difficult to use. Finally, make sure to document each module so that others know how to use it.

5. Avoid hard-coding values in your Terraform code

If you hard-code values in your Terraform code, then changing those values later on will require you to modify your Terraform code. This can be a problem if you need to change values frequently or if you need to share your Terraform code with others (such as when using Terraform modules).

Instead of hard-coding values in your Terraform code, it’s better to use variables. Variables allow you to specify values in a separate file (called a variable file) and reference those values in your Terraform code. This way, you can easily change values without having to modify your Terraform code.

To learn more about Terraform file structure best practices, check out our blog post: “5 Tips for Organizing Your Terraform Code”.

6. Use input variables instead of environment variables

When you use environment variables, your Terraform code is tightly coupled to the environment it’s running in. This makes it difficult to move your code around and reuse it in other environments.

On the other hand, input variables are passed into your Terraform code at runtime, so your code isn’t tied to any specific environment. This makes it much easier to reuse your code in different environments.

Plus, input variables can be overridden at runtime, so you can easily test your code in different scenarios. For example, you could override the value of an input variable to see how your code behaves in a production environment.

Overall, using input variables instead of environment variables will make your Terraform code more flexible and reusable.

7. Use the same variable names across all environments

If you use different variable names for the same value in different environments, it can be difficult to track down which value is being used where. This can lead to confusion and errors, especially when you’re working with a large number of variables.

Instead, use the same variable name for the same value across all environments. This will make it easy to see at a glance what value is being used where, and it will help prevent errors.

8. Document your variables and outputs

When you’re working with terraform, it’s important to remember that you are not the only one who will be looking at your code. Other people in your team, or even people outside of your team, may need to understand what your code is doing and why.

Documenting your variables and outputs is a great way to help others understand your code. It also helps you keep track of what your code is doing, and why.

When you’re documenting your variables and outputs, there are a few things to keep in mind:

– Make sure you document all of your variables and outputs. Don’t leave anything out.
– Be clear and concise in your documentation. Use simple language that can be understood by everyone.
– Include examples in your documentation. This will help others understand your code better.

following these best practices will help you write better terraform code, and will make it easier for others to understand and use your code.

9. Use version control

When you’re working with terraform, you’re going to have a lot of files (possibly hundreds or even thousands). Keeping track of all these files and their changes can be difficult, especially if you’re working on a team. Version control systems like Git help by allowing you to track changes to your files over time.

Not only does this make it easier to see what has changed between versions of your code, but it also makes it possible to revert back to previous versions if something goes wrong. This is extremely important when you’re dealing with infrastructure as code, because a single mistake can cause major problems.

Using version control also allows you to share your code with others easily. For example, you can use GitHub to host your code and allow others to contribute. This is a great way to collaborate on projects and ensure that everyone is using the same code base.

10. Don’t check secrets into version control

If you check secrets into version control, then anyone with access to the repository can see them. This is a bad idea for obvious reasons.

A better approach is to use Terraform’s “sensitive” type for secret data. This type marks the data as sensitive, and Terraform will redact it when displaying or logging the value.

To use the “sensitive” type, simply add the “sensitive” keyword to the variable declaration:

variable “secret” {
type = “sensitive”
default = “supersecret”
}

Now, when you run “terraform plan” or “terraform apply”, the secret value will be redacted:

Plan: 1 to add, 0 to change, 0 to destroy.

Secret values are not shown.

This is much safer than checking secrets into version control.