Terraform 的 Google 供应商 v8.5.0 于 2026 年 9 月 29 日发布：Cloud SQL 缩容不再重建实例。 这条版本发布落在「前置部署」Forward Deployed Engineer（FDE）的客户环境基础设施生命周期管理段：供应商版本决定了交付时能不能在不动客户生产数据的前提下把资源改对。对在客户现场维护 Terraform 栈的「前置部署」Forward Deployed Engineer（FDE）来说，一个字段的强制重建语义就是一次不可逆的停机风险，把风险项从「强制重建」改成「原地缩容」，是可以直接写进「交付清单」的改动。这条改动对做「隔离环境」交付的「前置部署」Forward Deployed Engineer（FDE）同样重要：离线镜像里多带一份供应商版本，现场就少一次排障。 terraform-provider-google v8.5.0 由 HashiCorp 于 2026 年 9 月 29 日 18:16 UTC 发布，同一天 18:28 UTC 发布配套的 terraform-provider-google-beta v8.5.0。发布说明共 29 条，分成 4 段：1 条 NOTES、2 条 DEPRECATIONS、5 条 FEATURES、21 条 IMPROVEMENTS，引用 25 个不重复的 pull request 编号，编号从 #29438 到 #29658。这个供应商按每周一次的节奏发版，前三个版本分别在 2026 年 9 月 8 日、9 月 15 日、9 月 22 日发布，所以从 8.4.0 升到 8.5.0 的间隔是 7 天。这些改动由 modular-magician 机器人从上游 magic-modules 仓库同步过来，每条变更都能追到一个上游 pull request 编号。「前置部署」Forward Deployed Engineer（FDE）看版本号之外，应该先读 NOTES 与 DEPRECATIONS 两段，这两段最容易在客户环境里造成意外变更。 v8.5.0 最值得读的一条是 google_sql_database_instance 的存储缩容。改动前的实现是：负责差异判断的函数 diskSizeCutomizeDiff 在检测到 disk_size 变小时返回 ForceNew，Terraform 因此在计划里把这次改动标成 forces replacement，apply 时会销毁整台 Cloud SQL 实例再按新规格重建一台，对一块装着客户数据的「数据盘」来说这是破坏性操作。改动后的实现是：diskSizeCutomizeDiff 不再对缩容返回 ForceNew，缩容被保留为原地更新；apply 时通过 Cloud SQL 的 Instances.PerformDiskShrink 操作执行缩容，而 settings 更新保留当前磁盘大小，对磁盘本身是一次空操作。「前置部署」Forward Deployed Engineer（FDE）判断这条改动能不能用，关键就在「计划里出现 forces replacement 还是原地更新」这一个信号上。 根因是服务端能力变了，不是供应商的取舍。Cloud SQL 在服务端提供 PerformDiskShrink 之前没有缩容接口，供应商只能用重建来表达缩小这个意图，于是把缩容建模成 ForceNew；服务端接口上线后才可能改成原地。该接口对 MySQL 与 PostgreSQL 已经正式可用，对 SQL Server 是可用状态但没有标为正式可用。此外还加了一道前置校验：apply 之前先调 GetDiskShrinkConfig，当请求的尺寸低于该实例当前允许缩容到的最小尺寸时直接报错，而不是让缩容操作先启动再失败。扩容路径没有改动，仍然走 settings 更新；开启 disk_autoresize 时缩容依旧被忽略，与旧版本一致。「前置部署」Forward Deployed Engineer（FDE）在客户现场遇到的是同一类问题：服务端能力升级之后，供应商版本才是真正的开关。 这项改动带了一条真实的「验收测试」：TestAccSqlDatabaseInstance_storageShrink 会在真实 GCP 上创建一台 100 GB 的实例，再就地缩容到 90 GB，断言磁盘大小变成 90 GB 且实例 ID 不变、也就是没有发生重建，结果通过。原来那条 TestAccSqlDatabaseInstance_DiskSizeAutoResizeWithDiskSize 里断言必然重建的步骤，也被改成断言原地更新且计划非空。测试里有一个细节值得注意：共享核心机型不支持存储缩容，所以新测试用的是 db-custom-* 规格。「前置部署」Forward Deployed Engineer（FDE）可以把这条测试名当成升级后自查的锚点。这条数字对比是本文判断改动真实生效的唯一硬证据，因为发布说明本身只写了行为变化，没有给任何实测耗时。 第二个可用点是写-only 字段 write-only field 继续铺开。Secret Manager 的区域级密钥版本资源 google_secret_manager_regional_secret_version 新增 secret_data_wo 与 secret_data_wo_version，补齐了它与区域无关版本之间的能力差距，上游修复的是 issue #27405。根因在 Terraform 的 state 语义：普通字段的取值会被写进 state 文件，而密钥值进 state 就等于把密钥复制一份到对象存储或版本库里。把字段标记为 write_only: true 之后，生成器会派生出 secret_data_wo、字符串触发器 secret_data_wo_version、二选一约束 ExactlyOneOf{secret_data, secret_data_wo}，以及 secret_data_wo 与 secret_data_wo_version 之间的 RequiredWith 配对；该字段只在 apply 时读一次配置，不落 state。 这次改动还顺手修了一个会让计划抖动的问题：当 secret_data_wo_version 被设置时，读取逻辑提前返回，跳过访问接口的取值调用，避免把密钥读回 state，也避免出现假的差异。同一版本里另有两处同型改动：google_bigquery_connection 新增 password_wo 与 password_wo_version，google_compute_disk 与 google_compute_region_disk 新增 rsa_encryption_wo 与 raw_key_wo，后两者用于磁盘的客户自管加密密钥。「前置部署」Forward Deployed Engineer（FDE）在客户环境里应优先把新建的密钥资源改成写-only 形态。 用写-only 字段有一条必须记住的规则：只改 secret_data_wo 的值不会触发更新，因为这个值不在 state 里、供应商无法比对；要「密钥轮换」必须同时递增 secret_data_wo_version。这条规则是「前置部署」Forward Deployed Engineer（FDE）在客户环境交付密钥管理时最容易踩的一处。 第三个可用点是新增的 List Resource。v8.5.0 新增两个：google_project_iam_binding 与 google_secret_manager_secret_version；List Resource 的用途是列出现有对象并支持导入，对「前置部署」Forward Deployed Engineer（FDE）接管客户既有环境特别有价值，不必先手工把资源写进 state，可以先把客户已经存在的 IAM 绑定与密钥版本列出来，再决定纳管范围。同版本还新增 1 个数据源 google_network_services_gateway，新增 2 个资源 google_resource_manager_capability_config 与 google_vertex_ai_semantic_governance_policy，后者把 Vertex AI 的「语义治理」策略写成「基础设施即代码」infrastructure as code。 谷歌托管侧的几条改动值得单独记一笔。google_cloud_run_v2_service 新增 ssh_enabled，可以在托管的容器服务里开启 SSH 会话用于现场排障；同一资源的 template.scaling.cpu_utilization 与 template.scaling.concurrency_utilization 从预览转为正式可用。google_ces_agent 新增 remote_a2a_agent，对应服务端的 remoteA2aAgent.a2aConfig 配置，把远端 A2A 智能体接进托管的客户互动套件 Customer Engagement Suite 并纳入 IaC 管理。对在做「多智能体编排」multi-agent orchestration 交付的「前置部署」Forward Deployed Engineer（FDE）来说，这条意味着智能体之间的连接关系终于可以进版本控制、而不是停留在控制台里。 两条弃用要提前处理。google_firebase_ai_logic_config 的 generative_language_config 与 generative_language_config.api_key 被标记弃用，其中把 api_key 直接写进配置的字段被弃用，方向与前面写-only 字段一致。google_network_services_agent_connectivity_template 里 egress_network_config.dns_peering_config.domain 被弃用，改用同级的 domains 列表字段，从单值改成多值是一次会改变行为的迁移。「前置部署」Forward Deployed Engineer（FDE）应在下一次发版前把这两处弃用字段统一改完。NOTES 段只有一条：google_compute_router_interface 的 VPN 隧道查询从旧的 Apiary 计算客户端迁移到直连 HTTP，URL 由 transport_tpg.BaseUrl(Product, config) 拼出，这个调用只在创建资源时执行一次，属于清理「技术债」而不是功能变化。 这篇要说明局限，逐条说清。第一，「原地缩容」对「共享核心机型」不适用，变更说明明确写了存储缩容不支持这类机型，交付前必须先确认实例的规格族，这也是为什么官方验收测试要换成 db-custom-* 规格。第二，缩容只在关闭 disk_autoresize 时才被处理，开着自动扩容时缩小 disk_size 仍然被忽略，这一点新旧版本一致。第三，SQL Server 只是可用而非正式可用，把 MySQL 与 PostgreSQL 的行为直接外推到 SQL Server 不成立。第四，字段文档与发布说明不一致：在 v8.5.0 标签以及主干分支的 google_sql_database_instance 文档页里，disk_size 仍然写着运行中的实例存储不能缩小、只能增大，整篇文档没有出现缩容相关表述，也就是发布说明更新了但文档页没有同步，落地时以变更记录为准、不要以文档页为准。第五，变更本身没有给出缩容耗时、缩容期间对在线读写的影响、以及大实例的缩容时长，验收测试只报告通过、没有报告时长，所以本文无法给出缩容窗口的估算。第六，服务端对缩容频率与最小尺寸的完整约束在这次发布范围之外，disk_size 的 10 GB 与 20 GB 下限是字段级下限，不等于实例当时可缩到的最小值。第七，本文不涉及跨区域高可用、也不涉及物理隔离环境下该供应商能否使用。这些局限对「前置部署」Forward Deployed Engineer（FDE）的意义是：把这条改动当作可以做「原地缩容」的能力，而不是任何实例都能随时缩到任意尺寸的保证。 实用结论很直接：只要 state 里有 google_sql_database_instance，这次升级就值得做，因为旧版本一旦遇到缩容就会把生产库重建掉。适用条件是：用 Terraform 管理 Cloud SQL、目标实例不是共享核心机型、并且能接受一次 apply 级别的变更；不满足前两条就不要靠这次升级去缩容。具体动作按顺序执行。第一步，把「版本约束」改成 version = "~> 8.5" 或 "= 8.5.0"，然后跑 terraform init -upgrade；隔离环境不要走公网，先用 terraform providers mirror 把 terraform-provider-google 8.5.0 预取到本地目录，再让离线环境通过 filesystem_mirror 分发。第二步，先跑 terraform plan：如果配置里确实存在 disk_size 缩小，计划里原本的 forces replacement 应该变成原地更新；看到原地更新再 apply，看到重建就停下来核对机型。第三步，确认目标实例的 disk_autoresize 为 false，否则缩容请求会被静默忽略。第四步，缩容目标不要低于服务端允许的最小尺寸，低于时 apply 会被 GetDiskShrinkConfig 前置校验直接拦下，报错信息里会给出可缩容的最小值；这一步更适合先用小实例在测试环境验证一次。第五步，把新写的 google_secret_manager_regional_secret_version 改用 secret_data_wo 加 secret_data_wo_version，轮换时递增版本触发器。 回滚或退出方式：把「版本约束」固定回 8.4.0 并重新 init。已经缩容过的实例，只要配置里的 disk_size 与实机一致就不会触发重建；但如果之后再试图把 disk_size 调小，ForceNew 行为会恢复、计划里会重新出现 forces replacement。所以回滚的决定必须在缩容之前做，缩容之后再回滚只是回滚工具版本，不是回滚数据盘尺寸。要彻底退出这次能力，可以在 resource 上给 disk_size 加 lifecycle.ignore_changes，让 Terraform 不再管理该字段，代价是磁盘尺寸从此不受代码约束。最后提醒一句：「前置部署」Forward Deployed Engineer（FDE）应在改动落地前确认客户环境用的是公有云版供应商，而非只能在控制台改尺寸的场景。 交付前的自检清单，逐条勾选，每一条都对应上面某一段的结论。 - 「前置部署」Forward Deployed Engineer（FDE）：升级前先确认目标 Cloud SQL 实例不是共享核心机型，该机型不支持存储缩容。 - 「前置部署」Forward Deployed Engineer（FDE）：确认 disk_autoresize 已关闭，开着自动扩容时缩小 disk_size 会被忽略。 - 「前置部署」Forward Deployed Engineer（FDE）：先看 terraform plan 里的 forces replacement 是否消失，再决定是否 apply。 - 「前置部署」Forward Deployed Engineer（FDE）：缩容前先调 GetDiskShrinkConfig 或先用测试实例验证，确认目标值不低于服务端最小可缩容尺寸。 - 「前置部署」Forward Deployed Engineer（FDE）：把供应商版本约束改到 8.5.0 之后再跑 terraform init -upgrade，不要只改 lock 文件。 - 「前置部署」Forward Deployed Engineer（FDE）：隔离环境用 terraform providers mirror 预取 8.5.0，再用 filesystem_mirror 离线分发。 - 「前置部署」Forward Deployed Engineer（FDE）：密钥改用 secret_data_wo 与 secret_data_wo_version 组合，轮换时递增版本触发器而不只改值。 - 「前置部署」Forward Deployed Engineer（FDE）：核对 google_firebase_ai_logic_config 与 agent_connectivity_template 两处弃用字段，避免下次发版报错。 - 「前置部署」Forward Deployed Engineer（FDE）：接管客户既有环境时先用两个新 List Resource 列出 IAM 绑定与密钥版本，再决定纳管范围。 - 「前置部署」Forward Deployed Engineer（FDE）：把 remote_a2a_agent 这类智能体连接关系写进 IaC，别只留在控制台。 - 「前置部署」Forward Deployed Engineer（FDE）：Cloud Run 现场排障可以用新的 ssh_enabled 字段开启 SSH，替代临时跳板机。 - 「前置部署」Forward Deployed Engineer（FDE）：如需回滚，把版本固定回 8.4.0 并重新 init，且回滚决定必须在缩容之前做。 原始来源： - https://github.com/hashicorp/terraform-provider-google/releases/tag/v8.5.0 - https://github.com/hashicorp/terraform-provider-google/blob/v8.5.0/CHANGELOG.md - https://github.com/hashicorp/terraform-provider-google/pull/29635 - https://github.com/hashicorp/terraform-provider-google/pull/29653 - https://github.com/hashicorp/terraform-provider-google/pull/29440 - https://github.com/hashicorp/terraform-provider-google/pull/29442 - https://github.com/hashicorp/terraform-provider-google/blob/v8.5.0/website/docs/r/sql_database_instance.html.markdown