NOTE: these instructions have been genericised from a real example, and so your mileage may vary.
I first create a provider.tf
file.
terraform {
required_providers {
fastly = {
source = "fastly/fastly"
version = "0.28.2"
}
}
}
provider "fastly" {
api_key = "<API_KEY>"
}
Next I create a main.tf
placeholder file (I name the resource import_testing
but you will likely want to name it something different).
resource "fastly_service_v1" "import_testing" {}
I use a program called tfswitch
(https://github.com/warrensbox/terraform-switcher) to manage multiple terraform versions, but you can just download the latest version direct from HashiCorp if you don't have multiple projects (e.g. each project using a different Terraform version).
I use tfswitch
to install the latest version of Terraform (currently v0.15.1
).
I run terraform init
which displays a bunch of information, but the relevant section is in green and says "Terraform has been successfully initialized!"
I then import the service using:
terraform import fastly_service_v1.import_testing <SERVICE_ID>
Notice the use of import_testing
as the name I assigned to the fastly_service_v1
resource. If you decide to change the name as I suggested earlier, you will want to be sure to update this command to reflect that change. Also <SERVICE_ID>
should be replaced with your actual Service ID.
Running this command will display some information, but the relevant section is in green and says "Import successful!".
I don't need to run the next command, but I like to have a look at the local state straight after an initial import:
terraform show
The show
subcommand pretty prints the internal Terraform state (i.e. what's in the terraform.tfstate
that has been created in the local directory where the other Terraform files, provider.tf
/main.tf
are located).
The next crucial command is to run:
terraform show -no-color > main.tf
This will overwrite the 'placeholder' content that was in the main.tf
file with a bunch of Terraform HCL code.
This code is a HCL version of the Terraform internal state, which will include a bunch of things that shouldn't be present in a typical Terraform file you would normally write manually by hand.
This means I need to manually edit the updated main.tf
content so it doesn't include internal state attributes that would cause a terraform plan
to get confused. I start by first executing terraform validate
to be sure that otherwise Terraform is happy.
This should print the message "Success! The configuration is valid."
At this point I also run a terraform plan
to see if Terraform thinks any changes are needed (I know from experience that Terraform will be confused and so I typically run this just out of interest).
I can see in the output (I've shortened it for brevity):
~ resource "fastly_service_v1" "import_testing" {
+ comment = "Managed by Terraform"
+ vcl {
+ content = <<-EOT
- vcl {
- content = <<-EOT
- main = true -> null
- name = "customvcl" -> null
So we can see from this that it is seeing comment
as a new attribute and the vcl
attribute is being deleted and recreated.
So here's where I open up main.tf
and manually remove attributes I know should be deleted (and add/modify certain attributes)...
Attributes to delete:
active_version
id
Attributes to add:
comment = ""
(I just added it under thename = "<...>"
attribute).
Attributes to modify:
content
(inside thevcl
block) should no longer use<<-EOT
inlined VCL and should now becomecontent = file("vcl/main.vcl")
That last point will require you to download your main VCL file and stick it inside a vcl
directory next to your other Terraform files provider.tf
and main.tf
.
One other change I need to make is to the terraform.state
file itself. I modify this file so that "activate": null
becomes "activate": true
. The activate
field is specific to the Fastly Terraform Provider and is not returned by the Fastly API and so that's why we need to tweak it when doing an import of a service.
Although not used in this example, I've historically had to delete fields such as dictionary_id
.
NOTE: If you see any
(sensitive value)
values, then replace them with actual secrets (although it might be best to usefile()
for multi-line keys). You should have a read through Fastly's "Orchestration using Terraform and the Fastly Terraform Provider" which has a best practices section that covers how to handle sensitive data.
Now if I run a terraform plan
I'll see:
No changes. Infrastructure is up-to-date.