Terraform从0.11.13跨版本升级至1.3.6的方案咨询

1. 不依赖官方升级工具的跨版本升级路径 #

官方要求的分步升级确实繁琐，但可以通过重新构建状态与配置链路的方式跳过中间版本，核心逻辑是弃用旧状态，基于需保留的资源重新建立1.3.6版本的管理体系：

• 优先备份当前0.11.13的所有配置文件和terraform.tfstate，这是所有操作的前提，防止失误导致资源失控
• 用0.11.13版本执行terraform state pull > old_state_backup.tfstate，导出完整状态文件留底
• 整理出需要保留的SQS、SNS资源的ARN或唯一标识，后续用于导入新状态
• 安装Terraform 1.3.6版本，编写符合1.x语法的新配置文件，仅包含需保留的SQS和SNS资源（注意：0.11的count语法要替换为for_each，变量定义格式、资源属性名称需对应1.x版本调整，比如部分资源的参数名称在迭代版本中已变更，需对照官方文档修正）
• 执行terraform init初始化新工作目录，再用terraform import命令逐个将SQS、SNS资源导入新状态，示例命令：

  terraform import aws_sqs_queue.my_queue https://sqs.us-east-1.amazonaws.com/123456789012/my_queue
  terraform import aws_sns_topic.my_topic arn:aws:sns:us-east-1:123456789012:my_topic
  

• 导入完成后执行terraform plan，确认配置与导入状态完全匹配、无额外变更，即可完成跨版本升级的核心环节

2. 保留SQS/SNS、销毁其他资源的实现步骤 #

方法一：基于旧版本Terraform清理 #

• 在0.11.13环境下，执行terraform state list获取所有资源列表，过滤出非SQS/SNS的资源
• 编写脚本遍历这些资源，执行terraform state rm <resource_address>将其从状态中移除（如terraform state rm aws_instance.web_server）
• 临时修改0.11配置文件，仅保留SQS/SNS的配置，执行terraform plan确认其他资源会被销毁，无误后执行terraform destroy
• 若资源数量多，可通过批量target命令销毁：

  for res in $(terraform state list | grep -v "aws_sqs_queue\|aws_sns_topic"); do
    terraform destroy -target $res -auto-approve
  done
  

方法二：基于AWS CLI批量清理 #

如果已弃用旧状态，可直接通过AWS API批量删除非保留资源：

• 从旧状态文件中提取非SQS/SNS资源的标识符（如EC2实例ID、S3桶名）
• 针对不同资源类型编写CLI命令批量删除，示例：

  # 删除EC2实例
  aws ec2 terminate-instances --instance-ids i-1234567890abcdef0 i-0987654321fedcba0
  # 删除S3桶（强制删除非空桶）
  aws s3 rb s3://my-bucket --force
  

3. 实际跨版本升级的经验总结 #

• 状态文件备份是生命线，每次操作前都要备份，建议同时存到本地和云存储
• 0.11到1.x语法差异极大，变量块结构、资源参数名称、输出定义都有变更，必须逐行对照官方文档调整配置，避免导入后出现不匹配
• 优先选择import方式构建新状态，比直接迁移旧状态更可靠——旧状态格式与1.x兼容性差，迁移易出现隐性错误
• 多环境升级时，先在测试环境跑通全流程，将所有操作步骤脚本化（如状态导出、资源过滤、导入命令生成），再批量在其他环境执行，减少重复工作和人为失误
• 销毁资源前务必多次确认，生产环境建议先执行terraform plan或AWS CLI的dry-run参数预览操作，避免误删保留资源

内容的提问来源于stack exchange，提问作者daze-hash