CDKTF 0.19 adds support for config-driven import and refactoring

[Hashicorp]

The mission of CDK for Terraform (CDKTF) is to simplify Terraform adoption. We introduced the generally available version of CDKTF in August of 2022, enabling developers not familiar with HashiCorp Configuration Language (HCL) to write Terraform configurations in their choice of language, including TypeScript, Python, C#, Java, and Go. In July of 2023, multi-language provider documentation for CDKTF further simplified infrastructure provisioning by offering provider configuration options and code samples for the programming languages supported by CDKTF, alongside the HCL documentation in the registry.

We are also working to make CDKTF more powerful by supporting new Terraform features to achieve cost savings and improve security. Up until now, CDKTF had limited support for import and moved blocks, resulting in manual, cumbersome resource migration and refactoring within a CDKTF project.

Today, we’re releasing CDKTF version 0.19, which improves support for config-driven import and refactoring. This support allows developers to safely move resources and bring existing infrastructure into CDKTF projects with auto-generated code — without jeopardizing business continuity.

Config-driven import support

Importing existing infrastructure into a CDKTF project was a manual process until Terraform 1.5 introduced config-driven import in June. CDKTF v0.19 adds support for config-driven import (which requires Terraform 1.5+) with two workflows, described below:

1. Specify a CDKTF config for a resource and specify where it is currently living:

Instantiate an instance of the resource type you want to import, with an empty configuration. Then call the importFrom method on the resource object, providing the id present for the resource in the cloud provider:

new S3Bucket(this, "bucket", {}).importFrom("id-in-cloud-provider")

When running a plan or apply, you will get a message saying that your resource is going to be imported. Once you run apply, you can remove the importFrom call and the resource will now be managed by CDKTF.

2. Generate configuration for an existing resource

If you want to generate configuration for an imported resource, you can use the static method generateConfigForImport by specifying the type of a resource and its resource ID. When you run a plan, Terraform will generate HCL config for the resource and CDKTF will convert it to your language of choice:

S3Bucket.generateConfigForImport(this, "bucket", "id-in-cloud-provider");

Resource refactoring with moved block support

If the ID of a resource is changed — for example, by refactoring it into a nested construct — destroying and recreating the resource is the default behavior of Terraform.

However, the new moveTo method lets you refactor code without losing the state or destroying and recreating the resources being moved. This is especially important when working in a production environment where you might want to restructure your code but can't afford service downtime or data loss.

The moveTo function is available on all resources and is used for relocating a resource to the location specified by the string target. To set the string target for a resource, use the addMoveTarget function present on the resource to move to:

new S3Bucket(this, "test-bucket-move-to", {
	bucket: "move-bucket-name",
}).addMoveTarget("move-s3");

new S3Bucket(this, "test-bucket-move-from", {
	bucket: "move-bucket-name",
}).moveTo("move-s3");

Try CDK for Terraform

If you’re new to the project, these tutorials for CDKTF are the best way to get started. You can dive deeper into our documentation with this overview of CDKTF.

Whether you’re still experimenting or actively using CDK for Terraform, we’d love to hear from you. Please file any bugs you encounter, let us know about your feature requests, and share your questions, thoughts, and experiences in the CDK for Terraform discussion forum.

View the full article