There is little doubt that HashiCorp Terraform is the leading “infrastructure as code” product. It uses a declarative syntax to create, provide, and update infrastructure resources deployed to hyper-scaled Cloud platforms and locally installed and deployed infrastructure. As part of HashiCorp’s continual improvement process they have just release the latest version “Terraform 1.5”, as normal they are constantly developing new features and capabilities and enhancing their support for a wide range of cloud providers and services.
Today, in this article, we will look at the additions and improvements that cut into their latest release of Terraform, 1.5. the major talking points are Config-driven import, checks, and Terraform Cloud integration; as such, these will be our three key areas of investigation.
So, without further ado, let’s consider these new features’ benefits.
So what have we got in Terraform 1.5?
Config-Driven Import
Anybody who has ever written a line of Terraform code and deployed it into a rapidly moving and fluid production environment knows and understands the pain of importing existing resources, or more likely, manually deployed resources that have been “deployed to fix an issue”, into your configuration’s file to enable the safe updating of the environments State file is perhaps the major difficulty of using Terraform in a production environment. Previously to this update, you had to manually change your configuration file to reflect the imported state after using the terraform import command for each resource separately, unless you were lucky enough to be using Azure as your platform of choice when deploying resources where you could use Terrafy to speed up the process.
Thankfully 1.5 has brought a much simpler method of controlling resource importation to the masses. Config-driven import, is a new feature in Terraform 1.5, that lets you import resources based on your current configuration file. This implies that you can create your configuration file first, then import the resources that match it using the Terraform apply command.
You must include a for_each parameter in your resource block and supply a map of identifiers for each resource instance if you want to use configuration-driven import. For instance, you could write something like this if you wanted to import two AWS EC2 instances with the IDs i-1234567890abcdef0 and i-0987654321fedcba0:
Resource “aws_instance” resource “example” {
for_each = {
"i-1234567890abcdef0" = {}
"i-0987654321fedcba0" = {}
}
# other arguments
Once the resource blocks have been written, they can be imported into your state file using the standard Terraform apply command. Before continuing, Terraform will ask you to confirm the import operation, but as standard, this confirmation step can be skipped using the -auto-approve switch.
Config-driven import can handle complex situations like nested modules and dependencies and works with any resource that supports import. Additionally, provided that they have a for_each argument, it permits the simultaneous import of numerous resources of various sorts.
The process of importing existing resources into Terraform can indeed be significantly streamlined and automated using configuration-driven import. Thereby making the transition of your infrastructure to Terraform control more straightforward and effective. It is not perfect, but it is a massive improvement on the previous process. Now that the importation framework is in place, it should only improve and develop to cover many more importation needs.
Checks
The second new feature we will be looking at is “Checks”; this function lets you specify unique regulations and validations for your setup. Checks are similar to Sentinel policies, however, they are written in HCL rather than in a different language. However, This function introduces a new configuration file, the “*.tfchecks”. This file is stored in your configuration directory and contains the definitions of the checks. Each check can have a name, a description, and a severity that you can specify using the check block. The condition argument can also be used to build a boolean expression that analyses your configuration information.
For instance, you could write something like this if you wanted to make sure that all AWS EC2 instances have tags:
check "instance_tags" {
description = "All EC2 instances must have tags."
severity = "error"
condition = alltrue([
for r in resources.aws_instance : length(r.tags)
> 0
]
)
}
These checks are then carried out by running either a Terraform plan or apply. If any check fails, Terraform will show an error message with the check’s name, description, and severity. By default, the outputs are sent to stdout, but the results can be obtained in JSON format using the -JSON flag; these can be picked up as a trigger to another process in your deployment pipeline, allowing further automation depending on the output’s results.
Checks are an effective technique to uphold compliance and build standardisation practices for your code. If you are a Terraform cloud user, “Checks” could be introduced to enhance the single Sentinel or OPA policy that is now available with the free tier; so that before making modifications to your infrastructure, the “checks” code can assist in identifying mistakes and discrepancies.
Integration of Terraform Cloud
The final improvement we are going to focus on is that users of Terraform can access collaboration and automation tools through Terraform Cloud, which is a hosted service enabling you as a user to conduct Terraform operations in a safe and scalable environment, store and backup your state files remotely, and share configuration with ease across your teams.
But wait, this is not new; TFC has been around for several years on app.terraform.io. However, Terraform 1.5 has added several additional capabilities to interact more effectively with Terraform Cloud. Several of these abilities include:
- Importing state from Terraform Cloud: You can now download your state file from Terraform Cloud and store it locally using the ”terraform state pull” This will be very useful for off-line backups or off-line troubleshooting.
- Viewing state from Terraform Cloud: You can now view your state data from Terraform Cloud without downloading it by using the “terraform state list” and “terraform state show” This can be used to examine or search your state data.
- Managing infrastructure from Terraform Cloud: You can now interact with the infrastructure that Terraform Cloud manages using the “terraform cloud” Options like “Apply, cancel, discard, force-unlock, list, lock, show”, and “unlock” are just a few of the subcommands that can be used to conduct different tasks on your workspaces and runs.
- Adding resources from Terraform Cloud: You can now add resources from Terraform Cloud to your setup by using the “terraform import” This can be helpful if you want to add already-managed resources from Terraform Cloud to your environment.
The recent improvements to the free tier, which was explained in this article, together with the new Integrations added to this release of Terrafrom, make for an even more compelling argument to utilise Terraform Cloud and its advantages over a purely local environment. It is given that using TFC will make your IaC utilisation secure and productive.
Conclusion
The Terraform ecosystem has seen significant advancements with the introduction of Terraform 1.5. the addition of new capabilities, including config-driven imports, inspections, and interaction with Terraform Cloud make managing your infrastructure simpler and more efficient.
For a more in-depth understanding, check out the official changelog, the blog postings, and the documentation to learn more about Terraform 1.5. Upgrading is as simple as using your operating system’s package manager or the official website to download the most recent version of Terraform.
We know that Terraform is an effective tool that helps develop, modify, and upgrade infrastructure safely and predictably. This new version has moved the goalposts. My favourite new feature is the new method of importation of resources; it is a massive step forward in functionality; even though it is not perfect, it is a good start. As I already alluded to, I prefer how Terrafy manages the issue, but that is limited as it only addresses the problem from an azure standpoint; perhaps that is the direction they may be moving, I hope so.
