如何阻止Terraform销毁重建Azure VM扩展 lifecycle块无效

• lifecycle.prevent_destroy = true 仅能拦截主动执行的定向销毁/全量destroy操作，无法阻止因资源属性变更触发的「销毁旧资源+重建新资源」的ForceNew流程：当配置中存在触发强制重建的参数变更时，Terraform会正常生成重建计划，仅在apply阶段如果检测到销毁操作才会主动中断；如果配置未正确加载，就会直接发起Azure API删除请求，这时候就会被你配置的Azure资源锁拦截报错。
• 你当前配置存在多个容易触发非预期重建的隐患点：
  • 资源使用for_each循环创建，只要var.dsc_agent_name的键名、键值映射关系发生变更（比如修改key名、调整key对应的VM ID、删除旧key新增同名映射），Terraform会判定旧资源已被移除，直接触发销毁逻辑
  • auto_upgrade_minor_version 你传入的是字符串"true"，在3.x版本以上的azurerm provider中该参数要求为布尔类型，类型不匹配会导致状态漂移，触发资源重建判定
  • 针对azurerm_virtual_machine_extension资源，name/virtual_machine_id/publisher/type/type_handler_version这几个属性只要发生变更，都会被标记为强制重建属性
• 常见配置不生效的隐蔽原因：如果该资源是定义在子模块中，prevent_destroy必须写在资源声明所在的模块代码里，在根模块调用模块时配置lifecycle规则完全无效。

1. 定位触发重建的具体属性
   执行terraform plan，在输出中找到azurerm_virtual_machine_extension.dsc对应的计划条目，标记为# forces replacement的属性就是触发销毁重建的直接原因，不要盲目依赖资源锁或者lifecycle规则绕过。
2. 修复配置中的显性问题
   将auto_upgrade_minor_version的入参改为布尔类型，消除类型漂移问题：

   auto_upgrade_minor_version = true
   

3. 处理for_each映射变更导致的非预期销毁
   如果是调整了var.dsc_agent_name的键值映射、没有实际修改扩展本身的配置，不要直接执行apply，使用terraform state mv将状态中旧资源地址迁移到新地址，即可跳过销毁流程，示例命令：

   terraform state mv 'azurerm_virtual_machine_extension.dsc["old_key"]' 'azurerm_virtual_machine_extension.dsc["new_key"]'
   

4. 必须修改强制重建属性的场景处理
   如果你确实需要调整publisher/type这类会触发重建的属性，又要保留线上已存在的扩展不被删除，先将对应资源从Terraform状态中移除，再执行apply即可让Terraform直接关联现有资源，不会发起删除请求：

   terraform state rm 'azurerm_virtual_machine_extension.dsc["<your_extension_key>"]'
   terraform apply
   

5. 验证prevent_destroy是否正常生效
   配置正确的前提下，只要执行计划包含该资源的销毁操作，apply阶段Terraform会直接抛出Instance cannot be destroyed的本地错误，不会发起任何Azure API请求；如果出现Azure资源锁拦截的报错，说明你的lifecycle规则没有被正确加载，优先排查资源所属模块位置、配置是否保存后重新执行plan校验。

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