terraform removed block - ghdrako/doc_snipets GitHub Wiki

Zastosowanie

Nie potrafimy skasowac zasobu za pomca terraforma np cloudsql sie wywala bo postgres jest powiazany z jakimis obiektami. Procedura jest taka

  1. Zakomentoujemy zasob i dajemy klazule removve z destroy=false - aby usunac ze stata bez fizycznego kasowania
  2. Skasowac fizycznie z poziomu chmury Jesli zrobimy odwrotnie wywali sie teraform bo bedzie w czssie fazy refresh zczytywal parametry z chmury zasobow z state a jesli instacje skasowalismy recznie to jej juz nie bedzie i zanim zacznie robic plan to wywali:
 Error: googleapi: Error 404: The Cloud SQL instance does not exist., instanceDoesNotExist

caveat: no singular instance support

Nie da sie skasowac pojedynczego zasobu z tablicy typu module.foo.aws_iam_user[0] czy z mapy po kluczu

Workeround:

moved {
  from = module.foo.aws_iam_user[0]
  to   = module.foo.aws_iam_user_0
}
removed {
  from = module.foo.aws_iam_user_0
  lifecycle {
    destroy = false
  }
}

So in the example, we want to remove index 0 from our module of aws_iam_users, with a normal removed block that is not supported (we cannot target that specific index, or if it were a map, the key). However, with the introduction of the moved block, we can take that indexed instance of the resource and place it into a “fake” path in which the removed block will pick up and remove from the state file (in the example above, since destroy=false, this won’t be deleted in our cloud provider but just from our state management).

removed Syntax

The removed block syntax is as follows:

removed {
  from = 
  lifecycle {
    destroy = 
  }
}
  • from ~ The resource or module path that you want to be removed from the state file
  • lifecycle.destroy ~ Whether the infrastructure should be destroyed as part of the removal

one big caveat: no singular instance support

Using a combination of a moved block with a removed block, you can take a single instance of a resource and move it into a non-existent path to then remove it.

The example below shows this in action:

moved {
  from = module.foo.aws_iam_user[0]
  to   = module.foo.aws_iam_user_0
}
removed {
  from = module.foo.aws_iam_user_0
  lifecycle {
    destroy = false
  }
}

So in the example, we want to remove index 0 from our module of aws_iam_users, with a normal removed block that is not supported (we cannot target that specific index, or if it were a map, the key). However, with the introduction of the moved block, we can take that indexed instance of the resource and place it into a “fake” path in which the removed block will pick up and remove from the state file (in the example above, since destroy=false, this won’t be deleted in our cloud provider but just from our state management).

In Terraform, the removed block, available from version 1.7, allows you to remove a resource from the Terraform state without destroying the underlying infrastructure. This is useful when you want to stop managing a resource with Terraform but don't want to delete it from your environment. It provides an alternative to the terraform state rm command, offering a safer and more predictable way to manage state changes

removed{
  from = module.cloud-clone-sql-prd.google_sql_user.users
  lifecycle {destroy = false}
}
removed{
  from = module.cloud-clone-sql-prd.google_sql_database_instance.instance
  lifecycle {destroy = false}
}

To declare that a resource was removed from Terraform configuration (state) but that its managed object should not be destroyed, remove the resource block from your configuration and replace it with a removed block:

removed {
 from = aws_instance.example

 lifecycle {
   destroy = false
 }
}

The lifecycle block is required. The destroy argument determines whether Terraform will attempt to destroy the object managed by the resource or not. A value of false means that Terraform will remove the resource from state without destroying it.