Terraform托管服务与原生方案选型对比：状态管理、执行模型与权限体系全解析

1. 从一次真实的选型纠结说起去年年底团队要把一套跑了两年多的机器人仿真与调度平台做基础设施重构。原来的做法是几个人共用一台跳板机手工装依赖、手工改配置、手工记录变更时间一长环境漂移得厉害谁也说不清生产环境到底和文档差了多少。痛定思痛决定上 IaC把整套环境用代码描述出来做到可复现、可审计、可回滚。选型阶段摆在桌面上的方案有两个方向一是直接用原生 Terraform自己管状态、自己搭后端、自己写模块二是用云厂商提供的托管式 Terraform 服务把状态存储、执行环境、权限控制这些脏活累活交给平台。团队里两派意见吵得很凶一派觉得托管省心一派觉得原生可控。最后我们没有拍脑袋而是花了两周时间把两条路都跑了一遍用真实项目做了对照。这篇内容就是那次对照的完整复盘。我会把托管服务和原生 Terraform 在状态管理、执行模型、权限体系、成本结构、迁移路径这几个维度上的差异掰开揉碎讲清楚再给出不同团队规模、不同合规要求下的选择建议。如果你正在纠结 IaC 工具怎么选或者已经用了其中一种但总觉得哪里别扭这篇应该能帮你少走一些弯路。文中涉及的具体参数和配置都是我们实测过的可以直接抄作业。需要先说明一点本文讨论的“托管服务”泛指各类提供 Terraform 运行能力的平台化产品不特指某一家原生方案则以 Terraform 本体和它的开源分支 OpenTofu 为代表。两者底层用的都是同一套 HCL 语法和 Provider 生态差异主要在上层的工程化能力这一点先建立共识后面的对比才不会跑偏。2. 核心差异拆解托管与原生到底差在哪2.1 状态管理这是最本质的分水岭Terraform 最核心的机制是状态文件state它记录了代码里声明的资源和真实基础设施之间的映射关系。谁掌握了状态谁就掌握了整个 IaC 流程的命脉。原生方案里状态文件默认存在本地你得自己决定放哪。放本地磁盘团队协作时必然冲突放对象存储你得自己配锁机制防止并发写坏状态。我们最初的土办法是把 state 传到对象存储用一张数据库表做锁。听起来简单实际跑起来问题一堆锁没释放导致后续 apply 全部卡死、state 文件被误删没有版本回退、多人同时操作时锁的粒度太粗。后来换成托管服务状态存储、加密、版本历史、并发锁全部由平台接管这一块的心智负担瞬间归零。托管服务通常会给每个工作空间workspace独立的状态存储自带加密和访问审计还能看到每次 run 前后的 state diff。原生方案要达到同等效果你得自己搭一套后端S3 加 DynamoDB 锁是最常见的组合配置大概长这样terraform { backend s3 { bucket my-tf-state key prod/network/terraform.tfstate region cn-north-1 dynamodb_table tf-lock encrypt true } }这段配置本身不难难的是背后的运维桶的权限策略、版本控制、生命周期规则、锁表的容量规划、跨区域复制的延迟每一项都是隐性成本。托管服务把这些全部封装掉了你只需要在界面上点几下或者用平台提供的 API 创建工作空间即可。提示如果你的团队只有一两个人且基础设施规模不大原生方案配对象存储后端完全够用一旦超过三个人协作或者资源数量上百托管服务在状态管理上的优势会迅速放大。2.2 执行模型本地跑还是云端跑原生 Terraform 的执行发生在你敲命令的那台机器上。terraform plan和terraform apply用的是本地的 Provider 版本、本地的凭据、本地的网络环境。这意味着每个人的执行结果可能不一致尤其是 Provider 版本没锁死的时候A 同学 plan 出来是新增三个资源B 同学 plan 出来可能是重建五个。托管服务的执行发生在平台的隔离容器里每次 run 都用统一版本的 Terraform 和 Provider环境完全一致。这一点在排查“为什么我这里能过你那里报错”这类问题时价值极高。我们实测下来托管服务的 plan 结果在不同成员之间完全一致而原生方案如果不做严格的版本锁定差异率能到两成以上。不过云端执行也有代价。首先是网络路径变长如果你的基础设施在内网或者私有环境托管平台的执行器可能根本连不上得额外配代理或者自建执行器。其次是调试不便本地跑的时候你可以随时打断、加日志、改环境变量云端跑只能看平台给的日志输出粒度粗很多。我们后来采取的是混合策略日常开发和验证用原生 Terraform 在本地跑正式环境的 apply 走托管服务。这样既保留了本地的灵活性又保证了生产变更的一致性。这个策略不是拍脑袋定的而是踩过坑之后总结出来的——有一次本地 apply 因为 Provider 版本差异把一个安全组规则改错了导致测试环境短暂不可用从那以后生产变更就再也没走过本地。2.3 权限与合规谁能改、改了什么、什么时候改的原生 Terraform 的权限控制基本依赖云平台的 IAM。你给执行者什么权限Terraform 就能操作什么资源。问题在于Terraform 的权限需求往往很大一个 apply 可能涉及几十种资源的增删改很难做到最小权限。而且本地执行时凭据是明文放在环境变量或者配置文件里的泄露风险不低。托管服务一般会提供独立的权限体系把“谁能触发 run”“谁能审批”“谁能看 state”分开控制。审批流是它的一大杀器可以配置成 plan 之后必须有人工审批才能 apply审批记录留痕谁批的、什么时候批的、批的是哪个 commit全部可追溯。这在有合规审计要求的场景下几乎是刚需。我们做过一个对比测试同样是给一个新成员开通基础设施变更权限原生方案需要配 IAM 策略、配后端访问权限、配本地凭据前后花了小半天托管服务只需要在平台上把他加进对应的团队权限自动继承五分钟搞定。当然托管服务的权限模型也有学习成本尤其是自定义角色和策略的时候文档得啃一阵。2.4 成本结构显性账单与隐性人力原生 Terraform 本身是开源免费的OpenTofu 也是。你付出的成本主要是人力搭后端、维护锁、管版本、写 CI 流水线、处理各种边界情况。这些成本不会出现在账单上但会实实在在消耗团队的时间。托管服务按席位或者按 run 次数收费账单是显性的。小团队可能觉得贵但把人力成本折算进去之后很多时候托管反而更划算。我们算过一笔账一个中级工程师月薪按两万算每月花在 IaC 运维上的时间如果超过两天成本就超过大多数托管服务的席位费了。而且托管服务省下来的时间可以投入到更有价值的业务开发上这笔账不能只算表面。不过要注意托管服务的计费模式差异很大。有的按并发 run 数收费有的按管理的资源数量收费有的按 state 存储量收费。选之前一定要把自己的使用模式摸清楚否则很容易出现“以为很便宜结果账单爆炸”的情况。我们见过一个团队因为 CI 里配置了过于频繁的 plan一个月跑了几千次 run账单直接翻了好几倍。2.5 生态与锁定风险别把自己焊死在一棵树上托管服务最大的顾虑是锁定。你在这个平台上积累的工作空间、变量、策略、审批流迁移到另一个平台或者迁回原生方案时都需要重新配置。虽然底层还是 HCL但平台特有的配置项、API、集成方式都是非标准的。原生方案在这方面天然占优state 文件是标准的配置是标准的换后端只需要改几行 backend 配置。OpenTofu 的出现更是给了原生方案一个完全开源的退路不用担心某天上游改协议或者改收费模式。我们的做法是核心的基础设施代码保持平台无关所有平台特有的配置都隔离在薄薄的一层适配里。这样即使将来要换平台迁移成本也可控。具体来说就是把资源定义、变量、输出这些标准 HCL 放在一个目录把后端配置、工作空间映射、审批策略这些平台相关的东西放在另一个目录通过 CI 脚本组装。这个模式跑了一年多切换过一次执行平台迁移只花了两天。3. 实操对照两条路各自怎么落地3.1 原生方案从零搭建的完整步骤先讲原生方案。假设你要在一个新项目里从零搭一套 Terraform 工作流下面是我们实际用过的步骤按顺序来基本不会踩大坑。第一步确定目录结构。我们用的是按环境分目录的方式每个环境一个独立的 stateinfra/ modules/ network/ compute/ envs/ dev/ main.tf backend.tf terraform.tfvars prod/ main.tf backend.tf terraform.tfvars模块放公共逻辑环境目录只放差异化的配置和 backend 定义。这样 dev 和 prod 共享同一套模块但状态完全隔离改 dev 不会影响 prod。第二步配置后端。前面给过 S3 加 DynamoDB 的例子这里补充几个实操细节。桶要开版本控制否则 state 被写坏没法回滚锁表的主键必须是LockID这是 Terraform 的约定桶的权限策略要限制到具体的 IAM 角色不要图省事给整个账号。我们踩过的坑是锁表的读写容量按最低配设的结果并发 plan 一多就限流后来改成了按需模式才稳定。第三步锁定版本。在terraform块里显式声明 required_version 和 provider 版本terraform { required_version 1.5.0, 2.0.0 required_providers { aws { source hashicorp/aws version ~ 5.0 } } }版本范围不要写太死也不要完全不锁。~这种写法允许补丁版本升级但不允许大版本跳跃是比较稳妥的选择。我们有一次没锁 provider 版本上游发了个大版本把某个资源的参数名改了CI 直接红了一片。第四步搭 CI 流水线。核心是把 plan 和 apply 分开plan 在 PR 阶段跑结果贴到 PR 评论里apply 在合并到主分支后跑需要人工确认。我们用的是一个简单的脚本先terraform init再terraform plan -outtfplanapply 的时候直接terraform apply tfplan保证 apply 的就是 plan 过的那份计划不会因为中间有人改了代码而漂移。第五步配凭据。本地开发用临时凭据CI 里用 OIDC 联邦避免长期密钥落盘。这一步很多团队会偷懒直接用长期 AK/SK一旦泄露后果很严重。OIDC 配置起来稍微麻烦一点但一次配好长期受益。3.2 托管服务的接入流程与关键配置托管服务的接入流程和原生方案有重叠但重心不同。原生方案你花大量时间在后端和 CI 上托管服务你花时间在工作空间组织和权限策略上。第一步创建工作空间。大多数托管平台的工作空间对应一个 state命名建议和环境、业务域挂钩比如prod-network、dev-compute。工作空间之间可以通过平台的 API 互相引用输出但不要搞太复杂的依赖链否则一个工作空间挂了会牵连一片。第二步连接代码仓库。托管平台一般支持直接对接 Git 仓库指定分支和目录有 push 或者 PR 时自动触发 run。这里要注意触发规则别配成任何分支的任何改动都触发否则 run 次数会失控。我们的配置是主分支 push 触发 apply 候选PR 触发 plan其他分支不触发。第三步配置变量。托管平台的变量分两类一类是 Terraform 变量tfvars一类是环境变量比如云平台的凭据。敏感变量要标记为 secret平台会加密存储日志里也会脱敏。我们踩过的坑是把一个包含密钥的变量标成了普通变量结果在 run 日志里明文打印出来了虽然平台有访问控制但还是惊出一身冷汗。第四步设置审批策略。生产环境的工作空间一定要开人工审批plan 完成后停在待审批状态有人确认才继续。审批人最好是两个人以上避免单点。审批记录平台会自动留存审计的时候直接导出即可。第五步配置通知。run 成功、失败、待审批都要有通知接到 IM 或者邮件里。我们用的是 IM 机器人失败和待审批会 相关人响应速度快很多。通知别配太多否则会变成噪音大家就都不看了。3.3 两种方案的迁移路径从原生迁到托管或者从托管迁回原生核心都是 state 的迁移。state 本身是标准的迁移的关键是让新环境能读到旧 state并且锁机制要切换干净。从原生迁托管一般步骤是先在托管平台创建工作空间配置好变量和权限然后把本地或者对象存储里的 state 导入到平台最后把 CI 里的执行命令从本地 terraform 改成调用平台 API。导入 state 的时候要注意平台可能会对 state 做一次校验如果 state 里有平台不认识的资源类型会报错得先处理掉。从托管迁原生反过来先把 state 从平台导出放到对象存储然后配置 backend 指向新的存储最后把 CI 改成本地执行。这里最容易出问题的是锁平台的锁和对象存储的锁是两套机制迁移期间要确保没有并发的 run否则可能写坏 state。我们的做法是迁移前先冻结所有变更迁移窗口选在业务低峰期迁移完做一次完整的 plan 验证确认没有意外 diff 才解冻。注意state 迁移是不可逆操作里风险较高的一种务必先备份原始 state并且在非生产环境完整演练一遍再动生产。4. 常见问题与排查技巧实录4.1 状态锁相关的高频故障状态锁问题是原生方案里出现频率最高的故障没有之一。典型症状是terraform plan卡住不动或者报Error acquiring the state lock。原因通常是上一次 run 异常退出锁没释放。排查思路很直接先看锁表里有没有残留记录有的话确认没有正在运行的 run然后手动删掉锁记录。命令是terraform force-unlock LOCK_IDLOCK_ID 在报错信息里会给。但要注意force-unlock 是危险操作如果确实有 run 在跑强行解锁会导致 state 损坏。我们的规矩是force-unlock 之前必须在团队频道里喊一声确认没人正在操作。托管服务基本不会遇到这个问题因为锁由平台管理run 结束自动释放。但托管服务也有类似的坑如果 run 卡在某个步骤超时了平台可能认为 run 还在进行新的 run 会排队。这时候需要在平台上手动取消卡住的 run。4.2 Provider 版本不一致导致的诡异 diff这个坑我们在原生方案里踩过好几次。症状是同样的代码不同人 plan 出来的结果不一样或者 CI 上 plan 通过但本地 plan 有 diff。根因是 Provider 版本不一致。解决办法有两个一是严格锁定版本用.terraform.lock.hcl文件把 Provider 的哈希固定下来这个文件要提交到仓库二是统一执行环境用容器或者托管平台跑保证所有人用的是同一套 Provider。我们两个都做了lock 文件进仓库CI 用固定版本的容器镜像。.terraform.lock.hcl的维护有个小技巧升级 Provider 版本时用terraform init -upgrade更新 lock 文件然后单独提一个 PR把版本变更和代码变更分开方便回滚和审查。4.3 敏感信息泄露的排查与预防Terraform 的 state 文件里会明文存储很多敏感信息比如数据库密码、密钥、证书。原生方案里 state 存在对象存储如果桶的权限没配好等于把家底暴露了。托管服务虽然加密存储但平台的管理员理论上还是能接触到。预防措施有几条一是 state 存储的访问权限最小化只给必要的角色二是敏感变量用专门的密钥管理服务存储Terraform 里只引用不落盘三是定期扫描 state 文件看有没有不该出现的敏感信息。我们写了个简单的脚本每次 apply 后扫一遍 state匹配常见的密钥模式发现可疑就告警。还有一个容易忽略的点是 plan 输出。plan 里也会包含敏感值如果 CI 把 plan 贴到 PR 评论里等于公开了。托管平台一般会对敏感值脱敏原生方案得自己处理比如用sensitive true标记变量或者在 CI 里过滤输出。4.4 常见问题速查表问题现象可能原因排查方向解决方式plan 卡住不动状态锁未释放检查锁表残留记录确认无运行中 run 后 force-unlock不同人 plan 结果不一致Provider 版本不一致对比 lock 文件哈希锁定版本统一执行环境apply 报资源已存在state 与实际不符检查 state 中是否缺失该资源import 资源或调整代码run 排队不执行平台并发限制或卡住的 run查看平台 run 队列取消卡住的 run 或提升并发配额敏感信息出现在日志变量未标记为敏感检查变量定义和输出标记 sensitive过滤 CI 输出迁移后 plan 有大量 diffstate 未正确导入对比迁移前后 state重新导入或手动修正 state4.5 几个只有踩过才知道的实操心得第一个心得plan 的频率要控制。CI 里每次 push 都触发 plan 看起来很美好但 run 次数会飙升托管服务的账单会教你做人。我们的做法是 PR 创建和更新时触发 plan后续的 push 如果只是改文档或者注释通过路径过滤跳过。第二个心得模块的版本管理要趁早。一开始大家图省事模块直接引用主分支结果有人改了模块所有引用它的环境全受影响。后来改成模块打 tag环境引用具体 tag升级模块走 PR 流程稳定性好了很多。第三个心得不要把所有东西都塞进 Terraform。有些一次性操作、紧急修复、平台特有的配置用 Terraform 管反而别扭。我们的原则是需要长期存在、需要版本控制、需要多人协作的资源才进 Terraform临时的、探索性的操作走控制台或者脚本事后再决定要不要纳管。第四个心得文档和代码要同步。Terraform 代码本身就是文档但有些决策背景、踩坑记录、参数选择的理由代码里写不下得单独记。我们用一个DECISIONS.md记录每个重要决策的背景和取舍新人接手时看这个文件能快速理解为什么这么设计。5. 不同场景下的选择建议5.1 小团队快速起步怎么选三五人的小团队基础设施规模不大预算有限我的建议是先用原生方案加对象存储后端。这个组合足够支撑日常开发成本几乎为零学习曲线也平缓。等团队扩张到十人以上或者资源数量超过两三百再考虑迁托管。小团队用原生方案时有几个地方可以偷懒但不会出事后端可以用云平台的对象存储不用自建 MinIOCI 可以用平台自带的流水线不用自己搭 Jenkins凭据可以用云平台的临时凭据服务不用自己搞密钥轮换。这些偷懒是合理的因为规模小风险可控。5.2 中大型团队的托管优先策略十人以上、多环境、有合规要求的团队托管服务的优势会非常明显。状态管理、权限控制、审批流、审计日志这些能力自建的话投入产出比很低。托管服务的席位费相比人力成本通常是可以接受的。中大型团队用托管服务时重点要放在工作空间的规划和权限模型的设计上。工作空间不要按人分要按业务域和环境分权限不要给个人要给团队和角色。这两条做好了后面的管理会顺很多。5.3 强合规场景的混合方案金融、医疗这类强合规场景往往要求数据不出境、操作可审计、权限可追溯。纯托管服务可能过不了合规审查纯原生方案又难以满足审计要求。这时候混合方案是折中的选择核心敏感资源用原生方案加自建后端跑在合规环境内非敏感资源用托管服务享受平台化的便利。混合方案的复杂度在于两套体系的协调。我们的做法是统一代码规范统一模块只在执行层做区分。这样代码本身是平台无关的切换执行方式只需要改配置不需要改代码。5.4 开源分支 OpenTofu 的适用考量OpenTofu 作为 Terraform 的开源分支最大的价值是给了原生方案一个不受单一厂商控制的退路。如果你的团队对开源有强偏好或者担心上游的许可证变更OpenTofu 是值得评估的选项。它的语法和 Terraform 基本兼容迁移成本不高Provider 生态也在逐步跟上。不过 OpenTofu 的生态成熟度相比 Terraform 还有差距某些新出的 Provider 或者平台特性可能支持滞后。选之前要确认你依赖的 Provider 在 OpenTofu 上能不能正常工作。我们做过一次评估常用的几个 Provider 都没问题但一个比较小众的监控 Provider 当时还不支持所以暂时没有全面切换。6. 我个人的选型体会折腾完这一轮我最大的感受是托管和原生不是非此即彼的对立而是不同阶段的工具。团队小的时候原生方案的灵活性和零成本是优势团队大了托管服务的工程化能力是刚需。硬要在小团队上托管或者在大团队上纯原生都是在给自己找麻烦。还有一个体会是无论选哪条路代码本身的质量才是根本。状态管理、执行环境、权限体系这些都是外围真正决定 IaC 好不好用的是你的模块设计得清不清晰、变量抽象得合不合理、命名规范不一致、文档跟不跟得上。这些做不好换什么平台都救不了。最后分享一个我们一直在用的小技巧每个季度做一次 IaC 健康检查看看有没有未纳管的资源、有没有过期的 Provider 版本、有没有该合并的模块、有没有该清理的工作空间。这个习惯坚持下来技术债不会积累到失控的程度。IaC 这件事工具选型只是起点持续维护才是长期功课。