Terraform谷歌云8.0发布：消除永久Diff却含破坏性变更
HashiCorp 宣布，Terraform Google Cloud Provider 8.0 现已正式可用。这个大版本更新了两种 Compute Engine 资源的默认负载均衡行为，移除了与已退役 Google Cloud 服务相关的资源，并将若干不考虑顺序的属性由列表改为集合，以避免持续出现计划差异。由于这是一
HashiCorp 称，Terraform Google Cloud Provider 8.0 已经正式开放使用。这一大版本改动集中在三处：两类 Compute Engine 资源的负载均衡默认行为变了，跟已停运 Google Cloud 服务挂钩的资源被拿掉，另有一批本来不讲究顺序的属性从列表改成集合，目的是让计划差异不再反复冒出来。因为带着破坏性变更，HashiCorp 给用户的建议是：先升到最新的 7.x，把弃用警告清干净，再往 8.0 走。
最显眼的行为变动落在google_compute_backend_service 和 google_compute_global_forwarding_rule上，它们的默认load-balancing_scheme 已由 EXTERNAL 改为 EXTERNAL_MANAGED换了。也就是说，配置里没写这个字段的，会自动套用新的外部应用负载均衡器，经典负载均衡器不再是默认。还指着经典行为干活的团队，得自己把load_balancing_scheme = "EXTERNAL"显式写上，不然 Terraform 的计划阶段就可能提出要改动现有的负载均衡器。
同时被删掉的还有一批资源和数据源，原因是它们背后的服务已经关停或者被别的服务顶替。移除名单里有google_iap_brand 和 google_iap_client（IAP OAuth Admin API 关闭之后），还有三个google_notebooks_*资源，用户需要迁到google_workbench_instance）、google_ml_engine_model；BeyondCorp 的应用连接、连接器、网关这几类资源同样没了，接替它们的是 Security Gateway 资源。google_vertex_ai_schedule 则由 google_colab_schedule老资源被替换之后，升级前还得把所有引用它们的配置一并改好。
列表与集合的调整同样出现在 Schema 行为上：Compute Service Attachments、GKE 日志和监控配置，以及 Cloud Security Compliance Frameworks 中的字段，凡是不带顺序语义的属性都从列表改成了集合。HashiCorp 的说法是，这样能防止 API 返回值的顺序和配置不一致时冒出永久性差异。同时，一些 Google Cloud API 的校验规则收得更紧了。比如，google_workflows_workflow现在必须提供source_contents；创建 Workforce Identity Pool Provider SCIM 租户时，同样必须提供claim_mapping。有些状态变化能自动迁移，像部分整数转字符串的情况；另一些就得动手改配置了。
公告里还盘点了 8.0 所依托的若干 7.x 时期功能。Terraform 列表资源已经得到该 Provider 的支持，可以配合terraform query的工作流来用。用户能搜索状态之外的现有基础设施，再决定生成资源配置还是导入配置，眼下覆盖 Compute Engine、IAM、BigQuery、Pub/Sub、Secret Manager、Migration Center 和 Network Services。Resource Identity 的支持范围也扩大了，它为 Provider 提供了一种清晰表达远程对象的方式，导入时可以像传统 ID 那样使用。只写属性则让敏感值能发给 API 却不必存下来，目前涉及证书私钥、AlloyDB 密码和 IAP 凭证。
这个 Provider 由 Google Cloud 工程团队、HashiCorp 和 Terraform 社区一起开发，8.0 版本已经上架 Terraform Registry。官方文章既没给基准测试，也没给采用数据，被移除的资源同样没有列全。说到底，升级指南和 GitHub 变更日志才是权威依据。
升级可以按下面这套方案走：
-
先把 Provider 版本固定住，升级到最新的 7.x。弃用警告全部处理完，再到非生产环境里升 8.0。
-
在代码里搜前面提到的已移除资源，还有没设置
load_balancing_scheme的负载均衡器资源。这个字段要显式写上，免得不知不觉迁到EXTERNAL_MANAGED。 -
仔细检查
terraform plan。重点盯被标记为销毁或替换的资源，列表转集合的地方尤其要看，类型变了或改成必填的只写版本属性也别放过。
用 OpenTofu 的团队能拿到该版本的大部分功能，但不是全部。这个 Provider 的破坏性变更包括默认值改为EXTERNAL_MANAGED、资源移除，以及列表到集合的转换。这些改动都落在 Provider 里，换哪种 CLI 都躲不开。只写属性要求 OpenTofu 1.11 或更高版本，这项功能是那个版本才加进来的。
用 Terraform 查询和列出资源的发现工作流，在 OpenTofu 里还没有对应实现。关于tofu query的功能请求（issue #3787）还挂着没处理。所以这些团队还是得靠 import 块和生成的配置来管现有基础设施。
到本文撰写时为止，OpenTofu 支不支持 Resource Identity 还没有确认，打算用基于身份导入的团队最好先翻翻 OpenTofu 变更日志。固定版本之前，也该确认 OpenTofu Registry 里有没有现成的 8.0 Provider 构建版本。
