- Newest
- Most votes
- Most comments
I figured it out.
Indeed, I didn't see any Container Instances in the ECS Cluster Dashboard. I thought that they don't show up because the Capacity Provider manages everything and as long as they show up at the Capacity Provider, everything should work. Apparently that was wrong. I noticed in the CloudTrail logs that there were errors from the ECS Agent running on the instances that said that it was not able to register the instance with the "default" Cluster.
To fix this, I added the ECS Cluster name to the config file for the ECS Agent. The updated definition for the launch configuration looks like this.
resource "aws_launch_configuration" "ecs_lc" {
name_prefix = "ecs-lc-"
image_id = data.aws_ami.ecs_ami.id
instance_type = "t3.micro"
iam_instance_profile = aws_iam_instance_profile.ecs_instance_profile.name
security_groups = [aws_security_group.ecs_sg.id]
associate_public_ip_address = true
user_data = <<-EOF
#!/bin/bash
echo ECS_CLUSTER=${aws_ecs_cluster.main.name} >> /etc/ecs/ecs.config
EOF
}
Now, the EC2 instances that were created by the Capacity Provider show up in the Cluster Dashboard correctly and the Tasks can be executed.
The issue you're experiencing with tasks stuck in the "Provisioning" state despite having EC2 instances available is likely due to a mismatch between the task requirements and the instance capabilities. Here are a few potential reasons and solutions:
-
Network Mode: Your task definition uses "network_mode = "none"", which is not typical for EC2 tasks. Try changing it to "bridge" or "awsvpc" mode, as these are more commonly used and might resolve the issue.
-
Resource Requirements: Ensure that the EC2 instances in your Auto Scaling group have enough resources to accommodate the task. Even though you've specified t3.micro instances, which should be sufficient for the defined task, it's worth double-checking that the CPU and memory requirements are met.
-
Placement Constraints: If you have any placement constraints defined for your tasks (not shown in the provided configuration), make sure they're not preventing task placement on the available instances.
-
IAM Permissions: Verify that the IAM role attached to your EC2 instances (ecs_instance_role) has all the necessary permissions for ECS operations.
-
ECS Agent: Ensure that the ECS agent is running correctly on the EC2 instances. You can check this by SSHing into an instance and verifying the agent's status.
-
Cluster Recognition: Make sure the EC2 instances are properly registered with the ECS cluster. This should happen automatically with the ECS-optimized AMI, but it's worth confirming.
-
Capacity Provider Settings: Your capacity provider settings look correct, but you might want to experiment with different target capacity values (e.g., 80 instead of 100) to see if it affects task placement.
-
CloudWatch Logs: Enable CloudWatch logs for your ECS cluster and tasks to get more detailed information about why task placement might be failing.
If none of these solutions work, you may need to review the ECS service events and CloudTrail logs for more detailed error messages. Additionally, consider temporarily increasing the desired count of your Auto Scaling group to 1 to ensure an instance is always available for troubleshooting.
Sources
Amazon ECS managed scaling behavior - Amazon Elastic Container Service
Amazon ECS task stuck in a lifecycle state | AWS re:Post
ECS Capacity Provider not working when task memory exceeds 16G | AWS re:Post
Amazon ECS standalone tasks - Amazon Elastic Container Service
Amazon ECS capacity providers for the EC2 launch type - Amazon Elastic Container Service
Relevant content
asked 4 years ago
asked 4 years ago
- AWS OFFICIALUpdated 2 years ago
