Terraform因代码bug卡住如何安全终止？plan操作是否重要？

处理卡住/重试循环的最优方式 #

• 自定义资源超时：针对容易卡住的操作（比如SSH provisioner），在资源块里添加timeouts配置，比如：

  resource "aws_instance" "example" {
    # 其他配置...
    provisioner "remote-exec" {
      inline = ["echo hello"]
      connection {
        type        = "ssh"
        user        = "ec2-user"
        private_key = file("~/.ssh/id_rsa")
        host        = self.public_ip
      }
    }
    timeouts {
      create = "2m" # 把创建超时设为2分钟，避免默认长等待
    }
  }
  

• 降低并发执行数：执行terraform apply时加上-parallelism=1，单线程执行减少资源冲突导致的重试，也更容易定位问题点。
• 终止后先同步状态：用Ctrl-C终止后，先运行terraform refresh让Terraform拉取AWS的实际资源状态，之后再用terraform plan查看状态差异，按需修复代码或继续执行，不要直接手动删资源。
• 开启详细日志排查：执行命令时添加TF_LOG=INFO，比如TF_LOG=INFO terraform apply，能看到每一步的执行细节，快速定位SSH失败的根源（比如密钥错误、安全组未开放22端口等），从源头避免重试。

terraform plan的重要性 #

• 提前预览变更：terraform apply虽然会生成计划，但terraform plan能单独展示所有要创建、修改、销毁的资源，帮你提前发现误操作（比如不小心删除生产环境资源），避免执行后才后悔。
• 固化执行计划：用terraform plan -out=tfplan把计划导出为文件，后续执行terraform apply tfplan时，会严格按照这个计划执行，避免中间配置被修改导致的意外变更，适合生产环境。
• 提前暴露错误：plan阶段会做语法校验、依赖检查，很多代码错误（比如变量未定义、资源依赖缺失）在这一步就会报错，不用等到apply阶段浪费时间。
• 团队协作评审：把terraform plan的输出结果分享给团队成员，作为变更评审的依据，确保变更符合规范后再执行。

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