AWS Fargate服务启动报错：Network bindings - not configured 求助排查

Let’s break down why your main Drone Server service is failing to start while the other two work fine, even with the same Terraform module. The "Network bindings - not configured" error combined with health check failures points to a few specific issues worth investigating:

1. Fix Port Mapping for Fargate Compatibility #

In Fargate's awsvpc network mode (which you’re using), the hostPort parameter in your task definition has strict constraints or is effectively ignored. While you set hostPort: 80 to match containerPort:80, Fargate doesn’t support custom host port assignments—instead, you should either omit hostPort entirely or set it to 0 (to let AWS auto-assign an ephemeral port; the ALB will still route traffic correctly to your container port).

Update your port mappings in the task definition to:

"portMappings": [
  {
    "protocol": "tcp",
    "containerPort": 80
  }
]

Or if you prefer to keep the field explicitly:

"portMappings": [
  {
    "hostPort": 0,
    "protocol": "tcp",
    "containerPort": 80
  }
]

This ensures Fargate properly configures network bindings without conflicts.

2. Verify the Drone Image's Listening Port #

It’s possible the drone/drone:1 image doesn’t actually listen on port 80 by default. Test this locally first to confirm:

docker run -p 8080:80 drone/drone:1

Then try curling http://localhost:8080—if you get no response, check the Drone documentation to find the correct default port (some versions use port 3000). Adjust your containerPort in the task definition to match the actual port the Drone server listens on.

3. Audit ALB Target Group Health Checks #

The task is being terminated by the ALB due to health check failures, so double-check your target group configuration:

• Ensure the health check port is set to "Traffic Port" (so it uses the container port you defined).
• Confirm the health check path matches a valid endpoint on the Drone server (e.g., /healthz—check Drone docs for the official health endpoint).
• Adjust the health check timeout and interval values if they’re too aggressive (a 2-second timeout might be too short for the Drone server to fully start up).

4. Inspect Container Startup Logs #

Your task definition uses CloudWatch Logs (awslogs-group: /drone), so head to the CloudWatch console and check the logs for failed drone-server containers. Look for errors like:

• Port already in use
• Missing required environment variables (Drone needs critical configs like DRONE_SERVER_HOST or DRONE_RPC_SECRET)
• Failed initialization of the server

These logs will give you the most direct insight into why the container isn’t starting properly.

5. Validate Environment Variables for the Main Service #

Since the other two services work with the same module, the issue is likely in the unique environment variables for the Drone server. Ensure you’ve set all required variables (like DRONE_SERVER_PORT if it overrides the default port) and that there are no typos or missing values. Even a single incorrect environment variable can prevent the server from binding to the expected port.

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