Question

我正在尝试为我的项目设置开发环境。

我有一个容器（ms1）应放在他自己的网络中（＆＃34;服务＆＃34;在我的情况下），以及一个容器（apigateway）应该访问该网络，同时将一个http端口暴露给主持人的网络。

理想情况下，我的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和网络。

我还有其他选择吗？

目前我正在使用它：

   apigateway:
        networks:
            services:
                aliases:
                    - api
        ports:
            - "127.0.0.1:10000:13010"

然后apigateway容器侦听0.0.0.0:13010。它有效，但它很慢，如果主机的互联网连接断电，它就会冻结。

另外，我计划将来在docker上使用vagrant，是否允许以干净的方式解决？

Answer 1

我会试试这个：

1 /找到主机网络 docker network ls

2 /使用此dockercompose文件

     services:
          ms1:
              ports:
                  - "13010"
              networks:
                  - service
          apigateway:
              networks:
                  - front
                  - service

      networks:
          front:
          service:
              external:
                  name: "<ID of the network>"

Answer 2

在docker 1.13中，您应该能够创建一个服务来桥接两个网络。我正在使用类似于修复another problem的内容，我认为这也有助于此：

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

Answer 3

在docker-compose does not publish the port on the host中

expose。由于您可能不再需要服务链接（相反，您应该依赖Docker网络），因此该选项的价值通常有限，并且在您的方案中似乎根本没有为您提供任何价值。

我怀疑你错误地使用它并且在意识到它本身似乎没有任何影响之后，偶然发现使用主机网络驱动程序会“制造”这行得通”。注意，这与expose属性无关。只是主机网络驱动程序允许包含的进程直接绑定到主机网络接口。多亏了这一点，您可以从外部访问API网关进程。您可以删除expose属性，但它仍然有效。

如果这是您选择主机网络驱动程序的唯一原因，那么您已成为X-Y problem的受害者：

<强>（TL; DR）在正常情况下，您永远不需要使用主机网络驱动程序，默认的桥接网络驱动程序可以正常工作。你要找的是ports属性，而不是expose。这将在幕后设置适当的端口转发。

在docker compose中使用主机网络和其他网络

3 个答案: