Using Terraform Import Blocks with Alkira

For many moons, importing existing infrastructure (that is to say, infrastructure running outside of Terraform state), has not been a trivial task. Historically, Terraform did not generate any configuration. You would have to write the infrastructure-as-code in a manner that reflects how it was deployed. Then, to make matters not easier, you would fetch the ‘ol shovel and dig out the unique resource identifiers to feed through the command line. Handling a single resource in this manner is pretty simple. Wrangling 20+ resources like this is not. Last month, Terraform v1.5.0 was released, offering the ability to use import blocks. Let’s test this new feature on my favorite infrastructure provider, Alkira.

Why is this Useful?

#

This feature shifts import from a CLI driven approach to configuration-driven and plannable actions for adopting existing resources. Here are the key takeaways:

• Configuration-Driven: You can now declare imports within your Terraform configuration files using an import block, making the process more streamlined and part of the initial planning.

• Plannable Action: Terraform treats importing as part of a standard plan. Running terraform plan will show a summary of the resources that Terraform intends to import, along with other planned changes.

• Preservation of existing CLI command: The existing terraform import CLI command remains unchanged and can still be used separately.

• Support for Generating Configuration for Imported Resources: This feature, used in conjunction with the import block, enables templating of configuration when importing resources. A new flag -generate-config-out=PATH is added to terraform plan. When this flag is set, Terraform generates an HCL configuration for any resource included in an import block that doesn’t already have an associated configuration, writing it to a new file at the specified PATH.

A Common Scenario

#

In this scenario, I’ll build an AWS VPC and connect it to Alkira using the alkira_connector_aws_vpc resource. This is a pretty common scenario I see with our customers. They begin a proof-of-concept for a particular use case and do most of the testing via Alkira’s excellent user interface. Instead of building a new environment for production however, a lot of times, they will want to take the proof-of-concept to production. From here, they need to import what has already been built into the appropriate Terraform State file.

Building some Infrastructure

#

I’m going to mock-up the infrastructure we will import using Terraform.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

# Some things already exist - fetch the IDs
data "alkira_group" "this" { name = "aws" }
data "alkira_segment" "this" { name = "my-org" }
data "alkira_credential" "this" { name = "aws" }

/*
Provision VPC
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/vpc
*/
resource "aws_vpc" "this" {
  cidr_block = "10.1.0.0/16"

  tags = {
    Name = "this-vpc"
  }

}

/*
Provision a single /24 subnet for VPC
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/subnet
*/
resource "aws_subnet" "this" {
  vpc_id            = aws_vpc.this.id

  cidr_block        = cidrsubnet(aws_vpc.this.cidr_block, 8, 0)
  availability_zone = "${var.aws_region}a"

  tags = {
    Name = "this-subnet"
  }

}

/*
Attach VPC to Alkira
https://registry.terraform.io/providers/alkiranet/alkira/latest/docs/resources/connector_aws_vpc
*/
resource "alkira_connector_aws_vpc" "this" {

  # AWS details
  aws_account_id   = var.aws_account_id_p
  aws_region       = var.aws_region
  vpc_id           = aws_vpc.this.id
  vpc_cidr         = [aws_vpc.this.cidr_block]

  # Alkira details
  name             = "this-connector"
  cxp              = upper(var.aws_region)
  credential_id    = data.alkira_credential.this.id
  group            = data.alkira_group.this.name
  segment_id       = data.alkira_segment.this.id
  size             = "SMALL"

  depends_on       = [ aws_vpc.this, aws_subnet.this ]

}

# Output for connector_id
output "connector_id" {
  value  =  alkira_connector_aws_vpc.this.id
}

Importing that Infrastructure Somewhere Else

#

Now that we have some infrastructure to work with, along with the resource identifiers, let’s put import blocks to the test. First, we create an import block for the Alkira connector in a file called imports.tf in a separate directory. I defined the connector_id returned from the previous configuration into a new variable called var.connector_id:

1
2
3
4

import {
  to = alkira_connector_aws_vpc.this
  id = var.connector_id
}

Next, we initialize this separate directory containing the new Terraform configuration. Once everything is initialized, we can run -generate-config-out=main.tf which generates the following:

Conclusion

#

This is a great feature that saves time. If I had to guess, as more functionality and polish is added, you’ll see modules popping up that leverage import blocks and provide a simplified way to import larger swaths of infrastructure. Some tools exist out there to do this today. Last year, I wrote about one such tool - Azure Terrafy. The difference is that since this is now integrated with the Terraform configuration and planning process, it can keep all of the logic in the HashiCorp ecosystem. No messing around with fetching binaries or needing to do any third-party tricks.