2016-05-18 20:47:41 +02:00
|
|
|
---
|
2021-12-15 03:41:17 +01:00
|
|
|
page_title: 'Import: Usage'
|
|
|
|
description: The `terraform import` command is used to import existing infrastructure.
|
2016-05-18 20:47:41 +02:00
|
|
|
---
|
|
|
|
|
|
|
|
# Import Usage
|
|
|
|
|
2020-10-02 20:02:59 +02:00
|
|
|
> **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 on HashiCorp Learn.
|
2020-07-31 22:16:35 +02:00
|
|
|
|
2016-05-18 20:47:41 +02:00
|
|
|
The `terraform import` command is used to import existing infrastructure.
|
|
|
|
|
|
|
|
The command currently can only import one resource at a time. This means
|
|
|
|
you can't yet point Terraform import to an entire collection of resources
|
2017-07-19 00:00:33 +02:00
|
|
|
such as an AWS VPC and import all of it. This workflow will be improved in a
|
|
|
|
future version of Terraform.
|
2016-05-18 20:47:41 +02:00
|
|
|
|
2020-08-01 00:22:50 +02:00
|
|
|
~> 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
|
2021-12-15 03:41:17 +01:00
|
|
|
[the State section](/language/state).
|
2020-08-01 00:22:50 +02:00
|
|
|
|
2017-05-17 03:26:20 +02:00
|
|
|
To import a resource, first write a resource block for it in your
|
2017-07-19 00:00:33 +02:00
|
|
|
configuration, establishing the name by which it will be known to Terraform:
|
2017-05-17 03:26:20 +02:00
|
|
|
|
|
|
|
```
|
2017-07-19 00:00:33 +02:00
|
|
|
resource "aws_instance" "example" {
|
2017-05-17 03:26:20 +02:00
|
|
|
# ...instance configuration...
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
2017-07-19 00:00:33 +02:00
|
|
|
The name "example" here is local to the module where it is declared and is
|
|
|
|
chosen by the configuration author. This is distinct from any ID issued by
|
|
|
|
the remote system, which may change over time while the resource name
|
|
|
|
remains constant.
|
|
|
|
|
2017-05-17 03:26:20 +02:00
|
|
|
If desired, you can leave the body of the resource block blank for now and
|
|
|
|
return to fill it in once the instance is imported.
|
|
|
|
|
2019-11-01 16:47:46 +01:00
|
|
|
Now `terraform import` can be run to attach an existing instance to this
|
2017-05-17 03:26:20 +02:00
|
|
|
resource configuration:
|
2016-05-18 20:47:41 +02:00
|
|
|
|
2017-04-05 17:29:27 +02:00
|
|
|
```shell
|
2017-07-19 00:00:33 +02:00
|
|
|
$ terraform import aws_instance.example i-abcd1234
|
2016-05-18 20:47:41 +02:00
|
|
|
```
|
|
|
|
|
2019-11-01 16:47:46 +01:00
|
|
|
This command locates the AWS instance with ID `i-abcd1234`. Then it attaches
|
2018-04-21 17:49:38 +02:00
|
|
|
the existing settings of the instance, as described by the EC2 API, to the
|
|
|
|
name `aws_instance.example` of a module. In this example the module path
|
|
|
|
implies that the root module is used. Finally, the mapping is saved in the
|
|
|
|
Terraform state.
|
2017-07-19 00:00:33 +02:00
|
|
|
|
2018-04-21 17:49:38 +02:00
|
|
|
It is also possible to import to resources in child modules, using their paths,
|
2019-11-01 16:47:46 +01:00
|
|
|
and to single instances of a resource with `count` or `for_each` set. See
|
2021-12-15 03:41:17 +01:00
|
|
|
[_Resource Addressing_](/cli/state/resource-addressing) for more
|
2017-07-19 00:00:33 +02:00
|
|
|
details on how to specify a target resource.
|
2016-05-18 20:47:41 +02:00
|
|
|
|
2017-07-19 00:00:33 +02:00
|
|
|
The syntax of the given ID is dependent on the resource type being imported.
|
|
|
|
For example, AWS instances use an opaque ID issued by the EC2 API, but
|
|
|
|
AWS Route53 Zones use the domain name itself. Consult the documentation for
|
|
|
|
each importable resource for details on what form of ID is required.
|
2016-05-18 20:47:41 +02:00
|
|
|
|
2017-05-17 03:26:20 +02:00
|
|
|
As a result of the above command, the resource is recorded in the state file.
|
|
|
|
You can now run `terraform plan` to see how the configuration compares to
|
|
|
|
the imported resource, and make any adjustments to the configuration to
|
|
|
|
align with the current (or desired) state of the imported object.
|
2016-05-18 20:47:41 +02:00
|
|
|
|
|
|
|
## Complex Imports
|
|
|
|
|
|
|
|
The above import is considered a "simple import": one resource is imported
|
|
|
|
into the state file. An import may also result in a "complex import" where
|
2020-04-08 02:36:02 +02:00
|
|
|
multiple resources are imported. For example, an AWS network ACL imports
|
|
|
|
an `aws_network_acl` but also one `aws_network_acl_rule` for each rule.
|
2016-05-18 20:47:41 +02:00
|
|
|
|
2017-05-17 03:26:20 +02:00
|
|
|
In this scenario, the secondary resources will not already exist in
|
|
|
|
configuration, so it is necessary to consult the import output and create
|
|
|
|
a `resource` block in configuration for each secondary resource. If this is
|
|
|
|
not done, Terraform will plan to destroy the imported objects on the next run.
|
|
|
|
|
2017-07-19 00:00:33 +02:00
|
|
|
If you want to rename or otherwise move the imported resources, the
|
2021-12-15 03:41:17 +01:00
|
|
|
[state management commands](/cli/commands/state) can be used.
|