更新ECS任务定义未自动触发服务部署的原因与配置排查

ECS服务本身没有“任务定义更新自动部署”的原生开关，你观察到的服务行为差异，完全是Terraform编排时的资源配置差异导致的，核心影响因素有三个：

• task_definition参数的传值逻辑差异
  当aws_ecs_service资源的task_definition参数引用的是带版本号后缀的完整任务定义ARN（也就是aws_ecs_task_definition资源直接输出的arn属性值，格式类似arn:aws:ecs:region:account-id:task-definition/family-name:N），每次你更新任务定义生成新版本N+1时，Terraform会检测到服务配置的task_definition值和实际状态不一致，自动调用UpdateService API绑定新版本，触发滚动部署，不需要手动加--force-new-deployment参数。
  如果你手动拼接了不带版本号的任务定义ARN、硬编码了固定版本的ARN，Terraform更新完任务定义后，检测不到服务配置有变化，就不会触发服务更新，自然不会拉取新任务版本。
• 部署控制器类型差异
  检查服务的deployment_controller配置：默认值为ECS时，只要任务定义绑定关系变更就会自动触发滚动部署；如果配置为CODE_DEPLOY或EXTERNAL（对接蓝绿发布、第三方GitOps/发布工具），即使任务定义版本更新，ECS也不会主动触发部署，必须由对应的发布控制器发起部署流程。
• 生命周期忽略规则差异
  如果对应服务的aws_ecs_service资源里写了lifecycle { ignore_changes = [task_definition] }，Terraform会完全跳过任务定义字段的变更检测，不管任务定义更新多少个版本，都不会修改服务配置，自然不会触发自动部署。

要实现任务定义更新后自动触发部署，直接在服务资源里引用任务定义资源输出的完整ARN即可，不需要额外加特殊配置：

resource "aws_ecs_task_definition" "demo_svc" {
  family                   = "demo-service"
  container_definitions    = jsonencode([...])
  execution_role_arn       = aws_iam_role.ecs_task_exec.arn
  network_mode             = "awsvpc"
  requires_compatibilities = ["FARGATE"]
  cpu                      = "256"
  memory                   = "512"
}

resource "aws_ecs_service" "demo_svc" {
  name            = "demo-service"
  cluster         = aws_ecs_cluster.main.id
  # 直接引用任务定义的ARN输出，自带版本号，不要手动截断后缀
  task_definition = aws_ecs_task_definition.demo_svc.arn
  desired_count   = 2
  launch_type     = "FARGATE"
  network_configuration {
    subnets         = aws_subnet.private[*].id
    security_groups = [aws_security_group.ecs_svc.id]
  }
}

对行为不一致的两个服务执行terraform state show aws_ecs_service.<服务名>，分别对比三个字段即可定位差异：

• 看task_definition字段值是否带版本号后缀
• 看deployment_controller.0.type的值是否为ECS
• 看资源块内是否配置了针对task_definition的ignore_changes规则

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