使用Terraform部署AWS ECS Fargate任务失败（退出码134）求助

退出码134表示容器进程收到SIGABRT信号终止，常见原因包括应用内存溢出、镜像启动失败、权限不足等。结合你的Terraform配置，按以下步骤排查：

1. 开启容器日志，获取报错详情 #

当前配置未开启日志驱动，无法看到容器启动的具体错误。修改fargate.tf中的容器定义，添加CloudWatch日志配置：

container_definitions = <<EOT
[
    {
        "name": "example_app_container",
        "image": "250531645249.dkr.ecr.us-east-1.amazonaws.com/ecr_example_repo:latest",
        "memory": 512,
        "essential": true,
        "portMappings": [
            {
                "containerPort": 3000
            }
        ],
        "logConfiguration": {
            "logDriver": "awslogs",
            "options": {
                "awslogs-group": "/ecs/backend-example-app",
                "awslogs-region": "us-east-1",
                "awslogs-stream-prefix": "ecs"
            }
        }
    }
]
EOT

可以用Terraform自动创建日志组（也可手动在CloudWatch控制台创建）：

resource "aws_cloudwatch_log_group" "ecs_backend_logs" {
  name              = "/ecs/backend-example-app"
  retention_in_days = 7
}

重新部署后，去CloudWatch日志组查看具体报错，这是定位问题最直接的方式。

2. 验证镜像本身的可用性 #

本地拉取ECR镜像并运行，确认镜像是否能正常启动：

docker pull 250531645249.dkr.ecr.us-east-1.amazonaws.com/ecr_example_repo:latest
docker run -p 3000:3000 --memory 512m 250531645249.dkr.ecr.us-east-1.amazonaws.com/ecr_example_repo:latest

如果本地启动失败，说明问题出在镜像本身：比如启动命令错误、依赖缺失、应用代码崩溃等，需要先修复镜像。

3. 调整容器内存配置 #

虽然你已提升过实例配置，但容器级别的内存限制可能仍不足。尝试：

• 增加容器的memory值，比如设为和任务总内存一致（1024）
• 添加memoryReservation软限制，允许容器动态使用更多内存：

"memory": 1024,
"memoryReservation": 512

注意Fargate的CPU和内存是绑定规格，512CPU对应1024-2048内存，1024CPU对应2048-4096内存，确保组合合法。

4. 检查权限与网络配置 #

• ECR镜像拉取权限：你的任务执行角色已绑定AmazonECSTaskExecutionRolePolicy，该策略包含拉取ECR镜像的必要权限，无需额外配置；如果是自定义ECR权限策略，需确认角色有ecr:GetDownloadUrlForLayer、ecr:BatchGetImage等权限。
• 网络配置：你的公网子网、路由表、安全组配置无明显问题，任务分配公网IP后可正常访问ECR和外部资源。

5. 优化任务定义细节 #

• Fargate的awsvpc模式下，每个任务拥有独立网络栈，hostPort配置可以省略（保持containerPort即可）。
• 确认应用实际监听的端口是否为3000，若应用监听其他端口，需同步修改containerPort。

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