Pulumi 是开源的基础设施即代码（IaC）平台，核心思路是让工程师用自己熟悉的通用编程语言——TypeScript、Python、Go、C#、Java 或 YAML——来定义云资源，而不是学习一套专用 DSL。它覆盖 AWS、Azure、GCP、Kubernetes 以及各类托管服务，提供资源声明与增量编排、状态管理、密钥加密、多环境 Stack、策略即代码（Policy as Code）、自动化 API 与 ESC 环境管理。相比 HCL 类工具，Pulumi 的最大差异在于语言表达力：循环、条件、函数、类与单元测试可以直接服务于基础设施代码，适合已有编程背景的 DevOps、平台工程与 SRE 团队。本文从安装开始，带你 10 分钟跑通第一个示例，再深入核心能力、生产部署与工具选型，最后用常见误区和面试题收尾。
掌握 Pulumi 意味着你可以直接复用团队的 Go/TS/Python 技能来组织云资源，这是 IaC 工具选型评估与平台工程岗位面试中的高频加分项。
目录
速览卡是工具类内容的固定首屏模块：30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 Pulumi：DSL 表达力不足 → 用语言定义目标状态
Terraform 的 HCL、CloudFormation 的 JSON/YAML 这类专用 DSL 在表达循环、条件分支、函数复用上能力有限。中等复杂度的多环境配置常演变成大段复制粘贴，团队还需要另外维护生成器、包装脚本和模板才能拼出可维护的 IaC 代码。类型约束几乎为零，错误通常要到 plan 阶段才暴露。
Pulumi 把资源声明直接嵌入通用编程语言：批量创建用 for 循环，分支用 if，公共逻辑抽成函数与类，规范可以通过类型定义约束。同一套语言还能直接编写单元测试（pytest、jest），在部署前验证资源输出与依赖关系。需要澄清的是，代码运行只是“描述目标状态”的手段，真正执行变更的是 Pulumi 引擎——它与上次状态做对比，只对差异部分做增量创建、更新或删除，这与 Terraform 的 plan/apply 本质相同。
与同类工具相比，Pulumi 的定位是“多云 + 语言中立”：不绑定任何云厂商，也不要求团队学新语法。它面向的是已经会写代码、但不想再学一套 DSL 的工程团队，属于“语言即 DSL”路线。
安装与环境配置：3 步就绪
步骤一 · 安装 CLI：macOS/Linux 使用官方安装脚本，脚本会把可执行文件安装到 ~/.pulumi/bin 并提示加入 PATH；Windows 推荐 winget，也可以使用官方 PowerShell 脚本或 Chocolatey。
步骤二 · 配置云凭证：按目标云平台设置身份认证。AWS 用 aws configure 或环境变量 AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY；Azure 用 az login；Google Cloud 用 gcloud auth application-default login。生产环境推荐使用 OIDC 联邦身份换取短期临时凭证，而不是长期密钥。
步骤三 · 验证安装：执行 pulumi version 确认版本号正常输出，再执行 pulumi login 选择状态后端（默认本地文件，后续可切到 Pulumi Cloud 或对象存储）。
# macOS / Linux：官方安装脚本curl -fsSL https://get.pulumi.com | sh # Windows：winget 或官方脚本winget install Pulumi.Pulumi# 或iwr -useb https://get.pulumi.com/install.ps1 | iex # 验证与登录pulumi versionpulumi login # 默认本地后端；也可指定 https://app.pulumi.com 或 s3://bucket # 配置云厂商凭证（以 AWS 为例）aws configure
快速上手：10 分钟部署第一个 S3 存储桶
最小可用流程的核心思路是三步：初始化项目骨架 → 在入口文件中声明资源 → 用 pulumi up 完成预览与部署。
步骤一 · 创建项目：执行 pulumi new aws-python（也可用 aws-typescript）。向导会依次询问项目名、Stack 名（建议输入 dev）和 AWS region；模板会自动创建 Python 虚拟环境并安装 pulumi 与 pulumi-aws 依赖。
步骤二 · 编写资源：打开生成的 __main__.py，定义一个私有 S3 存储桶，并用 pulumi.export 导出存储桶名称供下游使用。
步骤三 · 部署与清理：执行 pulumi up，引擎先输出 preview（将创建哪些资源），确认后输入 yes 完成部署；pulumi stack output bucket_name 可查看导出值；pulumi destroy 按需清理全部资源。
进阶技巧：pulumi config set region cn-north-1 可随时调整配置；同一项目可以再创建 staging、prod 等 Stack，各环境状态相互独立。
# requirements.txt 已由模板生成：pulumi、pulumi-awsimport pulumiimport pulumi_aws as aws # 声明一个私有 S3 存储桶bucket = aws.s3.Bucket( "demo-bucket", acl="private", tags={"Owner": "platform", "Env": "dev"},) # 导出存储桶名称，供其他系统消费pulumi.export("bucket_name", bucket.bucket)
pulumi up # 先看 preview，确认后输入 yespulumi stack output bucket_name # 查看导出值pulumi destroy # 清理该 stack 下的全部资源
核心能力详解：5 大支柱
支柱一 · 多语言多云 SDK。Pulumi 为 AWS、Azure、GCP、Kubernetes 等平台提供官方 SDK，语法与语义保持一致：写 AWS 资源的方式和写 Azure、K8s 资源的方式相同。Provider 分为两类：原生 Provider（深度优化）与基于 Terraform 桥接层的 Provider（可复用大量 Terraform Provider 生态）。团队已有的语言技能可以直接迁移到云资源管理上。
支柱二 · 状态管理与 Pulumi Cloud。状态文件记录全部资源图与最近一次部署结果，是 IaC 的“账本”。引擎通过对比状态与代码来计算增量变更。Pulumi Cloud 提供托管状态、并发锁、部署历史与审计；不依赖 SaaS 时，也可以用 S3、Azure Blob、GCS 或本地目录作为自托管后端，密钥字段通过用户口令或云 KMS 派生密钥加密。
支柱三 · Stack 与环境划分。Stack 是“同一份代码 + 独立状态”的环境实例：一个项目可以同时维护 dev、staging、prod 三个 Stack，互不干扰。环境差异通过 pulumi config set 键值注入，敏感值加 --secret 参数加密保存。Pulumi ESC 进一步把环境变量、云凭证与配置集中管理，供多个项目复用。
支柱四 · Automation API。这是 Pulumi 区别于多数 IaC 工具的关键能力：允许在 Python、TypeScript、Go 等应用进程内以代码方式调用 preview、up、destroy。平台团队可以把基础设施操作封装成自服务 API 或 CI 任务，实现按需创建临时环境、动态部署、多租户隔离的“平台即产品”。
支柱五 · 策略与测试。Policy as Code 允许用 TypeScript/Python 编写策略包（Policy Pack），在部署前强制校验标签规范、安全组配置、成本约束等合规要求；策略可在组织级与 stack 级生效。同时，由于代码是通用语言，可以写单元测试验证资源输出属性与依赖关系，把错误拦截在部署之前。
生产部署与监控：从上线到运维
CI/CD 集成。生产部署的默认路径是流水线而非本机：GitHub Actions、GitLab CI 可按事件触发 pulumi preview 与 pulumi up。典型做法是 PR 阶段只执行 preview 并让团队成员审查变更，合并到主分支后再执行部署，并在部署后运行测试验证资源可用性。
状态后端选型。生产环境需要明确的“账本”策略：Pulumi Cloud 托管状态自带并发锁、审计日志与 Insights 资源搜索，适合多数团队；自托管 S3/Azure Blob/GCS 后端要自行解决并发锁、密钥加密与高可用备份。无论哪种后端，都应定期备份状态文件并演练恢复流程，这是 IaC 事故恢复的关键。
可观测性。pulumi refresh 会在部署前把线上实际资源与状态对齐，pulumi preview --diff 可逐条审查属性级变更；Pulumi Cloud 的 Insights 支持跨 Stack 搜索资源、追溯变更历史、发现未受管资源。部署后的运行监控仍依赖云厂商原生监控告警（CloudWatch、Azure Monitor 等），IaC 层关注的是“谁在何时改了什么、是否符合策略”。
<p class="para-label">避坑清单：</p>
<ul class="dash-list"><li>密钥管理：不要将数据库口令、私钥硬编码进代码——字符串字面量不会自动加密；使用 pulumi config set --secret、ESC 或云 Secrets Manager 注入，并确保日志与 preview 输出不打印 secret 值。</li><li>并发与状态：多人同时对一个 Stack 执行 pulumi up 会互相踩踏；Pulumi Cloud 提供完整的并发锁与历史审计，自托管后端要自行确认锁机制，并定期备份状态、演练恢复。</li><li>升级顺序：升级 CLI 或 Provider 前先跑一次 pulumi preview 处理废弃警告；大版本（如 v3 到 v4）会提高运行时最低版本要求，需先评估 CI 与本地环境兼容性。</li></ul>
# PR 阶段：只预览不落变更pulumi preview --stack prod # 合并后：执行部署（--refresh 先对齐线上真实状态）pulumi up --stack prod --yes --refresh
| 维度 | Pulumi | Terraform | AWS CDK | AWS CloudFormation |
|---|---|---|---|---|
| 定位 | 通用语言多云 IaC 平台 | HCL 专用语言的多云 IaC | AWS 官方代码式 IaC 框架 | AWS 原生声明式模板服务 |
| 编排范式 | 代码声明目标状态，引擎增量 diff | 纯声明式，plan/apply | 代码合成 CloudFormation 模板 | JSON/YAML 模板原生编排 |
| 类型约束 | 强类型，编译期/语言静态检查 | HCL 弱类型，plan 阶段校验 | 强类型（TS/Python/Java/C#） | 无类型，靠模板校验 |
| 学习曲线 | 中（需会一门编程语言） | 低-中（需掌握 HCL 约定） | 中-高（需理解 AWS 构造模型） | 低-中（模板语法） |
| 生态集成 | 多云 Provider + Terraform 桥接 | 云与第三方 Provider 覆盖最广 | 与 AWS 服务深度集成 | 仅限 AWS 体系 |
| 生产部署 | CLI/CI + Pulumi Cloud 或自托管 | CLI/Terraform Cloud/CI，协作成熟 | CDK Pipelines 一键流水线 | 原生栈操作与内建回滚 |
| License | Apache 2.0 | BUSL v1.1（2023 年起） | Apache 2.0 | 专有托管服务 |
| 适合谁 | 有编程背景的跨云/平台团队 | 存量 HCL 资产多的团队 | AWS 深度用户 | 纯 AWS 最小工具链团队 |
选型建议：如果团队已有大量 HCL 资产与成熟的 Terraform 工作流，继续沿用 Terraform 最稳妥；如果团队以软件开发为主、需要跨云统一建模，或要构建自服务平台（Automation API）与策略治理，Pulumi 是更匹配的选择。AWS 独占且追求少学一套工具时，AWS CDK 值得考虑；纯模板诉求、无编程背景的 AWS 团队可直接用 CloudFormation。
版本迭代
Pulumi 自 2018 年推出预览版，2019 年发布 1.0 正式版确立“语言即基础设施”方向，2021 年 3.0 完成架构级重构，2023-2024 年在 3.x 生命周期内补齐 ESC、Insights 等平台治理能力，2025 年 4.0 完成废弃项清理与运行时升级（截至训练数据，可能已有更新版本）。
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| v1.0.0 | 2019-09 | 首个 GA 正式版 | TypeScript/Python/Go SDK 进入生产可用，确立“通用语言定义基础设施”模式 |
| v2.0.0 | 2020 | 工程化能力扩展 | 逐步引入 Automation API 等应用内编排能力，改进 CLI 与多语言体验 |
| v3.0.0 | 2021-07 | 架构级重构与平台化 | 更快的同步与状态处理、更清晰的错误信息；3.x 生命周期内陆续上线 Pulumi ESC（环境/密钥/配置）与 Insights（资源搜索与审计） |
| v4.0.0 | 2025 | 大版本清理与体验整合 | 提高运行时最低版本要求、清理 3.x 累积的废弃参数，重构 CLI 与平台集成体验 |
Pulumi 的版本主线是从“写得出”走向“治理得好”——1.0 解决表达能力，3.0 解决性能与平台能力（ESC、Insights），4.0 把长期债务清干净。Pulumi 属于 IaC 工具而非模型产品，没有 MMLU 一类的公开评测分数，社区横向对比主要围绕任务完成时间、状态锁定与多语言体验，尚无权威量化榜单。新项目建议直接从 v4.x 起步；存量 3.x 项目升级前先清理废弃警告并验证 CI 运行时版本。
AI 应用场景
场景一：跨云基础设施统一交付
阶段：多云编排 / 基础设施自动化
解决的问题：多朵云并存时，各家模板与 HCL 各成体系，环境差异靠复制粘贴维护。Pulumi 用同一门语言统一建模，for/if/函数把环境差异收敛为配置项，状态、密钥与策略统一管理。
具体案例：某平台团队把 AWS 与 Azure 上的网络、存储与计算资源收敛到同一个 Python 代码库，dev/staging/prod 通过三个 Stack 隔离；新增一个环境从人工操作脚本变为一次 pulumi up，交付耗时从小时级降到分钟级。
场景二：自服务开发环境（Automation API）
阶段：平台工程 / 部署自动化
解决的问题：开发与测试人员等待运维手动建环境是常见瓶颈。Automation API 把 preview/up/destroy 变成可编程调用，嵌入平台后端按需拉起与回收。
具体案例：某公司在 CI 中对每个 PR 创建隔离的测试环境，分支合并后自动销毁。环境生命周期与分支对齐，测试等待时间从小时级降到分钟级，临时资源不再长期空转。
场景三：AI 训练与推理基础设施
阶段：AI 基础设施自动化 / 资源编排
解决的问题：GPU 集群、节点池、存储与模型服务的多步创建难以手工维护。Pulumi 可用 TypeScript 或 Python 声明 Kubernetes 集群、GPU 节点池、PVC 与模型服务部署，基础设施与应用变更走同一套代码与审查流程。
具体案例：算法团队用同一份代码管理 EKS GPU 节点池与推理服务，集群扩容与模型版本更新统一走 PR 评审，基础设施变更可复用代码仓库的 CI 检查与回滚机制，环境一致性明显提升。
常见误区
误区官网一进来就引导登录 Pulumi Cloud，估计这工具不开源，不付订阅费根本没法用。
正解Pulumi 核心 CLI 与语言 SDK 是 Apache 2.0 开源项目（GitHub: pulumi/pulumi）。状态既可以交给 Pulumi Cloud 托管，也可以用 pulumi login s3://bucket、Azure Blob、GCS 或本地文件保存。Pulumi Cloud 提供托管状态、并发锁、Insights 搜索等增值能力并有免费额度，但不是使用前提。
为何常见：官网与教程默认引导注册 Pulumi Cloud，操作入口集中在 app.pulumi.com，让新用户误以为必须绑定 SaaS 才能使用。
误区用 Python 写基础设施，那不就是每次执行一遍脚本、资源每次都重建吗？
正解Pulumi 与 Terraform 一样是目标状态声明模型。代码运行产出的是资源意图图，引擎与上次状态对比后只做必要的新增/更新/删除；循环与条件只是描述目标集合的手段，并非逐条执行命令。是否声明式取决于引擎的 diff 收敛机制，与书写语言无关。
为何常见：把“编程语言 = 命令序列”的程序直觉直接套到 IaC 上，忽略了 Pulumi 引擎负责 plan 与收敛这一核心环节。
误区仓库是私有的，把数据库密码直接写在代码里应该没事，反正状态文件别人看不了。
正解硬编码字符串不会自动进入加密链路，任何能读代码仓库的人都看得到；只有标记为 secret 的值（如 pulumi config set --secret 或密文 Output）在状态文件中才会被加密保存。正确做法是用 --secret、ESC 或云厂商 Secrets Manager 注入，并确保日志与 preview 输出不打印 secret。
为何常见：教程示例为了精简常直接写值，新手不知道存在 --secret 参数，也不清楚加密发生在状态层而不是代码层。
误区两边语法完全不同，迁移到 Pulumi 就得把上百个资源一个个人工改写，成本太高了。
正解Pulumi 提供 pulumi convert（可将 Terraform HCL 转换为 Pulumi 项目）与 pulumi import（把现有资源导入状态）；官方 Terraform 桥接层让大量 Terraform Provider 可以直接复用。迁移可以按 Stack 分批进行，不需要一次性重写。
为何常见：只对比了两套语法差异，不了解官方已有的转换工具链与 Provider 桥接机制。
误区反正都是声明资源，换成编程语言只是写法不同，差别不大。
正解语言能力直接决定可表达的复杂度上限：循环批量创建、条件分支、函数抽取、类型约束与单元测试（pytest/jest）在 HCL 中要么不存在要么很别扭。更重要的是 Automation API、策略包与 ESC 这些平台能力，远超“用另一种语言写 plan”的范畴。
为何常见：停留在“模板换皮”的表层理解，没有看到语言层之上的自动化、策略与环境治理能力。
面试题
Q1. Pulumi 与 Terraform 最核心的区别是什么？
- A.使用 YAML 文件描述云资源
- B.使用通用编程语言定义基础设施← 正确答案
- C.只支持 AWS 单一云平台
- D.仅能离线在本机命令行运行
答案：B。Pulumi 的核心卖点正是用通用语言（TypeScript/Python/Go/C#/Java 与 YAML）定义基础设施，而不是 DSL 模板。A 是部分模板型工具的做法，C 与 D 均与事实不符，Pulumi 支持多云且可接入 CI 流水线。
Q2. 创建新 Pulumi 项目使用的命令是？
- A.pulumi init
- B.pulumi new← 正确答案
- C.pulumi create
- D.pulumi setup
答案：B。pulumi new <模板名>（如 aws-python、aws-typescript）负责生成项目骨架，包括 Pulumi.yaml、入口源文件与依赖清单。其余三个命令不是 Pulumi 的合法子命令。
Q3. 关于 Pulumi 的 secret（密钥）管理，正确的说法是？
- A.使用 --secret 参数设置的配置会加密保存← 正确答案
- B.加密密钥由用户口令或托管平台管理← 正确答案
- C.代码中的字符串常量会自动识别加密
- D.导出的输出值全部以明文写入状态
答案：AB。pulumi config set --secret 会把配置标记为 secret 并在状态中以密文保存；自托管后端用口令派生密钥，Pulumi Cloud 则由平台托管密钥。代码中的字符串字面量不会被自动识别为 secret，因此 C 错误；marked-as-secret 的输出同样加密，D 错误。
Q4. 下面哪一项正确描述了 Pulumi 的部署模型？
- A.每次执行都会先销毁再重建全部资源
- B.代码声明目标状态，引擎做增量变更计算← 正确答案
- C.所有资源变更必须人工逐条审批才能执行
- D.支持资源创建与更新，但不支持任何删除
答案：B。Pulumi 引擎保存上一状态，通过对比代码与状态做增量 diff，只对差异执行创建、更新或删除，因此 A 与 D 错误。审批与否取决于团队工作流配置，并非引擎强制，C 错误。
Q5. 下列哪些属于 Pulumi 的核心结构组件？
- A.Project 与 Stack← 正确答案
- B.Resource 与 State← 正确答案
- C.Config 与 Secret← 正确答案
- D.Virtual Machine
答案：ABC。Project 是项目根定义（Pulumi.yaml），Stack 是环境实例，Resource 是被管理云资源，State 保存状态图，Config 与 Secret 管理配置与密钥——它们共同构成 Pulumi 的核心模型。虚拟机监控程序是宿主机层面的概念，与 Pulumi 无关。
Q6. 在 CI 流水线中安全获取云厂商凭证，推荐做法是？
- A.将 AK/SK 明文写入 CI 环境变量
- B.使用云厂商 OIDC 或联邦身份获取临时凭证← 正确答案
- C.使用权限永久的账号并共享给全团队
- D.通过命令行参数在每次执行时手动传入
答案：B。OIDC 或云厂商联邦身份可签发短期临时凭证，避免长期密钥进入仓库或 CI 环境，Pulumi 的各云 Provider 官方支持该配置。明文写入、永久账号共享或命令行传参都会扩大泄露面，均不推荐。
Q7. 关于 Pulumi 的 Stack，正确说法是？
- A.一个项目只能对应固定一个环境状态
- B.同一项目可按环境划分独立状态与资源← 正确答案
- C.Stack 仅用于集中保存长期云凭证
- D.每个 Stack 必须部署在独立云账号中
答案：B。Stack 把同一份项目代码映射到不同环境（dev/staging/prod 等），每个 Stack 拥有独立状态与资源，因此 B 正确、A 错误。Stack 的职责是环境隔离而非凭证存储，C 错误；多 Stack 共享账号是常见做法，D 过于绝对。
Q8. Pulumi Automation API 适合用于哪些场景？
- A.在自服务门户中按需创建临时环境← 正确答案
- B.在 CI 流水线中动态执行基础设施变更← 正确答案
- C.在应用代码中直接调用基础设施操作← 正确答案
- D.在浏览器页面中直接执行云资源操作
答案：ABC。Automation API 允许在 Python/TypeScript/Go 等进程内调用 preview/up/destroy，是自服务环境、CI 动态部署与应用内编排的实现手段。它运行在你的进程里，并非浏览器直接执行，D 错误。
Q9. 关于 Pulumi 的 Provider 生态，正确的是？
- A.Pulumi 完全无法复用 Terraform 生态
- B.Pulumi 提供原生 Provider 与 Terraform 桥接层← 正确答案
- C.Pulumi 只支持 AWS 与 Azure 两个平台
- D.Pulumi 的 Provider 必须由用户全部手写
答案：B。Pulumi 同时维护原生 Provider（AWS/Azure/GCP/K8s 等）与基于 pulumi-terraform-bridge 的桥接 Provider，可复用大量 Terraform Provider，因此 B 正确。A、C、D 均与事实不符。
Q10. 部署前想查看将发生的变更，应执行哪个命令？
- A.pulumi apply 直接应用全部变更
- B.pulumi preview 预览将发生的变更← 正确答案
- C.pulumi config 查看当前配置
- D.pulumi destroy 删除全部资源
答案：B。pulumi preview 在不改动资源的情况下输出将要执行的变更清单，可加 --diff 查看属性级差异，是部署前审查的标准入口。apply 负责执行部署，config 管理配置项，destroy 负责清理资源。
参考来源
- webpagePulumi 官网产品主页与平台能力介绍