Configs2026年5月15日·1 分钟阅读

CDKTF — Define Terraform Infrastructure with TypeScript, Python, Go or Java

CDK for Terraform (CDKTF) lets you define cloud infrastructure using familiar programming languages instead of HCL, then synthesizes standard Terraform JSON for plan and apply.

Agent 就绪

这个资产可以被 Agent 直接读取和安装

TokRepo 同时提供通用 CLI 命令、安装契约、metadata JSON、按适配器生成的安装计划和原始内容链接,方便 Agent 判断适配度、风险和下一步动作。

Native · 98/100策略:允许
Agent 入口
任意 MCP/CLI Agent
类型
Skill
安装
Single
信任
信任等级:Established
入口
CDKTF Overview
通用 CLI 安装命令
npx tokrepo install 67452a98-5058-11f1-9bc6-00163e2b0d79

Introduction

CDK for Terraform bridges the gap between Terraform's provider ecosystem and general-purpose programming languages. Instead of writing HCL, you define resources with TypeScript, Python, Java, C#, or Go classes, gaining access to loops, conditionals, type checking, and IDE support while Terraform handles the actual provisioning.

What CDKTF Does

  • Generates Terraform-compatible JSON configuration from imperative code
  • Provides type-safe constructs for every Terraform provider and module
  • Supports all existing Terraform providers without modification
  • Enables code reuse via functions, classes, and package managers (npm, PyPI, Maven)
  • Works with Terraform Cloud and Terraform Enterprise for remote state and runs

Architecture Overview

CDKTF uses the AWS CDK's construct programming model. You write stacks of constructs in your chosen language, and cdktf synth walks the construct tree to emit Terraform JSON into cdktf.out/. From there, cdktf deploy invokes the Terraform CLI for planning and applying. Provider bindings are auto-generated from Terraform provider schemas via cdktf get, producing language-native classes with full type information.

Self-Hosting & Configuration

  • Install the CLI globally via npm; language-specific project templates handle SDK installation
  • cdktf.json at the repo root lists required providers, modules, and Terraform backend config
  • cdktf get generates typed provider bindings into a local .gen directory
  • Remote backends (S3, GCS, Terraform Cloud) are configured in the stack definition
  • CI/CD pipelines run cdktf synth then standard terraform plan/apply for review workflows

Key Features

  • Full IDE support with autocompletion, refactoring, and go-to-definition for infrastructure code
  • Access to the entire Terraform provider ecosystem (AWS, GCP, Azure, Kubernetes, and hundreds more)
  • Construct-level abstraction allows publishing reusable infrastructure libraries
  • Unit testing with standard language test frameworks (Jest, pytest, JUnit)
  • Incremental adoption: import existing Terraform state with cdktf import

Comparison with Similar Tools

  • Terraform (HCL) — Declarative DSL with a mature ecosystem; CDKTF adds imperative flexibility on top
  • Pulumi — Similar concept but uses its own state backend and provider model; CDKTF reuses Terraform providers directly
  • AWS CDK — Imperative IaC for AWS CloudFormation; CDKTF applies the same pattern to any Terraform provider
  • OpenTofu — Community fork of Terraform; CDKTF can target OpenTofu as well
  • Crossplane — Kubernetes-native infrastructure management via CRDs; different operational model

FAQ

Q: Can I mix CDKTF and HCL in the same project? A: Not directly in the same stack, but you can reference HCL modules from CDKTF stacks using TerraformHclModule.

Q: Does CDKTF support Terraform state locking and remote backends? A: Yes. CDKTF stacks configure backends the same way Terraform does, including S3, GCS, Azure Blob, and Terraform Cloud.

Q: How do I test my CDKTF infrastructure code? A: CDKTF provides a Testing utility that lets you snapshot-test synthesized output or assert on specific resource properties using your language's test framework.

Q: Is CDKTF production-ready? A: HashiCorp considers CDKTF generally available since version 0.15+. It is used in production by teams that prefer imperative languages over HCL.

Sources

讨论

登录后参与讨论。
还没有评论,来写第一条吧。

相关资产