Marin Pulumi基础设施即代码：一个Stack管理全部云资源的终极方案-育师

Marin Pulumi基础设施即代码：一个Stack管理全部云资源的终极方案

【免费下载链接】marinOpen-source framework for the research and development of foundation models.项目地址: https://gitcode.com/GitHub_Trending/ma/marin

Marin 是用于基础模型研究与开发的开源框架，其 infra/pulumi/ 目录用Pulumi 基础设施即代码（IaC）实现了「一个 Stack 管理全部云资源」：每个训练集群一个 Stack，一条pulumi up就能统一创建和管理 CoreWeave 与 GCP 上的 RBAC、预留 GPU 节点池、Kueue 调度对象、网关入口、DNS、静态 IP、负载均衡和全部 IAM 权限。

🧩 为什么基础模型项目需要 IaC

训练大模型的基础设施不是几台虚拟机，而是几十种异构资源：Kubernetes RBAC、按机架预留的裸金属 NodePool、Kueue 队列、Traefik/cert-manager 网关、Cloudflare CNAME、GCP 静态 IP、GCLB/IAP 入口、防火墙规则、镜像仓库、IAM 授权……

如果靠控制台手工点击，会迅速失控：资源没有版本、变更无法审计、新集群复制全靠人肉。Marin 的方案是把这一切写进 infra/pulumi/ 里的 Python 代码，并确立一条铁律——Pulumi 是这些资源的唯一属主（sole owner）：

Iris 不再为这些资源做任何开通动作，它只检查资源是否存在；缺失时直接报错，提示你用pulumi up修复。（见 infra/pulumi/README.md）

这意味着云上现状永远可以回答一个问题：它是否和代码一致？

🗂️ 一个 Stack、一个集群：资源布局速览

Stack 文件是每个集群的一个三行指针，例如 Pulumi.cw-rno2a.yaml：

config: marin-iac:cluster: cw-rno2a secretsprovider: gcpkms://projects/hai-gcp-models/.../cryptoKeys/marin-iac-key

当前共有 5 个 Stack：4 个 CoreWeave 集群（cw-us-west-04a、cw-us-east-02a、cw-rno2a、cw-us-east-08a，其中 08a 是 GB200）加 1 个 GCPmarinStack，对应 infra/pulumi/Pulumi.yaml 中的项目marin-iac。各文件职责一目了然：

文件 / 目录	职责
infra/pulumi/main.py	Pulumi 入口，调用`build_stack()`
infra/pulumi/src/iac/program.py	Stack 声明主逻辑，按 provider 分发到 CoreWeave / GCP
infra/pulumi/src/iac/config.py	`provisioning:`段的强类型 schema 与校验
infra/pulumi/src/iac/coreweave/	集群、RBAC、Kueue、Traefik、DNS 组件
infra/pulumi/src/iac/gcp/	静态 IP、GCLB/IAP、防火墙、镜像仓库、IAM
infra/pulumi/import_resources.py	批量纳管线上存量资源的交易文件生成器
infra/pulumi/iam_principal.py、infra/pulumi/iam_audit.py	加密 IAM 主体管理、密钥批量轮换
infra/pulumi/tests/	13 个测试文件覆盖 IAM、GCLB、NodePool 等组件

🔁 读懂 Stack 声明：从 4 行入口到一整个集群

入口main.py 只有十几行，核心是 program.py 里的build_stack()：

从 Stack 配置读出marin-iac:cluster，即目标集群名；
加载该集群在 lib/iris/config/ 中已评审的集群配置（如lib/iris/config/cw-rno2a.yaml的provisioning:段），并用 config.py 做强类型校验——故意不读操作者本地覆盖目录，保证生产计划可复现、可审查；
按 provider 分发：CoreWeave 集群声明控制器 RBAC、由scale_groups推导出的预留 NodePool（nodepools.py）、Kueue ClusterQueue、Traefik/cert-manager 入口栈与 Cloudflare CNAME；GCPmarin集群声明联邦出口静态 IP、Artifact Registry 拉取镜像、共享 GCLB/IAP 入口和全部仓库托管的 IAM 授权。

这套「Stack 只是指针、真相来自已评审集群配置」的设计，让新增一个集群的成本降到：写一份集群配置 + 加一个三行 Stack 文件。

此外，iac包还沉淀了可复用的服务组件：iac.gcp.cloud_run（被infra/echo、infra/evaldash、infra/grafana复用）、iac.iris（被infra/ducky、infra/xprof复用）和iac.kubernetes.finelog（被 infra/finelog 复用），使多个基础设施项目共享同一套经过验证的构建块。

🚀 日常操作三连：preview / up / import

先读 diff 再动手的安全变更流

cd infra/pulumi pulumi stack select <cluster> pulumi preview # 先读 diff pulumi up # preview 干净后才执行

有一条红线：NodePool 的replace或delete绝对不允许放行——那意味着拆除一整个预留裸金属机群。发现破坏性 diff 时停下，让代码与现实对齐，而不是强推pulumi up（见 README.md）。

一条命令纳管存量资源

Marin 遵循 Pulumi 的 Program-first 批量导入流程：先在代码里声明资源，用 import_resources.py 生成「交易文件」，apply时会重新校验文件是否过期、打印 SHA-256 摘要确认，并默认启用删除保护——把「接管线上资源」这件高危操作变成一次可审查、可回滚的确定性流程。

密钥与身份永不进状态

签名密钥、IAP OAuth 密钥等材料被刻意排除在 Pulumi 状态之外（README 的 "Unsupported" 一节）；IAM 主体邮箱则以 KMS 密文形式存放在 iam_data.yaml 的human-NNN匿名 ID 下，配合add-grant/review-grant工作流，个人邮箱永远不会以明文出现在公开仓库。

🛡️ 状态与密钥：GCS + KMS 的不对称权限设计

状态后端：gs://marin-iac-state/（us-central1、开启版本控制）；
密钥提供者：GCP KMS 密钥marin-iac-key，权限不对称——CI 只持有cryptoKeyDecrypter（能预览、不能写入），执行pulumi up的运维才额外拥有加密权限；
CI 纪律：infra/pulumi/ 的 CI 工作流对每个 Stack并行跑pulumi preview并聚合为一条 PR 评论，且永远不执行pulumi up——CI 服务账号本身就只有只读权限，制度与权限双重兜底。