Docker组成端口转发不能正常工作
当我用非常简单的命令使用docker时：
docker run -p 80:80 nginx 端口转发工作正常，当我使用浏览器/ curl转到localhost：80时，我可以得到nginx的“欢迎页面”。
同时当我使用非常相似但是docker-compose特定的configuration时：
version: '3' services: nginx: image: nginx ports: - "80:80"
而当我做docker-compose up并进入浏览器 – 我看到无限加载，所以看起来像端口转发configuration不正确，但我不明白什么是错的configuration。 我尝试使用不同的浏览器和curl，我得到相同的结果 – 无限加载。
这里的Nginx只是一个例子，因为它很简单，实际上我和redis / mysql / java的图片有相同的问题，所以这个问题跟nginx没有关系。
我也尝试了以下方法通过docker-compose启动容器：
docker-compose run -p 80:80 nginx docker-compose run --service-ports nginx
但没有运气，我得到了同样的结果。
在这两种情况下（ docker run和docker-compose up ）我有相同的networking驱动程序types – bridge 。
我已经比较了两种情况下的docker inspect <container id>结果： http : //i.prntscr.com/obvxi0yESEa92znLDEu_PA.png
docker inspect <network id>结果docker inspect <network id> ： http : //i.prntscr.com/yyTpetvJSXa-dz4o9Pcl3w.png
ifconfig docker0结果：
docker0 Link encap:Ethernet HWaddr 02:42:f1:9a:b6:72 inet addr:172.17.0.1 Bcast:0.0.0.0 Mask:255.255.0.0 inet6 addr: fe80::42:f1ff:fe9a:b672/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:174 errors:0 dropped:0 overruns:0 frame:0 TX packets:837 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:47434 (47.4 KB) TX bytes:107712 (107.7 KB)
brctl show结果：
bridge name bridge id STP enabled interfaces br-f7adc3956101 8000.02427f870e7f no docker0 8000.0242f19ab672 no
主机上的ifconfig结果： https ： //pastebin.com/6ufWeYTE
在主机上的route结果：
Destination Gateway Genmask Flags Metric Ref Use Iface default gateway 0.0.0.0 UG 600 0 0 wlp4s0 link-local 0.0.0.0 255.255.0.0 U 1000 0 0 docker0 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 192.168.0.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp4s0
docker和docker-compose都是使用官方网站的Linux指令安装的。
主机操作系统：Ubuntu 17.04
更新：我已经尝试在composeconfiguration中设置“可连接”networking属性，问题已修复。 虽然还不清楚为什么会这样。
networks: default: attachable: true
尝试删除您创build的所有networking，如下所示：
docker network rm $(docker network ls -q)
然后再运行docker-compose up
这是我使用docker-compose up运行的，它工作正常。
version: '3' services: nginx: image: nginx ports: - 80:80
我试图在compose config中设置“可附加”的networking属性，问题得到解决。 虽然还不清楚为什么会这样。
文章“ Docker Stacks and Attachable networks ”定义了一个可连接的networking作为一种群集覆盖networking。
这意味着在该networking上创build的服务将允许docker run命令：
docker service create --publish 80:80 --network=core-infra --name docker run --network=core-infra -ti ...
这些行可以在docker-compose.yml文件中指定，结果将是相同的：如果networking是可连接的， docker run将能够使用它。
一旦你创build了集装箱
docker network inspect core-infra将会显示networking的子网和其他诊断信息。
奇怪的是，networking应该是自2.1以来默认可附加的，正如docker-compose issue 4711中提到的那样。
可连接的networking帮助Docker Swarm Services与之前称为Swarm的编排版本互操作。
传统Swarm和Swarm Services之间的核心区别在于传统产品允许容器按照必要的方式进行调度。 声明式群体服务允许我们定义一个我们想要达到的群体然后应用和维护的最终状态。
只是我的2美分…但是，我已经有了一个docker-compose版本的麻烦（很久以前）。 而且， docker-compose是用Python编写的，所以这个问题可能来自你的本地Python安装。
我build议你试试dduportal / docker-compose 。 它允许运行docker-compose自己作为一个容器，共享docker套接字并将本地path作为一个卷挂载，这样你的本地项目将由主机上的容器启动。
只需在你的项目目录下运行这个命令：
docker run -v "$(pwd)":"$(pwd)" \ -v /var/run/docker.sock:/var/run/docker.sock \ -e COMPOSE_PROJECT_NAME=$(basename "$(pwd)") \ --workdir="$(pwd)" \ -ti --rm \ dduportal/docker-compose:latest up
这样你就可以确定你的docker-compose文件没有问题;-)