TERRAFORM 1.5 NEW FEATURES

-------------------TERRAFORM 1.5 NEW FEATURES-------------------------

With Terraform 1.5 in launched we have two new features added.

1. Config driven Import

So earlier we just had a state operation (one time to change the state of the state file only) using the terraform import command, which just brought one time change to the state file, we use import functionality in terraform when new infrastructure which is already created to bring it under the management of terraform.

We needed to manually change the resource block to add the new resources added.

Also it was error prone because it modified the state file instantaneously and if somebody else applied the terraform file using this state file it can lead to an inconsistent state.

Now we have terraform import block which we can include as part of our code inside the .tf file.

import {

# ID of the cloud resource

# Check provider documentation for importable resources and format

id = “i-abcd1234”

?

# Resource address

to = aws_instance.example

}

The above code reside at the top level of the .tf file and only we need to mention the instance id and a logic resource block as name depicted aws_instance.example which could be anything which you want as a logic resource name.

Which you can run using terraform plan -generate-config-out=generated_resources.tf

And then applying the same using the same parameter -generate-config-out.

2. Enhanced Validation and 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:

check "health_check" {

data "http" "example" {

url = "https://${aws_lb.example.dns_name}"

}

?

assert {

condition = data.http.example.status_code == 200

error_message = "${data.http.example.url} returned an unhealthy status code"

}

}

With these changes I strongly believe terraform is building itself like Ansible to bring some config management under its garb only difference is Ansible started from config management tool and can have the possibility of creating infra only limited to Red Hat whereas Terraform is pure IaC and moving towards config management also, definitely we can do it using local provisioners but still they are some kind of scripts which we run to configure the resources created. What if terraform comes with some runnable modules to do the same things as ansible does ??

Can you mention your comments/Views on it ?