Terraform中azurerm_storage_account持续触发in-place更新问题求助

核心问题原因 #

1. bypass属性的条件判断逻辑：使用var.network_rules_bypass != [] ? var.network_rules_bypass : ["AzureServices"]的条件判断，虽逻辑正确，但Terraform在状态对比时，空列表的处理方式可能导致持续检测到差异。
2. 布尔类型变量类型不匹配：large_file_share_enabled、is_hns_enabled等变量被定义为string类型，但AzureRM Provider对应资源参数要求bool类型，类型转换可能引发状态对比异常。
3. default_action状态不一致：执行计划显示default_action从Allow变为Deny，说明当前状态值与配置值不匹配，大概率是未启用network_rules时的默认值残留。

解决方案 #

1. 优化bypass属性赋值逻辑 #

用Terraform内置的coalescelist函数替代条件判断，该函数专门处理空列表的默认值场景，避免空列表对比的潜在问题：

bypass = coalescelist(var.network_rules_bypass, ["AzureServices"])

函数会优先使用var.network_rules_bypass的非空值，若变量为空列表，则返回["AzureServices"]。

2. 修正布尔类型变量定义 #

将所有布尔类型变量从string改为bool，确保与Provider参数类型一致，消除类型转换导致的状态差异：
在var.tf中修改以下变量：

variable "large_file_share_enabled" {
  type    = bool
  default = false
}

variable "is_hns_enabled" {
  type    = bool
  default = false
}

variable "is_sftp_enabled" {
  type    = bool
  default = false
}

variable "public_network_access_enabled" {
  type    = bool
  default = true
}

3. 同步default_action配置与状态 #

执行terraform state show azurerm_storage_account.storageaccount查看当前状态中network_rules.default_action的值，若确实为Allow，执行一次terraform apply将其更新为配置中的Deny，后续配置不变则不会再触发该属性更新。

4. 验证测试 #

修改完成后依次执行：

terraform plan

确认无不必要的更新提示后，执行terraform apply应用变更，再次执行terraform plan验证无更新操作。

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