1.2.4.1. terraform.tf

每一个 Terraform 模块（包括根模块）都应该包含一个 terraform 块，我们将这个块声明在 terraform.tf 文件里。

一个典型的 terraform 块如下所示：

terraform {
  required_version = ">= 1.0.0"

  required_providers {
    azapi = {
      source  = "Azure/azapi"
      version = "~>2.0"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~>4.0"
    }
  }
}

required_version 规定了运行该模块所需要的 Terraform 程序的版本范围，required_providers 里面列出了该模块所需要的 Provider 及其版本范围。required_providers 中的 source 字段是一个字符串，表示该 Provider 的源地址，格式为 <namespace>/<name>，例如 hashicorp/azurerm。version 字段是一个字符串，表示该 Provider 的版本范围，例如 ~>4.0 表示大于等于 4.0 小于 5.0 的版本。

当然，terraform 块也遵循相同的规范：required_version 作为 Argument 在上方，required_providers 作为 Nested Block 在下方。

1.2.4.1.1. 限定 Provider 的 Major Version

Terraform 及其所有的 Provider 都要求使用语义化版本标准进行版本化管理，简单来说：

版本格式：MAJOR.MINOR.PATCH，版本号递增规则如下：

MAJOR：当你做了不兼容的 API 修改， MINOR：当你做了向下兼容的功能性新增， PATCH：当你做了向下兼容的问题修正。

Major 版本的更新往往都伴随着破坏性变更，所有未经测试确认的破坏性变更都是极其危险的，所以我们在声明 Provider 版本号约束时，必须限制 Major Version，例如：

• ~> 2.0
• >= 2.17, < 3.0

以下的版本号约束是不合适的：

• >= 2.0 # 可能会在未经测试的情况下使用 v3.0
• =2.17、2.17 # 过于严格的约束，这使得该模块几乎很难与其他模块一起使用
• ~> 2.17 # 一种常见且隐晦的错误，该约束锁定了 Minor Version 在 17，也就是说，2.17.0、2.17.1 这些都可以，但 2.18.0 不行，这实际上与上一条的问题是一样的

我们建议以 ~> 2.0 这样的约束开始，但是一旦引入某个特定版本 Provider 才添加的新功能后，要改为类似 >= 2.17, < 3.0 这样的形式，版本约束的下界是新功能被添加的版本。

1.2.4.1.2. 请密切注意更新 terraform 块

请注意，作为模块的维护者，我们时常会收到来自社区和客户的请求，要求我们添加各种新功能、新字段，或是修复某些错误，我们对代码的变更有时需要引入一些原来没有的功能，这时我们必须检查这些功能是从 Provider 的哪个版本添加的，或是我们是否使用了 Terraform 本身比较新的一些功能，如果是，我们要重新审查我们在 terraform 块中定义的版本信息，确保他们是准确的，否则可能会引发一些非常令人困惑的错误，用户可能会被错误信息中各种提示不存在的字段吓到。