背景

之前发了一篇《Pulumi 惊艳到我了（还可以无限免费薅 AI 羊毛） - Jeff Tian的文章 - 知乎 》，有人留言希望我分享一下我们对 Pulumi 和别的方案做过的对比。

1710328380287 dcb4d26b 9f2e 4a26 a316 d906905fe284

今天就来分享一下这个对比，希望有参考作用。

正如前文所说，我们之前用过 CloudFormation 甚至纯脚本的基础设施即代码，但是终于有一天受不了了，希望能够转而使用现代化的、更易于维护的方案。这种改变的主要原因有：

  • 使用 CloudFormation 或者其他的基于yaml 或者 json之类的方案，非常难以阅读和维护
  • 抽象级别太低，要使用 CloudFormation 进行稍微复杂一些的构建会非常麻烦。
    • 比如，在 CloudFormation 中写一个条件表达式会非常混乱；又比如，要引用另外一个堆栈也很不直观；再比如，当需要在两个堆栈中共享一些代码时，又或者当需要在多个环境（开发、测试、生产等）中创建相同类型但是在不同环境中属性值不同的多个资源时，也非常困难。所有这些难点，在一种能够使用编程语言的 IaC 框架中，那都不是事儿。

考虑过的方案对比

一共对比了 4 种方案，分别是：

  • Pulumi
  • Terraform CDK
  • AWS CDK
  • CloudFormation
Pulumi Terraform CDK AWS CDK CloudFormation
参考链接 Documentation [CDK for Terraform Terraform HashiCorp Developer](https://developer.hashicorp.com/terraform/cdktf)
优势 + 直观的 API 接口
+ 庞大的社区群体，良好的文档
+ 支持多个云厂商
+ 多种编程语言可供选择，你可以选择你喜欢的
+ 对自动化测试友好		 + 支持多个云厂商
+ 多种编程语言可供选择
+ 对漂移检测支持得很好
+ 对自动化测试友好		 + 对自动化测试友好
+ 新特性更新及时
+ 多种编程语言可供选择
+ 良好的文档		 + 声明式
+ 良好的文档
劣势 + 新特性可能会有滞后
+ 使用 Pulumi Cloud 的价格不够透明		 + 还在 Beta 阶段
+ 不够成熟
+ 新特性可能会有滞后		 + AWS 专有
+ 漂移检测不是最好的
+ 自定义规则写起来太琐碎了
+ 底层还是使用了 CloudFormation		 + 漂移检测不是最好的
+ AWS 专有
+ 慢
+ 只能用 yaml/json
+ 很难抽象
风险 学习曲线有点陡峭 学习曲线有点陡峭 基于了 CloudFormation，从而拥有 CloudFormation 的劣势 团队陷入了yaml/json的泥潭

经过比较后，我们对其进行了采纳的优先级排序：

  1. Pulumi
  2. Terraform CDK
  3. AWS CDK
  4. CloudFormation

其他人对 Pulumi 的意见

我们也咨询了社区里其他使用 Pulumi 的团队，得到如下反馈：

好的方面

  • 易于测试
  • 周围越来越多的人开始使用 Pulumi 了
  • 只需要少量 yaml 代码，就能在诸如 GitHub Actions 的 CI/CD 流水线中运行起来

一个例子：https://github.com/Jeff-Tian/okteto-infra/actions/runs/7524112949/job/20478431724
1710330672289 500e7229 d2a9 4257 8edd a432972a3f09

  • 在简单场景下并不需要使用 Pulumi Cloud
  • 可以将已经存在的基础设施资源及状态导入到自己喜欢的编程语言中
  • 可以使用 AWS S3 作为状态的备份
  • 可以和代码仓库做深度集成，比如每次提交 PR 后，自动预览变化。

1710331025258 d29a08fd 222b 4840 a917 d50fe7b24823

不好的方面

  • Bug 比 Terraform 多 —— Pulumi 尝试集中力量赶上 Terraform 所拥有的功能，所以可能在 BUG 修复上慢了一些
  • Pulumi Cloud 可能并不便宜，起码价格并不透明（听说有的团队在使用，需要一年支付 1 万美元）
  • 听到有人说 Pulumi 其实比 CloudFormation 更慢，可能是由于不像其他的 IaC 框架，它的堆栈状态验证发生在操作之间，而不是在所有的操作开始之前。

关于 Pulumi Cloud

Pulumi Cloud 有一些很好的功能：

  • 一目了然的资源可视化

比如这是 Pulumi 的资源地图：
1710332029291 9f955607 1527 4716 bd1f e8efd2ba811e
比以下 AWS 自己提供的好多了：
1710332175760 fa2e0b2b 9e8e 4c6c 83e5 3ab658731b3e

  • 通过 UI 就可以和代码仓库做深度集成

1710332206686 cc07a878 a03a 460a b129 ac427e76948c

  • 部署时的分布式执行器
  • 可以有组织级别的强制策略
  • RBAC 可以和 SSO 绑定

1710330545930 dc12d66a b091 458b 91aa f73d715675fa

  • 在不同的云厂商和不同的账号间提供数据洞察

1710332351966 068fff16 5f15 4d3d 932c 5ceed9632331

最终产出

我们最终采纳了 Pulumi 做为 IaC 框架，但是决定不使用 Pulumi Cloud。不使用 Pulumi Cloud 的原因是在我们的使用场景中，只会用到它的堆栈状态存储，从而一年 1 万美元的价格就显得太贵了。

1710331553327 abd13f43 5721 4efa 9b3a e07a8654035a

额外的好处是，可以按需创建和销毁资源。我能想到的一个常见场景是，做个定时任务，每天上班定时创建出资源并部署测试环境，下班后自动销毁，从而可以节约成本。