Azure上Terraform执行apply失败后的回滚/状态更新问题

核心疑问解答 #

为什么Terraform不自动回滚已创建资源？ #

Terraform的设计原则是最小化破坏性变更，自动回滚存在不可忽视的风险：

• 云资源的创建/删除多为异步操作，Terraform无法100%确认资源的最终状态，盲目回滚可能导致不可逆的资源丢失。
• 即便首次部署，已创建的资源也可能存在隐式依赖关系，回滚会直接破坏这些依赖。
• 回滚本身需要额外的API调用，反而可能引入新的失败点，增加问题复杂度。

为什么失败后已创建资源没更新到状态文件？ #

主要有两类原因：

1. 状态更新机制限制：Terraform会在单个资源操作成功后更新本地状态，但如果使用远程状态（如Azure Blob存储的tfstate），部分配置下会批量提交状态变更，中途失败会导致最后一次变更未同步到远程。
2. 不确定性保护：如果遇到网络超时、Azure API返回模糊错误，Terraform无法确定资源是否真的创建成功，不会贸然更新状态，避免状态与实际资源出现不一致。

更优解决方法 #

1. 同步状态后重新部署 #

当apply失败后，先执行状态刷新，让Terraform同步已创建的资源到状态文件：

terraform refresh

之后再执行terraform apply，Terraform会识别已存在的资源，跳过创建步骤，继续完成剩余资源的部署。

2. 配置AzureRM Provider自动重试 #

针对Azure区域资源临时不可用的问题，在Provider配置中添加重试参数，让Terraform自动重试临时错误：

provider "azurerm" {
  features {}

  # 最多重试5次，每次间隔至少10秒
  retry_max_attempts = 5
  retry_min_delay_in_seconds = 10
}

这能大幅降低因临时资源不可用导致的部署失败概率。

3. 拆分复杂部署 #

把大型基础设施拆分成多个独立的Terraform模块或配置文件（比如按资源组、业务模块拆分），每个部分使用单独的状态文件。这样单个模块失败不会影响其他已成功部署的模块，恢复起来更简单。

4. 启用状态锁定 #

如果使用远程状态存储（如Azure Blob），必须启用状态锁定，防止多个apply操作同时修改状态文件，避免状态不一致：

terraform {
  backend "azurerm" {
    resource_group_name  = "tf-state-rg"
    storage_account_name = "tfstateaccount"
    container_name       = "tfstate"
    key                  = "prod.tfstate"
    enable_lock          = true
  }
}

5. 批量导入已创建资源（当refresh无效时） #

如果refresh没能同步资源，可以用脚本批量生成导入命令。先通过Azure CLI列出已创建的资源组：

az group list --query "[].{id:id, name:name}" -o tsv

再根据输出生成terraform import命令，例如：

terraform import azurerm_resource_group.my_rg /subscriptions/xxxx/resourceGroups/my-rg

资源数量多时，可编写简单的shell/Python脚本自动生成并执行导入命令，比手动操作高效很多。

内容的提问来源于stack exchange，提问作者StanTastic