Amazon AWS ECS Docker Port Optional

Question

I am using ECS-optimized image ECS and deploying using ECS.

So, if I bash into the container and curl localhost , I get the expected result (it is expected to be on port 80), this works fine.

Then if I run docker ps I get the following output

 CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1234 orgname/imagename:release-v0.3.1 "npm start" 53 minutes ago Up 53 minutes 0.0.0.0:80->80/tcp ecs-myname-1234` 

Which will mean that port 80 displayed as expected. (I also see Amazon ECS agent, but posted it above as it doesn’t matter)

Then I can run netstat -tulpn | grep :80 netstat -tulpn | grep :80 and get the following output

 (No info could be read for "-p": geteuid()=500 but you should be root.) tcp 0 0 :::80 :::* LISTEN - 

Then as root I run sudo netstat -tulpn | grep :80 sudo netstat -tulpn | grep :80 and I get the following output

 tcp 0 0 :::80 :::* LISTEN 21299/docker-proxy 

Does it make me think it's just listening to the IPv6 interface? I'm like a host entry for localhost 127.0.0.1, so when I run curl localhost or curl 127.0.0.1 on the host, I get curl: (56) Recv failure: Connection reset by peer

I also checked ACLS security groups and networks (not that they should affect localhost) ...

Any thoughts would be greatly appreciated!

Edit: For good measure (some say netstat only shows ipv6, not ipv4 when ipv6 is available. I also lsof -OnP | grep LISTEN this command. lsof -OnP | grep LISTEN gives the following output

 sshd 2360 root 3u IPv4 10256 0t0 TCP *:22 (LISTEN) sshd 2360 root 4u IPv6 10258 0t0 TCP *:22 (LISTEN) sendmail 2409 root 4u IPv4 10356 0t0 TCP 127.0.0.1:25 (LISTEN) exe 2909 root 4u IPv4 13802 0t0 TCP 127.0.0.1:51678 (LISTEN) exe 21299 root 4u IPv6 68069 0t0 TCP *:80 (LISTEN) exe 26395 root 4u IPv6 89357 0t0 TCP *:8080 (LISTEN) 

Answer 1

I encountered this problem when using network bridge mode. I have not found a solution yet. However, I used two workarounds.

workarounds

The easiest thing for me was to change NetworkMode for host in my ECS task definition.

In addition, you can eliminate the need to know or care about how ports are mapped using the Application Load Balancer .

Network modes

bridge maps the container port to another port (which may differ) on the host through docker-proxy. This is the mode I had problems with in ECS.

host allows a container to open a port directly on the host without requiring a proxy. The disadvantage is that instances of the same container cannot run on the same host without causing port conflicts.

awsvpc is similar to host except that it maps to the ENI in your VPC instead of the port on the host's awsvpc IP.

none is what it looks like.

Application load balancer

After posting this answer, my project requirements have changed. I did not have the opportunity to go back and test the bridge mappings in bridge mode directly. However, I am currently using Application Load Balancer to provide access to my containers.

When using ALB, you don’t have to worry about the host port at all. Instead, your ECS automatically adds your container as a target to this ALB target group. This document contains detailed information on how to do this:

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html

We will not dwell here in detail, because this is not a direct answer to the question about port binding problems.

---

Interestingly, network modes for ECS were announced just 5 days after you asked your question:

Announcement: https://aws.amazon.com/about-aws/whats-new/2016/08/amazon-ec2-container-service-now-supports-networking-modes-and-memory-reservation/

Network Mode Documentation: https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html#ECS-RegisterTaskDefinition-request-networkMode

Hope this answer helps a few other Googlers. Note I will update this answer if I find out how to correctly bridge mode in ECS.

Answer 2

I had a similar problem, but I was running Java in Docker, which was bound only to the IPv6 port. Turns out to be related to Java. Read more about it here.