24-IaC生态扩展

Terraform 不是 IaC 的唯一选择。2023 年 HashiCorp 把 Terraform 许可证从 MPL 2.0 换成 BSL（Business Source License）后，IaC 格局发生了分化。本章简要介绍 Pulumi、OpenTofu 及国内云厂商 IaC 工具，给出对比选型参考。

IaC 格局#

维度	Terraform	OpenTofu	Pulumi
开源许可证	BSL（非 OSI 认证）	MPL 2.0（OSI 认证）	Apache 2.0
语言	HCL（DSL）	HCL（兼容）	Go/Python/TS/JS/C#/Java/YAML
Provider 生态	最大	兼容 Terraform provider	包装 TF provider + 原生
托管服务	HashiCorp Cloud	无（社区自建）	Pulumi Cloud
State 后端	S3/OSS/GCS	同 Terraform	Pulumi Cloud / S3 / 其它

三者不是零和博弈，服务不同需求。

Pulumi：代码式 IaC#

Pulumi 的哲学：用通用编程语言描述基础设施，获得类型检查、IDE 补全、单元测试等所有编程语言的好处。

typescript
// index.ts
import * as aws from "@pulumi/aws";

const vpc = new aws.ec2.Vpc("main", {
  cidrBlock: "10.0.0.0/16",
  enableDnsHostnames: true,
  tags: { Name: "production-vpc" },
});

const azs = ["a", "b", "c"];
const privateSubnets = azs.map((az, idx) => {
  return new aws.ec2.Subnet(`private-${az}`, {
    vpcId: vpc.id,
    cidrBlock: `10.0.${10 + idx}.0/24`,
    availabilityZone: `us-west-2${az}`,
  });
});

export const vpcId = vpc.id;
export const privateSubnetIds = privateSubnets.map(s => s.id);

优势：

IDE 补全：写 vpc. 有所有属性提示
类型检查：编译期发现大部分错误
单元测试：可 mock provider，纯单测业务逻辑
复用强：函数、class、npm/pypi/go module

劣势：

Input/Output 异步模型——资源的属性是 pulumi.Output<string> 而不是字符串，需要 apply 处理，初学反直觉
diff 不如 terraform plan 直观
代码 vs 配置——复杂逻辑写嗨了容易过度抽象

OpenTofu：Terraform 的开源续命#

OpenTofu 从 Terraform 最后一个 MPL 2.0 版本（1.5.6）fork 而来，首个稳定版 OpenTofu 1.6.0（2024-01）完全兼容 Terraform 1.5.x。项目由 Linux Foundation 托管、2025-04 进入 CNCF。此后两者开始分叉，OpenTofu 加了一些 Terraform 没有的特性：

State Encryption（原生）#

hcl
terraform {
  encryption {
    key_provider "aws_kms" "key" {
      kms_key_id = "arn:aws:kms:us-west-2:1234:key/..."
      region     = "us-west-2"
    }
    method "aes_gcm" "standard" {
      keys = key_provider.aws_kms.key
    }
    state {
      method   = method.aes_gcm.standard
      enforced = true
    }
  }
}

Terraform 的 state 加密只能靠 backend（S3 SSE），颗粒度更粗。

Early Variable Evaluation#

hcl
# OpenTofu 允许，Terraform 报错
module "network" {
  source = "./modules/${var.environment}-network"
}

Provider iteration#

hcl
provider "aws" {
  for_each = toset(["us-west-2", "us-east-1", "eu-west-1"])
  alias    = "by_region"
  region   = each.value
}

Terraform 至今不支持。

迁移成本#

改 CLI 名字（tofu init 替代 terraform init），大部分项目开箱即用。registry.opentofu.org 是 Terraform registry 的 proxy，99% 的 provider 可直接用。

国内云厂商 IaC 工具#

阿里云 ROS（Resource Orchestration Service）#

阿里云原生的 IaC 服务，类似 AWS CloudFormation：

模板用 JSON/YAML 描述资源栈
支持资源编排、资源栈组（StackGroup）多账号部署
与阿里云控制台深度集成
适合纯阿里云环境、不想引入额外工具的团队

腾讯云 TIC（Tencent Infrastructure as Code）#

腾讯云的 IaC 服务，支持 Terraform、Ansible、CloudFormation 模板：

统一管理多云资源
提供可视化模板编辑器
适合腾讯云为主的环境

与 Terraform 的关系#

阿里云和腾讯云都有 Terraform Provider（alicloud、tencentcloud），用 Terraform 管理国内云资源完全可行。原生工具的优势在与控制台集成和官方支持，Terraform 的优势在跨云统一和生态丰富。

跨工具协作#

真实场景下多种 IaC 工具共存是常态：

text
Terraform/OpenTofu    → 云基础设施（VPC、ECS、RDS、安全组）
Ansible               → 机器配置（装 Docker、改内核参数、部署应用）
Helm/Kustomize        → K8s 应用
Pulumi（可选）         → 需要复杂逻辑的基础设施（如动态生成的资源拓扑）

协作要点：

各工具管各的领域，不要重叠（Terraform 创建 ECS，不要让 Ansible 也去创建）
通过输出传递——Terraform 输出 ECS IP 列表，Ansible 动态 Inventory 读取
State/Inventory 分离——每个工具有自己的状态存储，不交叉

选型建议#

场景	推荐
50 人以下团队、早期创业	OpenTofu（生态成熟、许可证清晰）
已有 Terraform 深度使用	继续 Terraform，或迁 OpenTofu（成本低）
新项目、团队有强编程能力	Pulumi（类型、测试、IDE 支持）
纯阿里云/腾讯云环境	原生 ROS/TIC 或 Terraform Provider
K8s 为主的平台	Pulumi 或 Crossplane
多云一致性优先	OpenTofu（provider 生态最全）

小结#

Terraform 一家独大的时代过去了。OpenTofu 接住了开源那部分，Terraform 继续做 HashiCorp 的商业产品，Pulumi 是代码式 IaC 的小众但坚挺路线。国内云厂商的 ROS/TIC 适合纯单云环境。选型没有"哪个最好"，只有"哪个最适合你团队"——核心看团队已有技能栈、许可证要求、生态依赖。不管选哪个，核心实践都一样：state 远端存储 + lock + PR 驱动的 plan + 强制 policy 检查。工具只是载体，流程才是关键。