在Docker中使用主机networking和其他networking组成
我试图为我的项目build立一个开发环境。
我有一个容器（ms1），应该放在他自己的networking（在我的情况下是“服务”）和一个容器（apigateway），它应该访问该networking，同时暴露一个http端口到主机的networking。
理想情况下，我的docker组成文件将如下所示：
version: '2' services: ms1: expose: - "13010" networks: services: aliases: - ms1 apigateway: networks: services: aliases: - api network_mode: "host" networks: services: docker-compose不允许同时使用network_mode和networking。
我有其他的select吗？
目前我正在使用这个：
apigateway: networks: services: aliases: - api ports: - "127.0.0.1:10000:13010"
然后在0.0.0.0:13010上监听。 它可以工作，但速度很慢，如果主机的networking连接断开，它会冻结。
另外，我计划将来在docker上使用stream浪汉，是否允许以一种干净的方式解决？
我会试试这个：
1 /find主机networkingdocker network ls
2 /使用这个dockercompose文件
services: ms1: ports: - "13010" networks: - service apigateway: networks: - front - service networks: front: service: external: name: "<ID of the network>"
在docker1.13你应该能够创build一个服务来桥接两个networking之间。 我正在使用类似的东西来解决另一个问题 ，我想这也可以在这里帮助：
docker service create \ --name proxy \ --network proxy \ --publish mode=host,target=80,published=80 \ --publish mode=host,target=443,published=443 \ --constraint 'node.hostname == myproxynode' \ --replicas 1 \ letsnginx
docker-compose 中 expose 的端口不会在主机上发布 。 由于您可能不再需要服务连接（相反，您应该依靠Dockernetworking，因为您已经这样做了），该选项的价值总体上有限，似乎在您的scheme中对您没有任何价值。
我怀疑你是错误地使用它，并意识到它似乎没有任何作用本身，偶然发现使用主机networking驱动程序将“使其工作”的事实。 这与expose财产没有任何关系，介意你。 只是主机networking驱动程序允许包含的进程直接绑定到主机networking接口。 由此，您可以从外部访问API网关进程。 你可以删除expose属性，它仍然可以工作。
如果这是您select主机networking驱动程序的唯一原因，那么您已经成为XY问题的牺牲品：
（tl; dr）在正常情况下，您永远不需要使用主机networking驱动程序，默认桥接networking驱动程序就可以正常工作。 你正在寻找的是ports属性，而不是expose 。 这在后台设置了适当的端口转发。