如何编写CDKTF模块替代Terraform模块实现多资源组合

你不需要依赖cdktf.json里的terraformModules配置引用原生Terraform模块，CDKTF原生支持通过**自定义Construct（构造）**的方式，用纯TypeScript文件把关联资源打包成可复用逻辑单元，最终效果和引用本地Terraform模块完全一致，灵活度更高。

具体实现步骤 #

1. 封装自定义可复用Construct #

你可以在项目中单独创建目录存放可复用单元，比如对应你示例里的./New folder本地模块路径，可以新建./constructs/my-local-module目录，在目录下创建index.ts编写封装逻辑：

• 自定义单元本质是一个继承自constructs包中Construct基类的TypeScript类
• 类的构造函数入参可以定义配置接口，对应原生Terraform模块的variable输入
• 类的公开属性可以暴露资源输出，对应原生Terraform模块的output输出
• 所有关联的资源定义直接写在类的构造函数内，和你在TerraformStack中写资源的语法完全一致

参考封装代码：

// ./constructs/my-local-module/index.ts
import { Construct } from "constructs";
// 按实际使用的云厂商Provider引入对应资源，示例以AWS Provider为例
import { SecurityGroup, Instance } from "@cdktf/provider-aws/lib/ec2";

// 定义单元入参类型，对应Terraform模块的variable
export interface MyLocalModuleConfig {
  vpcId: string;
  instanceType?: string;
  tags?: Record<string, string>;
}

// 定义单元输出结构，对应Terraform模块的output
export interface MyLocalModuleOutput {
  securityGroupId: string;
  instancePrivateIp: string;
}

export class MyLocalModule extends Construct {
  // 暴露输出属性供外部调用
  public readonly output: MyLocalModuleOutput;

  constructor(scope: Construct, id: string, config: MyLocalModuleConfig) {
    super(scope, id);

    // 编写所有关联资源的定义逻辑
    const serviceSg = new SecurityGroup(this, "service-sg", {
      vpcId: config.vpcId,
      ingress: [
        { protocol: "tcp", fromPort: 80, toPort: 80, cidrBlocks: ["0.0.0.0/0"] }
      ],
      tags: config.tags
    });

    const serviceInstance = new Instance(this, "service-instance", {
      ami: "ami-0cxxxxxx", // 可根据需要将ami等参数加入入参配置
      instanceType: config.instanceType ?? "t3.micro",
      vpcSecurityGroupIds: [serviceSg.id],
      tags: config.tags
    });

    // 组装输出属性
    this.output = {
      securityGroupId: serviceSg.id,
      instancePrivateIp: serviceInstance.privateIp
    };
  }
}

2. 在Stack中直接引用封装好的TS单元 #

不需要在cdktf.json中做任何模块相关配置，直接像引入普通TypeScript类一样导入自定义的Construct，在Stack中实例化即可，使用体验和引用原生Terraform模块完全一致。

参考引用代码：

// 项目入口Stack文件 例如./main.ts
import { App, TerraformStack } from "cdktf";
import { Construct } from "constructs";
import { AwsProvider } from "@cdktf/provider-aws/lib/provider";
// 导入自己封装的可复用单元
import { MyLocalModule } from "./constructs/my-local-module";

class DemoStack extends TerraformStack {
  constructor(scope: Construct, id: string) {
    super(scope, id);

    // 初始化Provider
    new AwsProvider(this, "aws", {
      region: "cn-north-1"
    });

    // 实例化自定义单元，和引用本地Terraform模块的写法逻辑对齐
    const myAppModule = new MyLocalModule(this, "my-local-module", {
      vpcId: "vpc-0xxxxxx",
      instanceType: "t3.small",
      tags: {
        env: "dev",
        app: "demo-service"
      }
    });

    // 直接访问单元输出属性，不需要额外处理Terraform模块的output映射
    console.log("实例私网IP:", myAppModule.output.instancePrivateIp);
  }
}

const app = new App();
new DemoStack(app, "demo-infra-stack");
app.synth();

方案优势 #

• 静态校验：依托TypeScript类型系统，在编译阶段就能发现参数配置错误，比原生Terraform模块的校验时机更早
• 逻辑灵活：可以在封装类中编写任意TypeScript逻辑，比如条件判断、动态配置生成、批量资源创建，灵活度远高于HCL编写的Terraform模块
• 开发体验：IDE可以自动补全参数、输出属性，不需要记忆Terraform模块的variable和output定义
• 产物一致：最终CDKTF合成的Terraform配置和引用原生Terraform模块的生成结果完全一致，资源依赖、属性配置不会有差异

内容的提问来源于stack exchange，提问作者Amoghavarsh P