AWS ECS CDK部署WebSocket容器遇访问及容器异常问题求助

Let’s tackle each of your problems step by step, with fixes tailored to your CDK code:

1. No Business Containers Running on ECS Instances #

This is likely the root cause of your other issues. Let’s break down the critical mistakes in your code:

a. Invalid Environment Variable Format #

Your environment parameter uses an array of tuples, which won’t work for ECS container definitions. TypeScript/CDK expects a plain key-value object here. Fix it like this:

environment: {
  REGION: process.env.REGION,
  QUEUE_URL: core.Fn.importValue('NetworkStack:ApiMsgQueueUrl')
}

Malformed environment variables often cause containers to fail on startup, leading to ECS restarting them repeatedly or not launching them at all.

b. Missing Task Execution Role #

When using AwsLogDriver, your task needs permissions to write logs to CloudWatch. By default, Ec2TaskDefinition doesn’t create this role automatically. Add it explicitly:

const taskExecutionRole = new iam.Role(this, 'TaskExecutionRole', {
  assumedBy: new iam.ServicePrincipal('ecs-tasks.amazonaws.com'),
  managedPolicies: [
    iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AmazonECSTaskExecutionRolePolicy')
  ]
});

const taskDefinition = new ecs.Ec2TaskDefinition(this, "MyTaskDefinition", {
  executionRole: taskExecutionRole
});

Without this role, the container can’t initialize the log driver, which will block it from starting successfully.

c. Fix ECS Cluster Registration for ASG Instances #

Double-check that your Auto Scaling Group instances are joining the ECS cluster properly:

• In the ECS console, go to your cluster’s "ECS Instances" tab to confirm instances are listed.
• If instances are missing, SSH into an instance and run sudo systemctl status ecs to verify the ECS agent is running.
• Attach the required managed policy to your ASG’s instance role (your CDK code doesn’t set this explicitly):

autoScaleGroup.role.addManagedPolicy(
  iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonEC2ContainerServiceforEC2Role')
);

2. Can’t Access Target Endpoints from Inside the Container #

Once your container is running, if it still can’t reach external endpoints (like your SQS queue), check these points:

a. Validate Network Access #

You set natGateways: 0 with only public subnets—public subnet instances have direct internet access via the internet gateway, so outbound traffic should work (your security group has allowAllOutbound: true, which is correct). However:

• Ensure your target endpoint (e.g., SQS queue) is accessible from your VPC. If using a VPC endpoint for SQS, confirm the subnet is associated with the endpoint and security groups allow traffic.
• Verify the QUEUE_URL value is correctly resolved: Check the task definition in the ECS console to see if the imported value is populated.

b. Check Application Binding #

Make sure your WebSocket app inside the container binds to 0.0.0.0 instead of localhost. If it only listens on localhost, it won’t be accessible even from the ECS instance itself.

3. Can’t Use docker exec to Enter Containers #

First, fix issue #1 to ensure the container is running. Once it’s up:

a. SSH Into the ECS Instance First #

To use docker exec, you need to SSH into the ECS instance using your default-keypair first. Then:

• List running containers with docker ps.
• Use the container ID to run: docker exec -it <container-id> /bin/bash (adjust to sh if your image uses a different shell).

b. Enable ECS ExecuteCommand (Simpler Alternative) #

For a workflow that doesn’t require SSH, enable ExecuteCommand on your service:

new ecs.Ec2Service(this, "Ec2Service", {
  cluster,
  taskDefinition,
  enableExecuteCommand: true
});

Add the required policy to your task execution role:

taskExecutionRole.addManagedPolicy(
  iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonECSExecuteCommandRolePolicy')
);

Then you can run commands directly from your local machine:

aws ecs execute-command --cluster Ec2Cluster --task <task-id> --container AppContainer --interactive --command "/bin/bash"

Additional Debugging Tips #

• Check CloudWatch Logs: Even if the container fails to start, the websocket-app log group might have error messages about startup failures.
• Inspect Task Events: In the ECS console, go to your service → Tasks → select a task → "Events" tab. This will show why tasks are failing (e.g., "CannotPullContainerError", "InvalidEnvironmentVariable").

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