Imagine that you provisioned a Terraform resource in your environment running on a public cloud, such as Google Cloud, and you need to destroy and recreate the resource so you can start from a clean state. Terraform gives you two tools to accomplish this:

The terraform taint command, which instructs Terraform to mark an object as tainted in the Terraform state. When an object is marked as tainted, Terraform will propose to replace it. (This command is considered deprecated.)
The -replace option of the terraform apply and terraform plan commands, which instructs Terraform to replace an object.

Both tools are easy to use while in an interactive session, but:

Partner with aster.cloud
for your next big idea.
Let us know here.

From our partners:

CITI.IO :: Business. Institutions. Society. Global Political Economy.

CYBERPOGO.COM :: For the Arts, Sciences, and Technology.

DADAHACKS.COM :: Parenting For The Rest Of Us.

ZEDISTA.COM :: Entertainment. Sports. Culture. Escape.

TAKUMAKU.COM :: For The Hearth And Home.

ASTER.CLOUD :: From The Cloud And Beyond.

LIWAIWAI.COM :: Intelligence, Inside and Outside.

GLOBALCLOUDPLATFORMS.COM :: For The World's Computing Needs.

FIREGULAMAN.COM :: For The Fire In The Belly Of The Coder.

ASTERCASTER.COM :: Supra Astra. Beyond The Stars.

BARTDAY.COM :: Prosperity For Everyone.

They need support from external tooling if you want to run them in automation. For example, if you need to destroy and recreate a resource based on some condition, you need to implement a check for that condition outside Terraform and run the appropriate Terraform command to destroy and recreate the resource when the condition is met.
They leak the state of resources outside Terraform because the check for any condition and the execution of the commands to destroy and recreate resources wouldn’t be described in Terraform terms.

To solve these issues, you could make use of the field within a Terraform resource that is designed to force a new resource to be created: ForceNew.

Assess the implementation of the Terraform resource you want to dynamically destroy and recreate, building a list of the resource attributes of type String. We limit the assessment to resource attributes of type String because you likely have a relatively high degree of flexibility to set their values, compared to other types, such as booleans.
Resource attributes have many fields, and one of those is ForceNew, which is of type boolean. Exclude from the list the resource attributes that are marked with the ForceNew boolean field set to false. When setting the ForceNew field to true for a given resource attribute, any change to that attribute requires the resource to be destroyed and recreated.
Exclude from the list the resource attributes whose constraints force you to choose a value from a limited set of values, as described in the documentation about the resource.
From the list of resource attributes of type String that have the ForceNew field set to true, and that allow you to set an arbitrary value (provided it passes the validation constraints), pick at least one attribute.
Dynamically set the values of the attributes you picked so that the value changes when you need the resources to be destroyed and re-created.

Corollary: You can use this strategy to introduce explicit dependencies between the state of different resources, as we’re going to read in the following example.

Example: Delete and recreate a Google Compute Engine virtual machine

In this example, you:

Provision a Compute Engine virtual machine (VM) using Terraform by creating a google_compute_instance resource.
Configure the google_compute_instance resource to force the deletion and the recreation of the VM when the state of this or other resources change.

Provision a Google Compute Engine VM

In the following snippet, you prepare the Terraform resource to provision a Compute Engine VM:

locals {
  my_meta_data = "my-meta-data-value"
}

resource "google_compute_instance" "development-workstation" {
  allow_stopping_for_update = true
  name                   = "development-workstation"
  machine_type     = "n1-standard-8"

  boot_disk {
    initialize_params {
      image = "ubuntu-2004-lts"
      size  = "100"
      type  = "pd-ssd"
    }
  }

 metadata = {
    my-meta-data = local.my_meta_data
  }


  network_interface {
    subnetwork = google_compute_subnetwork.development-workstation-subnet.self_link

    access_config {
      network_tier = "PREMIUM"
    }
  }

  service_account {
    # Set to cloud-platform scope, then use IAM to limit access to the service account that this instance uses
    # https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam
    scopes = ["cloud-platform"]
  }
}

Force the deletion and the recreation of the VM

Now imagine that you want Terraform to automatically destroy and recreate the VM you provisioned every time the state of this or other Terraform resources changes, keeping this logic within the Terraform resource itself. In this example, we want to force the deletion and recreation of the VM every time the value of the metadata.my-meta-data attribute changes.

According to the strategy described above, we:

1. Assess the implementation of the google_compute_instance resource looking for attributes of type String that are marked with the ForceNew field set to true. In the current implementation of the google_compute_instance resource, there are more than 15 of such attributes.

2. Exclude from the list the resource attributes whose constraints force you to choose a value from a limited set of values, as described in the documentation about the google_compute_instance resource. This leaves us with:

device_name: excluded because if it changes, it might break the workloads that depend on a disk with such ID to exist. Also, we don’t want to necessarily configure a disk just for this purpose.
name and hostname: excluded because changing these will also change the “identity” of the VM. Might be acceptable in some situations, but not in most cases.
description: keep this as a candidate.
metadata_startup_script: this is an interesting candidate, but we excluded it because it changes the provisioning and configuration process of the VM, and it requires you to implement a startup script.
project and zone: excluded because you likely don’t want to dynamically change where to provision the VM.

3. From the list of resource attributes of type String that have the ForceNew field set to true, and that allow you to set an arbitrary value (provided it passes the validation constraints), pick at least one attribute. We proceed by picking the only attribute left in the list: description.

4. Dynamically set the values of the attributes you picked so that the value changes when you need the resources to be destroyed and re-created. In this example, we want Terraform to forcefully destroy and recreate the VM every time the value of the metadata.my-meta-data attribute changes, so we dynamically set the value of the description attribute of the VM to change when the value value of the metadata.my-meta-data attribute changes:

Note: Only one attribute is currently in the list, but it might happen that you have more than one, so you’d have to choose according to your use case, or eventually pick more than one attribute.

description = "my-meta-data SHA512 hash (base64): ${base64sha512(local.my_meta_data)}"

In this example, we use the base64sha512 function to compute a SHA512 hash of a string, and to encode it in Base64 mainly to:

Constraint the dynamic part of the attribute value to a known size, that is equal to the size of a SHA512 hash.
Reduce the chances of dynamically setting an attribute value that includes unsupported characters by encoding it in base64.

The Terraform manifest now looks like this:

locals {
  my_meta_data = "my-meta-data-value"
}

resource "google_compute_instance" "development-workstation" {
  allow_stopping_for_update = true

  description      = "my-meta-data SHA512 hash (base64): ${base64sha512(local.my_meta_data)}"
  name             = "development-workstation"
  machine_type     = "n1-standard-8"

  boot_disk {
    initialize_params {
      image = "ubuntu-2004-lts"
      size  = "100"
      type  = "pd-ssd"
    }
  }

  metadata = {
    my-meta-data = local.my_meta_data
  }


  network_interface {
    subnetwork = google_compute_subnetwork.development-workstation-subnet.self_link

    access_config {
      network_tier = "PREMIUM"
    }
  }

  service_account {
    # Set to cloud-platform scope, then use IAM to limit access to the service account that this instance uses
    # https://cloud.google.com/compute/docs/access/service-accounts#accesscopesiam
    scopes = ["cloud-platform"]
  }
}

This ensures that when you update the value of metadata.my_meta_data, Terraform picks it up as a value change on the description field, which forcefully destroys and then recreates the development-workstation resource.

In this article, we described a strategy to force Terraform to destroy and recreate a resource when a value of a variable, a local variable, or an attribute of another resource changes. This strategy allows you to avoid using external tooling to check for any conditions, and keeps the resource state all within Terraform.