> **Hands-on:** Try the [Import Terraform Configuration](https://learn.hashicorp.com/tutorials/terraform/state-import?in=terraform/state&utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) tutorial.
<<<<<<< HEAD
Terraform can import existing infrastructure resources. This functionality lets you bring existing resources under Terraform management.
~> Warning: Terraform expects that each remote object is bound to only one resource address. You should import each remote object to only one Terraform resource address. If you import the same object multiple times, Terraform may exhibit unwanted behavior. Refer to [State](/language/state) for more details.
=======
Terraform can import existing infrastructure resources. This functionality allows you take
resources you created by some other means and bring them under Terraform
management.
This is a great way to slowly transition infrastructure to Terraform, or
to be able to be confident that you can use Terraform in the future if it
potentially doesn't support every feature you need today.
~> Warning: Terraform expects that each remote object it is managing will be
bound to only one resource address, which is normally guaranteed by Terraform
itself having created all objects. If you import existing objects into Terraform,
be careful to import each remote object to only one Terraform resource address.
If you import the same object multiple times, Terraform may exhibit unwanted
behavior. For more information on this assumption, see
[the State section](/language/state).
>>>>>>> parent of 0a7e221a49 (Remove future-facing statements)
## Currently State Only
<<<<<<< HEAD
## State Only
Terraform import can only import resources into the [state](/language/state). Importing does not generate configuration.
Before you run `terraform import` you must manually write a `resource` configuration block for the resource. The resource block describes where Terraform should map the imported object.
@ -41,19 +22,3 @@ Before you run `terraform import` you must manually write a `resource` configura
## Terraform Cloud
When you use Terraform on the command line with Terraform Cloud, many commands like `apply` run inside your Terraform Cloud environment. However, the `import` command runs locally, so it does not have access to information from Terraform Cloud. To successfully perform an import, you may need to set local variables equivalent to any remote workspace variables in Terraform Cloud.
=======
The current implementation of Terraform import can only import resources
into the [state](/language/state). It does not generate configuration. A future
version of Terraform will also generate configuration.
Because of this, prior to running `terraform import` it is necessary to write
manually a `resource` configuration block for the resource, to which the
imported object will be mapped.
While this may seem tedious, it still gives Terraform users an avenue for
importing existing resources.
## Terraform Cloud
When you use Terraform on the command line with Terraform Cloud, many commands (e.g., `apply`) run inside your Terraform Cloud environment. However, the `import` command runs locally, so it will not have access to information from Terraform Cloud. To successfully perform an import, you may need to set local variables equivalent to any remote workspace variables in Terraform Cloud.
>>>>>>> parent of 0a7e221a49 (Remove future-facing statements)
@ -61,8 +61,6 @@ Because state does not currently have any significant metadata not covered by th
}
```
The extra wrapping object here will allow for any extension we may need to add in future versions of this format.
## Plan Representation
A plan consists of a prior state, the configuration that is being applied to that state, and the set of changes Terraform plans to make to achieve that.
For sets of strings, Terraform sorts the elements by their value, using
lexical sorting.
For sets of other types, Terraform uses an arbitrary ordering that may change
in future versions of Terraform. For that reason, we recommend converting the
result of such an expression to itself be a set so that it's clear elsewhere
in the configuration that the result is unordered. You can use
[the `toset` function](/language/functions/toset)
For sets of other types, Terraform uses an arbitrary ordering. For that reason, we recommend converting the result of such an expression to itself be a set so that it's clear elsewhere in the configuration that the result is unordered. You can use [the `toset` function](/language/functions/toset)
to concisely convert a `for` expression result to be of a set type.
@ -49,8 +49,8 @@ The arguments available within a `lifecycle` block are `create_before_destroy`,
such features, so you must understand the constraints for each resource
type before using `create_before_destroy` with it.
Destroy provisioners of this resource will not run if `create_before_destroy`
is set to `true`. We may address this in the future, and this [GitHub issue](https://github.com/hashicorp/terraform/issues/13549) contains more details.
Destroy provisioners of this resource do not run if `create_before_destroy`
is set to `true`. This [GitHub issue](https://github.com/hashicorp/terraform/issues/13549) contains more details.
* `prevent_destroy` (bool) - This meta-argument, when set to `true`, will
cause Terraform to reject with an error any plan that would destroy the
@ -235,8 +235,8 @@ fail, Terraform will error and rerun the provisioners again on the next
provisioners to be safe to run multiple times.
```
Destroy provisioners of this resource will not run if `create_before_destroy`
is set to `true`. We may address this in the future, and this [GitHub issue](https://github.com/hashicorp/terraform/issues/13549) contains more details.
Destroy provisioners of this resource do not run if `create_before_destroy`
is set to `true`. This [GitHub issue](https://github.com/hashicorp/terraform/issues/13549) contains more details.
```
Destroy-time provisioners can only run if they remain in the configuration
@ -251,8 +251,7 @@ remove a resource with a destroy-time provisioner:
* Remove the resource block entirely from configuration, along with its `provisioner` blocks.
* Apply again, at which point no further action should be taken since the resources were already destroyed.
This limitation may be addressed in future versions of Terraform. For now,
destroy-time provisioners must be used sparingly and with care.
Because of this limitation, you should use destroy-time provisioners sparingly and with care.
~> **NOTE:** A destroy-time provisioner within a resource that is tainted _will not_ run. This includes resources that are marked tainted from a failed creation-time provisioner or tainted manually using `terraform taint`.
Laura Pacilio
4 years ago