Skills2026年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 可直接安装

这个资产可安装;Agent 先选择当前运行时、检查安装计划,再运行匹配命令。

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

先 dry-run 确认安装计划,再运行此命令。

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

讨论

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

相关资产