Terraform 1.5 brings config-driven import and checks

We’re excited to announce that HashiCorp Terraform 1.5 is now generally available, ready for download, and available for use in Terraform Cloud. Terraform is the standard infrastructure as code tool for multi-cloud provisioning and automation at any scale. This release brings two significant new features: a config-driven import workflow and check blocks. Config-driven import is a new declarative workflow to add existing resources into Terraform state and solves the limitations of the existing import command. Checks are a new way to perform functional validation of provisioned infrastructure to ensure the real world matches expectations.

»Config-driven import

Bringing existing infrastructure under management by Terraform is a common task when onboarding new teams and applications into a Terraform-based workflow. This often occurs as part of a standardization effort or during mergers and acquisitions. Until now, the only way to do this was with the terraform import command. But this command has limitations:

• Resources are imported one at a time.
• State is immediately modified, with no opportunity to preview the results. This can lead to accidental resource modifications or deletions if an apply operation is executed on the shared state by another team member before the corresponding configuration has been added.
• The matching resource code has to be manually written, which often means a multi-step process of running plans to identify the required attribute values to achieve a clean run.

With Terraform 1.5, we have introduced a completely new config-driven import mechanism. A new top-level import block allows import operations to be defined in code. This means that import operations can be executed in bulk and are now part of the standard plan and apply cycle. Import is now a plannable operation, not a state operation, which eliminates the risk of unexpected state modification.

Better yet, Terraform 1.5 also introduces automatic code generation for imported resources. This dramatically reduces the amount of time you need to spend writing code to match the imported resources. As one of our customers put it, “this is going to save us weeks and weeks of work.”

The import block takes two parameters: the ID of the cloud resource to be imported and the HCL address for the new resource block. Here’s an example of an import block for an Amazon EC2 instance:

Once import blocks are added to your Terraform code, execute a plan with the new -generate-config-out parameter to automatically create the matching resource blocks in a file you specify (example: terraform plan -generate-config-out=generated_resources.tf). After reviewing the generated code, simply run a normal apply operation to complete the import to state.

Follow the updated Import Terraform Configuration tutorial to get hands-on with the new import workflow and learn more in the documentation.

»Enhanced validation with checks

A common challenge for Terraform users and module authors is having confidence that the provisioned infrastructure is functioning as expected. Terraform 1.2 added preconditions and postconditions which allow you to codify custom validations with contextual error messages in Terraform configurations. These conditions exist at a data source or individual resource level, and they will stop a plan or apply operation if they fail.

These custom conditions are great for validating assumptions and guarantees for individual data sources, resources, and outputs. But we’ve also heard from the community and our customers that there is a need for more holistic functional validation after infrastructure is provisioned.

With Terraform 1.5 we are introducing a new validation mechanism to address these needs: the check block. Checks are a new top-level construct which gives Terraform practitioners and module authors additional flexibility to define assertions within Terraform code. While there is overlap between the use cases for postconditions and checks, the check block has several notable differences:

• Because they exist at the top level, checks can reference all resources, data sources, and module outputs in the configuration. Checks are best suited for overall functional validation of the infrastructure, while postconditions guarantee the configuration of a single resource.
• Checks occur as the last step in the plan or apply and do not halt execution. Failed checks emit a warning message instead of an error.
• Checks can contain more than one assertion. Combined with the ability to reference all objects in the configuration and the power of the Terraform language, this allows for more complex conditional evaluations that make up an overall result.
• A check block can optionally include one nested (“scoped”) data source. If a scoped data source fails to execute, the error is contained to the check block evaluation and does not halt overall execution of the Terraform run.

In following example, a scoped data source is defined within the check block to validate the status of a provisioned web application:

Learn more about check blocks and assertions in the Terraform language documentation, and check out the new tutorial, Use checks to validate infrastructure to try it yourself.

»Getting started with Terraform 1.5

For more details and to learn about all of the enhancements in Terraform 1.5, please review the full HashiCorp Terraform 1.5 changelog.

• Download Terraform 1.5
• Sign up for a free Terraform Cloud account
• Read the Terraform 1.5 upgrade guide
• Get hands-on with tutorials at HashiCorp Developer

As always, this release wouldn't have been possible without all of the great community feedback we've received via GitHub issues and from our customers. Thank you!