检查

check 块可以在通常的资源生命周期之外验证您的基础设施。检查块弥合了基础设施应用后和功能验证之间的差距。

检查块允许您定义 自定义条件，这些条件在每次 OpenTofu 计划或应用操作时执行，而不会影响操作的整体状态。检查块在 OpenTofu 计划或供应基础设施之后作为计划或应用的最后一步执行。

语法​

您可以使用本地名称、零到一个作用域的 数据源 和一个到多个 断言 来声明 check 块。

以下示例加载网站并验证它是否返回预期的状态代码 200。

check "health_check" {
  data "http" "opentofu_org" {
    url = "https://www.opentofu.org"
  }

  assert {
    condition = data.http.opentofu_org.status_code == 200
    error_message = "${data.http.opentofu_org.url} returned an unhealthy status code"
  }
}

作用域数据源​

您可以将来自任何提供程序的任何数据源用作用于 check 块中的作用域数据源。

check 块可以选择包含嵌套（也称为作用域）数据源。此 data 块的行为类似于外部 数据源，但您不能在其封闭的 check 块之外引用它。此外，如果作用域数据源的提供程序引发任何错误，则将其屏蔽为警告，并且不会阻止 OpenTofu 继续执行操作。

您可以使用作用域数据源来验证基础设施的一部分的状态，而无需使用通常的 OpenTofu 资源生命周期。 在上面的示例中，如果 opentofu_org 数据源无法加载，您会收到警告而不是阻止错误，如果您在 check 块之外声明此数据源，则会出现此错误。

元参数​

作用域数据源支持 depends_on 和 provider 元参数。作用域数据源不支持 count 或 for_each 元参数。

depends_on​

depends_on 元参数在作用域数据源中使用时特别强大。

OpenTofu 第一次为我们的 上一个示例 创建初始计划时，计划会失败，因为 OpenTofu 尚未应用其配置。这意味着此测试失败，因为 OpenTofu 必须创建使此网站存在的资源。因此，OpenTofu 第一次运行此检查时，始终会抛出一个可能分散注意力的错误消息。

您可以通过向作用域数据源添加 depends_on 来解决此问题，确保它依赖于网站基础设施的重要部分，例如负载均衡器。检查返回 已知应用后，直到网站的关键部分准备就绪。此策略避免在设置过程中产生不必要的警告，并且检查在后续计划和应用期间执行。

此策略的一个问题是，如果作用域数据源 depends_on 的资源发生更改，则检查块会返回 已知应用后，直到 OpenTofu 更新该资源。根据您的用例，此行为可能是可以接受的或存在问题的。

如果您的作用域数据源依赖于另一个资源的存在而没有直接引用它，我们建议实现 depends_on 元参数。

断言​

检查块使用 assert 块验证您的自定义断言。每个 check 块必须至少有一个，但可能有多个 assert 块。每个 assert 块都有一个 condition 属性 和一个 error_message 属性。

与其他 自定义条件 不同，断言不会影响 OpenTofu 执行操作。失败的断言会报告警告，而不会停止正在进行的操作。这与其他自定义条件（例如后置条件）形成对比，在后置条件中，OpenTofu 会立即产生错误，停止操作并阻止未来资源的应用或计划。

assert 块中的条件参数可以引用封闭 check 块中的作用域数据源，以及当前模块中的任何变量、资源、数据源或模块输出。

了解更多关于断言的信息.

元参数​

Check 块目前不支持元参数。我们仍在收集对此功能的反馈，因此，如果您的用例能够从 check 块支持元参数中受益，请告知我们。

TACOS（TF 自动化与协作软件）中的持续验证​

TACOS（TF 自动化与协作软件）可以自动验证工作区配置中的检查在 OpenTofu 配置新基础设施后是否继续通过。

选择检查或其他自定义条件​

Check 块在 OpenTofu 中提供了最灵活的验证解决方案。您可以在检查断言中引用输出、变量、资源和数据源。您还可以使用检查来模拟每个备选的自定义条件。但是，这并不意味着您应该用 check 块替换所有自定义条件。

check 块断言和其他自定义条件之间存在主要的行为差异，主要区别在于 check 块不会影响 OpenTofu 对操作的执行。您可以使用这种非阻塞行为来决定最适合您用例的验证类型。

输出和变量​

输出后置条件和变量验证都对输入和输出进行断言。

这是您可能希望 OpenTofu 阻止进一步执行的情况之一。

例如，在使用该输入变量应用整个配置后，OpenTofu 警告输入变量无效并没有帮助。在这种情况下，check 块会警告无效的输入变量，而不会中断操作。同一输入变量的验证块会提醒您无效的变量并停止计划或应用操作。

资源前提条件和后置条件​

前提条件和后置条件与 check 块之间的区别更加细微。

前提条件在自定义条件中是独一无二的，因为它在应用或计划资源更改之前执行。选择前提条件和后置条件提供了关于在前提条件和后置条件之间进行选择方面的指导，相同主题也适用于在前提条件和 check 块之间进行选择。

您通常可以互换使用后置条件和 check 块来验证资源和数据源。

例如，您可以重写上面的 check 块示例以使用后置条件。以下代码使用 postcondition 块来验证网站是否返回预期的状态代码 200。

data "http" "opentofu_org" {
  url = "https://www.opentofu.org"

  lifecycle {
    postcondition {
        condition = self.status_code == 200
        error_message = "${self.url} returned an unhealthy status code"
    }
  }
}

check 和 postcondition 块示例都验证了网站在计划或应用操作期间是否返回 200 状态代码。这两个块之间的区别在于每个块如何处理失败。

如果 postcondition 块失败，它会阻止 OpenTofu 执行当前操作。如果 check 块失败，它不会阻止 OpenTofu 执行操作。

如果上述示例的后置条件失败，则无法从中恢复。如果您的后置条件在计划阶段不满足，OpenTofu 会阻止任何未来的计划或应用操作。出现此问题是因为后置条件不直接依赖于 OpenTofu 配置，而是依赖于多个资源之间的复杂交互。

我们建议使用 check 块来验证基础设施的整体状态。我们仅建议在您需要根据资源配置保证单个资源时使用后置条件。