2020-10-27 02:15:36 +01:00
|
|
|
---
|
2022-01-11 01:44:18 +01:00
|
|
|
page_title: Forcing Re-creation of Resources - Terraform CLI
|
2021-12-15 03:41:17 +01:00
|
|
|
description: Commands that allow you to destroy and re-create resources manually.
|
2020-10-27 02:15:36 +01:00
|
|
|
---
|
|
|
|
|
2022-01-11 01:44:18 +01:00
|
|
|
# Forcing Re-creation of Resources
|
2020-10-27 02:15:36 +01:00
|
|
|
|
2022-01-11 01:44:18 +01:00
|
|
|
During planning, by default Terraform retrieves the latest state of each
|
|
|
|
existing object and compares it with the current configuration, planning
|
|
|
|
actions only against objects whose current state does not match the
|
|
|
|
configuration.
|
2020-10-27 02:15:36 +01:00
|
|
|
|
2022-01-11 01:44:18 +01:00
|
|
|
However, in some cases a remote object may become damaged or degraded in a
|
|
|
|
way that Terraform cannot automatically detect. For example, if software
|
|
|
|
running inside a virtual machine crashes but the virtual machine itself is
|
|
|
|
still running then Terraform will typically have no way to detect and respond
|
|
|
|
to the problem, because Terraform only directly manages the machine as a whole.
|
2020-10-27 02:15:36 +01:00
|
|
|
|
2022-01-11 01:44:18 +01:00
|
|
|
If you know that an object is damaged, or if you want to force Terraform to
|
|
|
|
replace it for any other reason, you can override Terraform's default behavior
|
|
|
|
using [the `-replace=...` planning option](/cli/commands/plan#replace-address)
|
|
|
|
when you run either `terraform plan` or `terraform apply`:
|
2020-10-27 02:15:36 +01:00
|
|
|
|
2022-01-11 01:44:18 +01:00
|
|
|
```shellsession
|
|
|
|
$ terraform apply -replace=aws_instance.example
|
|
|
|
# ...
|
|
|
|
|
|
|
|
# aws_instance.example will be replaced, as requested
|
|
|
|
-/+ resource "aws_instance" "example" {
|
|
|
|
# ...
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
|
|
## The "tainted" status
|
|
|
|
|
|
|
|
Sometimes Terraform is able to infer automatically that an object is in an
|
|
|
|
incomplete or degraded state. For example, if creation of a complex object
|
|
|
|
fails in such a way that parts of it already exist in the remote system, or
|
|
|
|
if object creation succeeded but a provisioner step subsequently failed,
|
|
|
|
Terraform must remember that the object exists but may not be fully-functional.
|
|
|
|
|
|
|
|
Terraform represents this situation by marking an object in the state as
|
|
|
|
"tainted". When an object is marked with this status, the next plan will force
|
|
|
|
replacing that object in a similar way to if you had specified that object's
|
|
|
|
address using `-replace=...` as described above.
|
|
|
|
|
|
|
|
```
|
|
|
|
# aws_instance.example is tainted, so must be replaced
|
|
|
|
-/+ resource "aws_instance" "example" {
|
|
|
|
# ...
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
|
|
If Terraform has marked an object as tainted but you consider it to be working
|
|
|
|
correctly and do not want to replace it, you can override Terraform's
|
|
|
|
determination using [the `terraform untaint` command](/cli/commands/untaint),
|
|
|
|
after which Terraform will consider the object to be ready for use by any
|
|
|
|
downstream resource declarations.
|
|
|
|
|
|
|
|
You can also _force_ Terraform to mark a particular object as tainted using
|
|
|
|
[the `terraform taint` command](/cli/commands/taint), but that approach is
|
|
|
|
deprecated in favor of the `-replace=...` option, which avoids the need to
|
|
|
|
create an interim state snapshot with a tainted object.
|