Post

Let's try: Terraform part 5 - import

What to do if we want to develop the tf scripts on the existing resources?

Let's try: Terraform part 5 - import
In this series

Come to see again at part 5. All 4 parts is about creating a new resource and developing in tf scripts.

The next question is, what to do if we want to develop the tf scripts on the existing resources?


Import an existing resource

esources before/without maintaining in our Terraform stacks. Don’t worry, we can enlist them into. This is called Terraform import.

Terraform import can only importing resources’ states into our state file, so we have to update the tf scripts ourselves which is not quite a big deal.

diagram

Let’s say, we created two buckets manually like this.

bucket

There are 2 choices to import a resource into Terraform depends on how we currently design and manage the scripts.

  1. import into main scripts.
  2. import into modules.

resource in main scripts

If we go easy by writting resources in a single main folder, now we can do the following steps.

  1. Prepare an empty resource
  2. Import the state by referring the resource
  3. Show the state and update in tf scripts
  4. Verify tf scripts

1. Prepare an empty resource

2. import the state to the resource

Run the command.

1
2
terraform import -var-file="<var-file>" \
    '<resource_type>.<resource_name>' <resource_address>
  • var-file is for when we are using variables in the scripts, or Terraform will ask for the values.
  • Resource type and name are what we define in the tf script.
  • Resource address can be generated in the format given in Terraform registry.
    For this case, GCS bucket’s address format is here which is <project_name>/<bucket_name> or just bucket_name.

import

3. Show state and update scripts

Once the import is done successfully. We can list and see its configurations.

1
2
terraform state list
terraform state show <state_name>

state show

Then copy the config into the resource block.

4. Verify scripts

Then we can plan to see any missing between state and scripts.

plan

Oops! we got errors. There we can see unconfigurable attributes for self_link, url and id is invalid key. These are attributes we don’t need in the resource block so we delete them out.

Try plan again and yes we did it. It says no change now.

plan again


resource in modules

1. Prepare an empty resource

We can prepare a module resource like this.

and include it into the main script as follow.

2. import the state to the resource

When it comes to modules, we just change a bit on the command here.

1
2
terraform import -var-file="<var-file>" \
    'module.<module_name>.<resource_type>.<resource_name>' <resource_address>

In this case:

  • module_name is “bucket” as defined in the main script
  • resource_type is “google_cloud_storage_bucket” as defined in the module
  • resource_name is “bucket_in_module” as it is in the module as well

And it should show that the module’s resource has been imported successfully, like this.

import resource

When list the state, we can see the module’s state there.

3. Show state and update scripts

Then show the module’s state.

1
2
terraform state list
terraform state show <state_name>

state show

and copy into the resource block in the module.

4. Verify scripts

Finally try plan to see “no change” and that’s mean we’re done now.

plan


Update state

Say we have manually updated some configs on the existing resources we have in Terraform state. For example, I changed my bucket class from “STANDARD” to “NEARLINE”.

gcs class

Only the bucket “bluebirz-manual-create-bucket-for_main” has been changed for the bucket class.

updated class

Fortunately, we have the state of this resource. Life is easier as we just update the state of this bucket using the command.

1
terraform apply -var-file="<var-file>" -refresh-only -auto-approve

Terraform will fetch and update the latest configurations to be matched between the state file and the cloud provider.

update state

We can see what’s been changed in the output of the command. And we have to update our scripts as well for those changed configs.

This post is licensed under CC BY 4.0 by the author.