Terraform部署时配置项反复切换问题求助

核心原因 #

这种修改配置后部分嵌套块（比如site_config）先被移除、第二次执行terraform apply又恢复的问题，本质是Terraform Provider的状态同步bug：

• 第一次apply时，Provider与云服务商API交互后返回的资源状态，和本地配置存在差异，导致Terraform误判该嵌套块已不再需要，标记为移除
• 第二次apply时，Provider重新拉取资源状态，修正了之前的状态差异，又会把本地配置中的嵌套块重新添加回去

最优解决办法 #

1. 锁定Provider版本 #

不稳定的Provider版本是这类问题的高发诱因，指定固定版本避免自动更新带来的兼容性问题：

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "=3.74.0" # 替换为经过验证的稳定版本
    }
    aws = {
      source  = "hashicorp/aws"
      version = "=5.20.0"
    }
  }
}

2. 显式声明所有相关属性 #

部分Provider会因为可选属性未显式设置，在状态同步时出现误判。对于嵌套块，哪怕是默认值也显式写出来：

resource "azurerm_linux_function_app" "sample" {
  # 原有配置保持不变
  site_config {
    application_stack {
      python_version              = "3.8"
      use_dotnet_isolated_runtime = false # 显式声明默认值，避免状态误判
    }
    # 可根据需要补充site_config的其他属性，比如scm_type、always_on等
  }
}

3. 先刷新状态再执行apply #

修改配置后，先执行terraform refresh同步最新的云资源状态，再执行apply，避免第一次apply的状态误判：

terraform refresh
terraform apply

4. 排查Provider已知bug #

这类问题通常是Provider的已知bug，去对应Provider的GitHub仓库搜索相关关键词（比如azurerm linux_function_app site_config drift），如果是已上报的bug，等待官方修复版本即可。

5. 优化资源依赖方式 #

如果配置中有依赖其他资源动态生成的属性（比如storage_account_access_key），尝试用数据源替代直接引用资源属性，确保依赖关系更清晰：

data "azurerm_storage_account" "sample" {
  name                = azurerm_storage_account.sample.name
  resource_group_name = azurerm_storage_account.sample.resource_group_name
}

resource "azurerm_linux_function_app" "sample" {
  # 其他配置不变
  storage_account_access_key = data.azurerm_storage_account.sample.primary_access_key
}

总结 #

优先尝试锁定Provider版本和显式声明所有属性，这两个方法能解决绝大多数此类配置漂移问题；如果问题仍存在，再结合状态刷新和排查Provider issue来处理。

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