HashiCorp 发布 Terraform 1.15，引入了动态模块源、针对变量和输出的正式弃用机制、一个新的内联类型转换函数、输出块类型约束，以及对 Windows ARM64 的原生支持。该版本于 2026 年 4 月 29 日发布，Apoorva Murthy 和 Jacob Plicque 在 HashiCorp 的博客上撰文进行了介绍。该版本回应了 Terraform 社区中多项长期存在的诉求，尽管其中部分核心功能在开源分支 OpenTofu 中已经存在近两年。
1.15 版本中最重大的语言变化在于，现在可以在模块源代码和版本属性中使用变量。此前，这些属性必须是字符串字面量，在需要将不同的环境指向不同的注册表或进行版本锁定时，团队将不得不重复编写模块代码块。变量代码块上新增的 const 属性说明该变量在 terraform init 过程中（即在评估完整配置之前）就会被解析。随后，模块源字符串就可以使用标准插值语法引用这些变量。只要其输入变量也声明为 const = true，该功能就同样适用于嵌套模块。
另一项主要的语言新特性是针对变量和输出块的 deprecated 属性。现在，模块创建者可以直接在配置中添加弃用提示，每当调用方将值传递给已弃用变量或引用已弃用输出时，Terraform 将在验证时发出警告诊断信息。HashiCorp 核心工程师 Daniel Schmidt 在一篇博文中详细解释了其工作原理：当弃用宽限期结束时，创建者可以发布一个不包含该已弃用变量的新版本，并替换所有旧变量的引用。该特性还会在资源属性及块中显示提供商定义的弃用提示，解决了之前弃用信息显示不一致的问题。
1.15 版本还引入了用于内联类型转换的 convert 函数，旨在解决 HCL 中 Terraform 类型推断产生意外结果的边界情况。常见的问题包括：在条件表达式中，两个分支推断出的类型不同；创建带类型的空容器：{} 会被视为空对象而非空映射，而 [] 会被视为元组而非列表。新函数允许开发者显式指定期望的类型。此外，输出块现在支持 type 属性，将输入变量很久以前就具备的验证和文档记录功能带到了输出。本次发布还新增了原生 Windows ARM64 二进制文件，而且 S3 后端现在已经支持通过 AWS CLI v2.32.0 的 aws login 命令生成的凭据，这样一来，就不需要在该场景下使用长期访问密钥了。
1.15 版本中的动态模块源文件功能让人不禁联想到 OpenTofu，这是由 Linux 基金会维护的 一个 Terraform 开源分支。OpenTofu 在 2024 年 8 月发布了 1.8.0 版本，其中就提供了同等的功能。在发布公告中，OpenTofu 团队详细阐述了这项被他们称为“早期变量与局部变量评估”的功能，它允许在模块源代码、后端配置以及状态加密设置中使用变量和局部变量。当时，该实现方案是 OpenTofu GitHub 上得票最高的 Issue，而且在此前几年间曾经被以各种形式提出过多次。后续发布的 OpenTofu 1.9 进一步完善了该功能，针对早期评估过程中的缺失变量增加了提示功能，并且能够阻止敏感值作为初始化的副作用出现在模块源路径中。
自 2023 年 8 月 HashiCorp 转向商业源码许可（Business Source Licence）后，OpenTofu 从 Terraform 1.5 分支出来，两个项目在其他方面也逐渐产生了分歧。InfoQ 在 2024 年 7 月曾经做过报道，OpenTofu 1.7 引入了原生的端到端状态加密功能，而这一功能在 Terraform 的开源 CLI 中至今仍未提供。OpenTofu 1.9 在提供程序块中添加了 for_each 功能，允许单个 provider 配置在多个区域或账户中实例化，而无需重复配置。2025 年 7 月发布的 OpenTofu 1.10 引入了 OCI 注册表支持（用于 provider 和模块分发）、无需 DynamoDB 表的原生 S3 状态锁定，以及实验性的 OpenTelemetry 追踪功能。同期， Terraform 的开发重点放在了临时值上，InfoQ 在 2024 年关于 Terraform 1.10 发布的报道中做过介绍；此外还有 Terraform 1.11 中的只写属性，以及与 HashiCorp 云平台的更深度集成，其中关于 MCP 服务器的支持，InfoQ 在 2025 年 8 月做过报道。
Terraform 1.15 中新增的变量弃用支持在 OpenTofu 中也有对应的功能，尽管具体实现细节有所不同。作为一系列工作流改进工作（包括增强型 moved 和 removed 代码块）的一部分，OpenTofu 1.10 引入了弃用能力。Terraform 1.15 的实现提供了更精细的控制，包括能够通过具有不同告警阈值的多层模块链式传递已弃用的输出。在 Alpha 版本发布以前，开发者 Mukhil Padmanabhan 曾经在 DEV Communit 上指出，该功能是负责管理公共及私有模块目录的团队长期以来一直要求的，此前接口变更只能通过发布说明来传达。
1.15 版本还改进了测试框架。现在，开发者可以在 mock_data 和 override_resource 块中使用函数，解决了测试数据依赖于 GUID 或资源 ID 等格式却无法动态生成的常见问题。此前，若尝试在模拟块内调用 uuid() 等函数，就会返回错误提示，指出该上下文不允许进行函数调用。HashiCorp 的多组件基础设施管理功能 Stacks 在该版本中新增了变量验证块，允许模块创建者在配置过程的早期阶段强制执行约束条件，而非等到应用时才进行验证。
Ashish Kasaudhan 在 LinkedIn 上撰文指出，Terraform 1.15 “不仅仅是一个普通的增量版本”，并列举了工程师们多年来一直希望解决的一系列问题。
这可能是近年来最重视工程师需求的 Terraform 更新之一。HashiCorp 没有推出任何花哨的功能，而是修复了平台团队多年来一直抱怨的那类问题。
—— Ashish Kasaudhan
在该版本发布后，Davlet Dzhakishev 在一篇分析文章中指出，terraform validate 命令现在已经支持对后端块进行验证，检查后端类型是否存在以及必填属性是否齐全。他认为，这个变更很小，但在实际的持续集成（CI）中却产生了出人意料的影响，因为在此之前，后端配置错误只会在 terraform init 阶段失败，而此时提供程序已经下载完毕，并且已经消耗了数分钟的管道运行时间。
不过在 Reddit 上，有评论者指出，这些验证规则的变更确实让部分用户措手不及。他们原本使用占位符和环境变量来处理数据，这会导致该功能失效；不过，其他评论者提出了合理的解决方法。
HashiCorp 在公告中表示，此次发布得益于社区通过 GitHub 问题和 HashiCorp Discuss 论坛所做的贡献。GitHub 的 Terraform 1.15 发布页面提供了完整的变更日志。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。