Terraform为指定AWS EC2配置user_data条件判断及脚本不执行问题

这个需求完全可以实现。你当前的条件判断逻辑本身没有问题，传入的user_data脚本未执行和条件写法无关，是EC2 user_data运行机制、Terraform配置细节的常见坑导致的。

核心问题排查与修复 #

• 首先检查脚本shebang头
  EC2通过cloud-init执行user_data时，只会识别首行带合法解释器声明的脚本。如果你的shell脚本首行没有写#!/bin/bash，或者shebang前有空行、BOM头，cloud-init会直接把user_data当作普通元数据存储，不会执行。
  实例启动后可以直接查看/var/log/cloud-init-output.log日志，这个文件会记录user_data的全量执行输出，能快速定位是脚本没被识别，还是脚本本身执行报错。
• 修正file函数的冗余写法与路径问题
  你当前写的"${file(var.file_name)}"属于冗余写法，不需要套字符串插值，直接写file(var.file_name)即可。同时要确认：
  • var.file_name指向的文件路径正确，Terraform执行plan阶段没有报文件不存在的错误
  • 脚本文件是UTF-8无BOM编码，Windows环境下编辑的脚本很容易带BOM头，直接导致shebang识别失败
• 注意user_data的执行时机与lifecycle拦截规则
  user_data默认仅在实例首次启动时执行一次。如果你是先创建了不带user_data的实例，后续修改配置追加user_data，Terraform会判定这个变更需要重建实例才能生效。但你配置了lifecycle { prevent_destroy = true }，这个重建操作会被直接拦截，实例不会更新，新的user_data自然不会执行。
  测试阶段建议临时关闭prevent_destroy，等配置验证通过后再开启，避免正常的变更测试被拦截。

修正后的参考配置 #

resource "aws_instance" "web" {
  count                       = length(var.vms)
  ami                         = data.aws_ami.ubuntu.id
  instance_type               = var.instance_type
  key_name                    = var.key_name
  get_password_data           = false
  associate_public_ip_address = true
  vpc_security_group_ids      = [var.secgr_id]
  iam_instance_profile        = aws_iam_instance_profile.ec2_instance_profile.name

  # 保留原有条件逻辑，去掉冗余插值
  user_data = var.vms[count.index] == "some-vm-name" ? file(var.file_name) : null
  # 明确user_data变更时触发实例替换，避免静默不生效
  user_data_replace_on_change = true

  tags = {
    Name = var.vms[count.index]
  }

  lifecycle {
    # 测试阶段关闭，验证通过后再开启防止误删
    prevent_destroy = false
  }
}

验证流程 #

1. 确认本地待传入的脚本首行是#!/bin/bash，脚本本身语法无错误
2. 执行terraform plan时，确认目标实例的user_data字段显示为预期的脚本内容，非目标实例显示为null
3. 实例启动后，登录实例执行cat /var/lib/cloud/instance/user-data.txt，确认内容和本地脚本完全一致
4. 查看/var/log/cloud-init-output.log确认脚本执行状态，如果有脚本语法错误直接在日志里就能看到报错信息

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