我正在使用ECS优化的ECS映像并使用ECS进行部署.
因此,如果我打入容器并卷曲localhost我得到预期的输出(预计在80端口),这工作正常.
然后,如果我运行docker ps
我得到以下输出
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`
这表明端口80正按预期映射. (我也看到了亚马逊ECS代理,但上面发布的内容并不重要)
然后我可以运行netstat -tulpn | grep：80,我得到以下输出
(No info could be read for "-p": geteuid()=500 but you should be root.)
tcp 0 0 :::80 :::* LISTEN -
然后作为root我运行sudo netstat -tulpn | grep：80,我得到以下输出
tcp 0 0 :::80 :::* LISTEN 21299/docker-proxy
这让我觉得它只是在监听IPv6接口？我作为localhost的主机记录是127.0.0.1这就是为什么当我在主机上运行curl localhost或curl 127.0.0.1时我得到卷曲：(56)Recv失败：连接由同行重置
我还检查了安全组和网络ACLS(并不是说它们应该对localhost产生影响)……
任何想法将不胜感激！
编辑：
好的措施(有人建议netstat只显示ipv6而不是ipv6,当ipv6可用时.我也运行了这个命令lsof -OnP | grep LISTEN给出以下输出
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)
对我来说最简单的方法是将NetworkMode更改为在我的ECS任务定义中托管.
或者,您可以使用应用程序负载均衡器消除了了解或关注端口映射方式的需要.
网络模式
bridge通过docker-proxy将容器端口映射到主机上的另一个端口(可能是不同的).这是我在ECS中遇到麻烦的模式.
host允许容器直接在主机上打开端口,而无需代理.缺点是同一容器的实例无法在同一主机上运行而不会导致端口冲突.
awsvpc就像主机一样,除了它映射到VPC中的ENI而不是主机IP上的端口.
听起来没什么.
应用程序负载均衡器
自发布此答案以来,我的项目要求已发生变化.我没有机会直接回到桥接模式测试端口映射.但是,我现在使用Application Load Balancer来提供对我的容器的访问.
使用ALB时,您根本不必担心主机端口.相反,您的ECS服务会自动将您的容器作为目标添加到给定的ALB目标组.本文档详细介绍了如何执行此操作：
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html
这里没有详细说明,因为它不是关于端口绑定问题的直接答案.
有趣的是,ECS的网络模式是在您提出问题后5天宣布的：
希望这个答案可以帮助其他一些Google员工.注意：如果我弄清楚如何在ECS中使桥接模式正常工作,我会更新这个答案.
