在 vRealize Automation 中将 Terraform 配置作为资源嵌入时，请注意某些限制和故障排除。

Terraform 配置限制

  • 验证包含 Terraform 配置的设计时，“测试”按钮会检查 Cloud Assembly 语法，但不会检查本机 Terraform 代码语法。

    此外，“测试”按钮不会验证与 Terraform 配置关联的提交 ID。

  • 对于包含 Terraform 配置的云模板，将模板克隆到其他项目需要应用以下解决办法。
    1. 在新项目中，在集成选项卡下，复制您的集成的 repositoryId。
    2. 打开克隆模板。在代码编辑器中，将 repositoryId 替换为所复制的值。
  • 在版本控制存储库中，不要在配置文件中包含 Terraform 状态文件。如果存在 terraform.tfstate，则部署时将出错。

对父 Terraform 资源支持的实施后操作

对于父 Terraform 资源，可以查看或刷新 Terraform 状态文件。有关状态文件操作的详细信息，请参见可以对 Cloud Assembly 部署运行哪些操作中的完整操作列表。

对子资源支持的实施后操作

部署 Terraform 配置后，可能需要长达 20 分钟才能对子资源执行实施后操作。

对于 Terraform 配置中的子资源，仅支持以下部分实施后操作。有关这些操作的详细信息，请在可以对 Cloud Assembly 部署运行哪些操作中的完整操作列表中查找这些操作。

提供商 Terraform 资源类型 支持的实施后操作
AWS aws_instance 打开电源
关闭电源
重新引导
重置
Azure azurerm_virtual_machine 打开电源
关闭电源
重新启动
挂起
vSphere vsphere_virtual_machine 打开电源
关闭电源
重新引导
重置
关机
挂起
创建快照
删除快照
恢复快照
GCP google_compute_instance 打开电源
关闭电源
创建快照
删除快照

对实施后操作可用性进行故障排除

如果即时可用 (OOTB) 实施后操作缺失或处于停用状态，可能需要进行故障排除。

问题 原因 解决方案
Terraform 资源在“操作”菜单上没有预期的 OOTB 实施后操作。

上述列表中提到的提供者和资源类型可能不支持该操作。

或者，根据资源发现和资源缓存计时，可能需要长达 20 分钟才能显示该操作。

检查设计中的提供商和资源类型。

等待 20 分钟，以完成数据收集。
即使在数据收集所用的 20 分钟后，Terraform 资源也没有预期的实施后操作。

资源发现问题导致该操作无法显示。

在项目外的云区域中意外创建资源时，会发生此问题。例如，您的项目仅包括云帐户和区域 us-east-1 云区域，但 Terraform 配置包括 us-west-1 提供商块，并且您在设计时未进行更改。

另一种可能的情况是数据收集不起作用。

根据设计中的云区域检查项目云区域。

转到基础架构 > 连接 > 云帐户，然后检查云帐户的数据收集状态和上次成功收集时间。
即使资源状态和数据收集没有明显的问题，实施后操作也会处于停用状态（灰显）。 偶尔会出现间歇性计时问题和数据收集失败，这些是已知问题。 该问题应会在 20 分钟内自行解决。
错误的实施后操作处于停用状态，该操作应基于资源状态处于活动状态。

例如，“关闭电源”处于启用状态，“打开电源”处于停用状态，即使使用提供商界面关闭了资源的电源也是如此。

 数据收集计时可能会导致暂时不匹配。如果从 vRealize Automation 外部更改电源状态，则需要一些时间才能正确反映所做的更改。 等待 20 分钟。

在 vRealize Automation 中使用自定义 Terraform 提供程序

如果您 要使用自定义 Terraform 提供程序，请执行以下步骤。

在 git 版本控制存储库中，在包含 main.tf 的 Terraform 目录下，添加以下子目录结构和自定义 Terraform 提供程序 ZIP 文件。

terraform.d/plugins/<HOSTNAME>/<NAMESPACE>/<TYPE>/terraform-provider-<TYPE_VERSION_TARGET>.zip

例如，如果下载了 azurerm 版本 3.12.0，则创建以下结构。

terraform.d/plugins/registry.terraform.io/hashicorp/azurerm/terraform-provider-azurerm_3.12.0_linux_amd64.zip