Terraform's fundamentals for configuring, managing, and scaling

Declarations alone are not enough to ensure stable infrastructure operation in a rapidly changing cloud environment.
This book is a practical guide to properly applying Terraform in practice.
We will go through key concepts one by one, such as state management, execution environment separation, custom module design, and use of various providers.
Additionally, it contains examples applicable to actual work, including input value management using YAML and CSV, open source integration such as KeyClock, and configuration of a multi-region environment.
For anyone who wants to understand Terraform more deeply and operate it reliably, this book will be a great starting point.

It is true that there is a perception that Terraform's HCL is difficult to learn.
However, HCL is just a declarative configuration language like JSON or YAML, and it allows you to define field references of resources or references between resources in an easier way than JSON or YAML.
In fact, any script that can be written in HCL can be written using an equivalent JSON-based configuration syntax.
Going further, HCL could theoretically also be expressed in its equivalent YAML, since JSON is a subset of YAML.
/ HCL is simply a language created to make writing JSON and YAML configuration files a little easier for infrastructure administrators, and is equivalent to JSON.

--- p.17

You can define and use modules as subdirectories within a module.
This is called a nested module.
Typically, when iterating over a collection and repeatedly creating resources, a fairly wide range of resources may need to be created for each iteration.
In this case, you can implement it by simply using for_each or for on many types of resources at the same time, but as you can easily predict, there is a high possibility of error.
In this case, you can use a method to improve the readability of the root module by defining actions according to the iteration as nested modules.
Nested modules are usually placed in the /modules subdirectory, as per Terraform's official convention, but it works correctly even if you don't follow the convention if you have a good reason to do so.

--- p.74

AWS metadata is a value that is frequently used in various environments and projects in practice, so it needs to be called more often than you might think.
For example, it is a common pattern to tag each resource within a module with account information.
Additionally, you can branch to create different resources depending on the account or region you are currently referencing.
/ However, in each of these situations, directly calling the value of AWS metadata is not efficient in terms of code maintenance.
To explain the reason, first of all, the ID must be received through different data blocks called aws_caller_identity, the alias through aws_iam_account_alias, and the region information through aws_region in the AWS metadata values.
However, it is cumbersome to have to check which data block contains the information I want every time I need metadata information.
Additionally, if you have to find out the metadata in this state by simply calling multiple data blocks, you end up writing repetitive and verbose code, which reduces readability and maintainability.

--- p.105

As with the VPC module, the security group module also sets the output block to a value that can be referenced from other resources.
The only new resources created in this module are security groups and security group rules.
Since the identifier of a security group rule is rarely used directly outside of the security group module, the only thing that is worth setting as an output value is the ID of the security group.
/ Therefore, we define the output block of the security group module to export the IDs of all security groups created in the module in map format.
To do this, we apply a for expression to aws_security_group.this, a resource block that points to a security group, and define a map in the form k =〉 v.id using parameters that point to keys and values.
As a result, an output block is created that can obtain the ID of a security group through the name of the security group.

--- p.187

A null provider is a virtual resource that does not create any actual resources.
Instead of handling actual resources, they are used to execute templates or external scripts, or to control simple workflows.
For example, you can use it to send API requests that are not supported by Terraform, or to control the resource creation flow.
/ However, in most cases, script execution or resource control is possible without a null provider, and its use is not recommended because it makes the code difficult to understand.
Additionally, starting with Terraform version 1.4, a Terraform native resource type with the same role named terraform_data6 was introduced, eliminating the need to use the null provider.
In fact, if you compare the two resources, everything else is the same except that the triggers property of null_resource has been changed to triggers_replace in terraform_data.

--- p.249

Atlantis is a representative open source tool for Terraform collaboration.
It is recommended because it allows you to set rules such as automatically executing planning or reflection commands when Terraform code changes are pushed to the repository, and it even provides a consistent Terraform execution environment.
However, this does not mean that Atlantis must be applied to all Terraform projects.
First of all, if you have a small team of people managing Terraform, the cost of installing Atlantis may be greater than the benefits you get from it.
Since it is a tool that handles infrastructure, it basically has to be installed within the company network, so server costs must be taken into consideration, and for those installing it for the first time, implementing the pipeline can be a learning curve, so it is recommended to check whether it is absolutely necessary before introducing it.

--- p.333