In this article we discuss how the basics of writing organized Terraform infrastructure configuration.

Specifying Terraform’s Configuration

We recommend keeping a given Terraform module’s requirements within their own versions.tf file. Within versions.tf, you can write a terraform block which includes the following key components:

– The Terraform version that you will be using via the required_version argument.

– The required Terraform providers and their respective versions.

– The Terraform state backend block configuration. This is where your remote backend is configured or if you are using Terraform cloud, the cloud block is configured.

Handling Variables: Inputs and Outputs

Variables are a key component of any Terraform code that you write. It allows us to make repeatable Terraform modules, pass secrets in through secure mechanisms as opposed to storing values as plan text, and get relevant outputs from Terraform executions. We cover variable usage and syntax in this article. For more on how to pass variables into your Terraform workflow, please see our discussion here.

Input variables

Input variables should be stored in a variables.tf file within your Terraform modules. Variables are Terraform blocks and these variable’s values can be referenced within resource blocks. A very basic example (note, with best practices and larger configuration footprints, this would be split into separate .tf files):

Output Variables

Output variables should be stored in an outputs.tf file within your Terraform modules. Outputs are Terraform blocks and they reference values that (generally) come from resource blocks within the module. A very basic example (again, with best practices and larger configuration footprints, this would be split into separate .tf files):

Writing Resources

Terraform resources are the meat of any Terraform configuration. They are what actually corresponds to remote cloud resources. All other pieces we have gone over are simply necessary scaffolding for being able to write and then create new resources with Terraform.

A resource is defined via an individual HCL blocks. The exact syntax within these blocks can vary greatly by resource type and provider, but the general structure is the same.

In general, all of our resources should live within the a main.tf file. If we find that main.tf file is getting quite large, we can split up and bundle multiple resources into a separate Terraform module; modules make Terraform easier to read, more consice, and more modular. You may have noticed we reference modules a lot in this post. This is because even if not explicitly declared as a separate module, Terraform code is considered to be running within the “root” module!

End to End Example

It is one thing to read about the major components of writing Terraform configuration. It is another to see it in action. And anther beast to write it yourself. While we have done the former, we cannot do the latter for you. We can, however, point you to a Terraform module that follows the basic outline described in this article, which you can use as an example as you write your own Terraform configuration.

If you have any questions, please drop us a line! 

dragondrop.cloud’s mission is to automate developer best practices while working with Infrastructure as Code. Our flagship product regularly scans and identifies resource changes that have occurred outside of a Terraform workflow (e.g. drift) so that dev teams can have a Cloud environment that is fully represented as code. All of our tools are self-hosted by our customers, with no data ever leaving their servers. To learn more, schedule a demo or get started today!

Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.

Learn More About Terraform