• 数据工程
• 后端
• 云原生
• 任务调度
• 微服务

本指南围绕 Pachyderm 仓库中 CI 基础设施的 Pulumi dev1 测试栈（Pulumi.dev1.README.md）展开，说明其定位、环境变量与配置项、资源标签规范，并深入对应 Go 源码（cluster.go / database.go / app.go / storage.go / main.go）讲解它在 AWS 上如何编排 EKS 集群、RDS PostgreSQL、S3 存储桶并部署 Pachyderm Helm Chart。读完本文，你将理解如何在本仓库外正确执行pulumi up验证基础设施即代码（IAC）改动，并掌握 dev1 栈中全部可覆写配置与敏感信息注入方式。

dev1 栈的定位：Pulumi IAC 自身的测试环境

Pulumi 目录etc/testing/circle/workloads/pulumi/aws/承载了 Pachyderm 核心（core）项目在 AWS 上的多套 Pulumi 栈，包含 dev1、qa1～qa4、LOAD1～LOAD4 等。其中dev1（Dev 1）栈在文档中被明确标注为：

Used for testing pulumi infra changes for the pulumi core project.

它的核心用途是测试 Pulumi IAC 本身——即对etc/testing/circle/workloads/pulumi/aws/下 Go 基础设施代码的改动。与 QA、LOAD 等由 CI 驱动的栈不同，dev1 栈的pulumi up通常在本地手动执行，而不是由 CI 触发。这样做的价值在于：任何针对 IAC 的修改（例如新增 AWS 资源、调整 Helm values、修改 EKS 集群参数）都可以先在 dev1 上跑通、验证行为正确后，再合入并被其他正式栈复用。

因此使用 dev1 栈前有一条重要的协作约定（文档原文强调）：

ITS A GOOD IDEA TO ASK IF ANYONE ELSE IS USING THIS STACK. You can always create a DEV2 etc if needed.

即：执行前应先确认当前没有其他成员正在占用 dev1 栈，避免相互干扰；若占用中，可以自行创建 dev2 等新栈。这与 Pulumi 的**栈（stack）**机制完全一致——Pulumi.yaml声明项目名与运行时，Pulumi.yaml 中name: core、runtime: go、description: Houses pachyderm core stacks，而每个栈（dev1、qa1、LOAD1 等）通过各自的Pulumi.<stack>.yaml与Pulumi.<stack>.README.md文件区分。

基础设施部署流程与入口

从源码结构看，dev1 栈的完整部署由 main.go 的DeployResources()编排，其调用链为：

1. DeployCluster(ctx)（cluster.go）：创建 VPC、EKS 集群、Kubernetes Provider、EBS CSI 驱动及 IAM 角色；
2. DeployRDS(ctx)（database.go）：创建 RDS PostgreSQL 实例与 dex 数据库；
3. DeployBucket(ctx)（storage.go）：创建 S3 存储桶；
4. DeployApp(ctx, ...)（app.go）：在集群中部署 Pachyderm Helm Chart 并注入各类配置。

此外，main.go末尾还有一个与本文档直接相关的细节：它会读取与当前栈同名的 README 文件（./Pulumi.%s.README.md，%s为ctx.Stack()），并将其作为readme输出导出。也就是说，Pulumi.dev1.README.md这份文档不仅是使用说明，还会在pulumi up后作为栈输出暴露给用户查看，方便随时核对栈的用途与注意事项。

必填环境变量：敏感信息只在本地注入

dev1 文档指出，测试数据库密码必须以 Pulumi secret 方式设置，且绝不能提交到代码仓库；CI 场景下该值由 CircleCI 的私有环境变量保存。本地执行时需要手动注入：

pulumi config set --secret rdsPGDBPassword $IAC_CI_DB_PASSWORD

--secret标志会将密码以密文形式写入Pulumi.dev1.yaml，读取时自动解密，避免明文落盘。这一点与源码中的读取方式严格对应：在 database.go 中通过cfg.RequireSecret("rdsPGDBPassword")读取，用于 RDS 实例的Password字段；在 app.go 中同样以cfg.RequireSecret("rdsPGDBPassword")注入 Helm values 的global.postgresql.postgresqlPassword与postgresqlPostgresPassword。RequireSecret表明该配置为强制的 secret 配置——若缺失，部署会直接失败。

另一个必填的环境变量是ENT_ACT_CODE，即测试用的企业版激活码：

$ENT_ACT_CODE- Test enterprise env variable key needs to be set locally from where ever thepulumi upis called from.

它必须在执行pulumi up的本地环境中预先导出。源码印证：在 app.go 中，enterpriseKey := os.Getenv("ENT_ACT_CODE")，若为空会直接返回错误need to supply env var ENT_ACT_CODE，部署中止。

除文档点名的rdsPGDBPassword与ENT_ACT_CODE外，从 app.go 可以看出，本地执行 dev1 栈实际上还需要一组环境变量（这些变量同样通过os.Getenv读取且缺失即报错）：AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、BIGQUERY_AUTH_JSON（写入 metrics secret）、CF_WP_LOADTEST_AWSKEYID、CF_WP_LOADTEST_ENDPOINT_URL、CF_WP_LOADTEST_AWSACCESSKEY、ISSUER_URI、CLIENT_ID、CLIENT_SECRET、TLS_CRT、TLS_KEY（用于 workspace 通配符 TLS 证书）。测试用例 main_test.go 中正是为每个栈统一 mock 了这些变量，可作为本地执行前的环境清单参考。

可覆写配置项与默认值

dev1 文档列出两个可通过pulumi config set覆写的配置：

pulumi config set pachdVersion << pachdVersion >> pulumi config set helmChartVersion << helmChartVersion >>

• pachdVersion：Pachyderm 主镜像pachd的镜像 tag。源码中cfg.Try("pachdVersion")读取，缺省默认2.5.3（见 app.go），最终写入 Helm values 的pachd.image.tag。
• helmChartVersion：Pachyderm Helm Chart 的版本号。读取后为空字符串时，helm.NewRelease不指定Version，直接安装https://helm.pachyderm.com仓库中pachydermChart 的最新可用版本；非空则显式指定版本（见 app.go）。

此外，dev1 栈实际的Pulumi.dev1.yaml仅包含一条配置：

config: aws:region: us-west-2

即 AWS 区域固定为us-west-2（美西二区），这也与 app.go 中 S3 存储 URL 的?region=us-west-2参数一致。除文档明确提及的两个配置外，从源码可整理出该栈支持覆写的其他常用配置及其默认值，均通过pulumi config set <key> <value>设置：

这些配置值通过config.Try*系列 API 读取，任何一项缺省时都会回落为上表默认值，因此本地测试时可以只覆写关心的项。

资源标签规范：可追踪计费与归属

dev1 文档要求为所有资源打上标签，以便追踪计费与使用情况。文档给出的 Go 代码片段如下：

Tags: pulumi.StringMap{ "Project": pulumi.String("Feature Testing"), "Service": pulumi.String("CI"), "Owner": pulumi.String("pachyderm-ci"), "Team": pulumi.String("Core"), },

这份标签并非只存在于文档示例中，而是贯穿了整个 Pulumi 代码库的所有 AWS 资源。可以看到，cluster.go 中 VPC（ec2.NewVpc）、EKS 集群、IAM 角色、EBS CSI Addon 都带有完全一致的Tags；database.go 的 RDS 实例与 storage.go 的 S3 存储桶同样如此。

其中值得注意的一点是：dev1 文档示例只列出 4 个标签键，而源码中实际实现会在上述基础上额外追加"Environment": pulumi.String(ctx.Stack())，即用当前栈名（如dev1）标记环境。这意味着通过 AWS 控制台的标签筛选，可以按Team=Core、Environment=dev1等维度快速定位某一套测试栈的全部资源，进而核算该栈的云成本与资源占用，这正是文档强调"track billing and usage"的实际落地方式。

dev1 栈在 CI 测试体系中的位置

为了更准确地理解 dev1 栈的使用场景，可以将其与同目录其他栈的 README 对照：

• Pulumi.qa1.README.md 表明 QA 栈用于 "sanity aws example release tests"，即发布前的 AWS 冒烟/示例发布测试；
• dev1 则是用于 "testing pulumi infra changes"，即验证 IAC 代码本身的改动。

二者形成互补：IAC 改动先在本地 dev1 栈验证 → 合入代码后由 CI 在 QA/LOAD 等栈运行正式测试。测试用例 main_test.go 也会遍历dev1、LOAD1～LOAD4、qa1～qa4全部栈，使用 Pulumi mock 与 terratest 渲染 Helm Chart 并校验部署逻辑（其中以"project:rdsPGDBPassword": "x"注入测试密码），从侧面印证 dev1 与其他栈共享同一套 IAC 代码、仅通过配置与环境变量区分行为。

本地执行 dev1 栈的推荐流程

综合文档与源码，可总结出在本地执行 dev1 栈验证 IAC 改动的完整流程：

1. 确认栈空闲：与团队确认 dev1 未被他人占用，必要时按文档建议新建 dev2。
2. 设置必填环境变量：在终端导出ENT_ACT_CODE，以及 app.go 中校验的 AWS、OIDC、TLS、指标等环境变量。
3. 注入数据库密码：

   pulumi config set --secret rdsPGDBPassword $IAC_CI_DB_PASSWORD

4. 按需覆写配置（可选）：

   pulumi config set pachdVersion 2.5.3 pulumi config set helmChartVersion 2.5.3

5. 执行部署：在etc/testing/circle/workloads/pulumi/aws/下运行pulumi up --stack dev1。部署完成后，main.go会将本 README 作为readme输出导出，方便核对。

需要说明的是，dev1 栈是 Pachyderm 团队内部的 CI 基础设施环境，其 AWS 凭据、企业激活码等敏感信息由团队内部管理与提供；本文仅就仓库内文档与源码说明其配置方法与运行机制，供读者理解该 IAC 工程的组织方式。

总结

dev1 栈是 Pachyderm 核心项目验证 Pulumi IAC 改动的前置环境：通过pulumi config set --secret rdsPGDBPassword与ENT_ACT_CODE等环境变量注入敏感信息，通过pachdVersion、helmChartVersion等配置控制部署内容，通过统一的Project / Service / Owner / Team / Environment标签管理计费与资源归属。其对应的 Go 源码（cluster.go、database.go、storage.go、app.go）展示了从 EKS 集群、RDS 数据库、S3 存储到 Helm Chart 部署的完整 AWS 基础设施编排，是理解 Pachyderm CI 基础设施如何"以代码管理基础设施"的最佳示例。

• 数据工程
• 后端
• 云原生
• 任务调度
• 微服务