The biggest differentiator of Terraform is that, well, Terraform plans ahead. Let’s look at how Terraform handles planning in detail.

The plan

When working with Terraform, you will be following a process where Terraform is used to analyze the existing environment. In doing this analysis, Terraform is determining what (if any) changes in the code need to be applied to the actual environment to bring it up to date. Terraform itemizes these changes as actions within the plan. While Terraform does this analysis on our behalf, produces the plan, and is fully capable of executing that plan against the environment, we are still responsible for reviewing the plan and determining if the planned changes are what we intended:

Figure 1.1 – Terraform resources are straightforward machines with inputs and outputs

Terraform represents every component in your environment as a resource in this analysis. Resources...

Terraform uses the state to remember what was previously provisioned in a given workspace. Some critics of Terraform, when they compare it to AWS CloudFormation or ARM templates, point out that these technologies don’t rely on this concept of maintaining state in an externalized file. Of course, this is only true because these tools only support a single target platform and can tightly couple to the proprietary nature in which those platforms maintain state. However, Terraform—with its flexible plugin architecture—can’t assume anything about the platform and the resources that it provisions to each target platform. Therefore, Terraform needs to drop to the lowest common denominator and ensure that it knows what it has provisioned before in a uniform and consistent fashion.

This approach to maintaining the state provides a couple of benefits. First, it uniformly records what Terraform has provisioned across platforms that...

One of Terraform’s most powerful capabilities is its ease of organizing and packaging reusable code, which increases the maintainability of your code base and improves the reusability of common patterns in your architecture.

Traditional developers have it easy—you must simply create a new method to encapsulate a reusable code block. In other IaC tools, doing the same thing is a challenge. In Terraform, all you need is a new folder.

Terraform scopes every module within a folder. When you run terraform init, Terraform transforms the current working directory into the root module of the workspace. You can use modules stored in other folders within the same repository just by using a relative path to reference the module. It is a standard convention within the Terraform community for storing local modules in a modules directory near the root module’s directory.

Consider this folder structure:

  &...

Now that we understand Terraform’s core architecture, let’s examine its CLI and how to interact with it. There are many different commands, but we’ll focus on the important ones for implementing the core Terraform workflow. I’d encourage you to explore HashiCorp’s documentation for some of the more obscure ones, and later in Chapter 17, when we discuss managing existing environments using Terraform, we’ll be covering some more commands useful in that context.

init

This is an important command and probably the first one you will ever execute when working with Terraform. The reason is that Terraform works within a working directory instead of other tools that operate on a single file (such as ARM or CloudFormation) or an entry point file (such as Ansible). Terraform also relies on hidden directories to load important context about the workspace. This approach is very similar to how Git works...

In this chapter, we took an in-depth look at Terraform’s architecture. We primarily focused on two critical architectural components: state and modularity. Having a sound understanding of Terraform’s architecture is vital for you to be able to use Terraform to its fullest effectively. Finally, we ended by looking at Terraform’s CLI, which will enable you to, when you’re ready, integrate Terraform with your own CI/CD pipelines. In the next chapter, we will explore HCL so that we can lay the foundation on which we can start building IaC using Terraform.