Docker compose port forwarding无法正常工作

scyqe7ek  于 2023-04-20  发布在  Docker
关注(0)|答案(4)|浏览(274)

当我使用docker时,使用非常简单的命令:

docker run -p 80:80 nginx

端口转发工作正常,当我使用browser/curl转到localhost:80时,我可以获得nginx的“欢迎页面”。
与此同时,当我使用非常相似但docker-compose特定的配置时:

version: '3'
services:
  nginx:
    image: nginx
    ports:
     - "80:80"

当我执行docker-compose up并转到浏览器时-我看到无限加载,所以看起来端口转发没有正确配置,但我不明白配置中的错误。我尝试使用不同的浏览器和curl,我得到了相同的结果-无限加载。
Nginx在这里只是一个例子,因为它的简单性,事实上我有同样的问题与redis/mysql/java图像,所以这个问题与nginx无关。
我还尝试了以下通过docker-compose启动容器的方法:

docker-compose run -p 80:80 nginx

docker-compose run --service-ports nginx

但运气不好我得到了同样的结果
在这两种情况下(docker rundocker-compose up),我有相同的网络驱动程序类型-bridge
我比较了两种情况下docker inspect <container id>的结果:http://i.prntscr.com/obvxi0yESEa92znLDEu_PA.png
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

dockerdocker-compose都是使用Linux的官方网站说明安装的。
Host OS:Ubuntu 17.04

**更新:**我尝试在compose config中设置'attachable' network属性,问题得到解决。虽然还不清楚为什么会发生这种情况。

networks:
  default:
  attachable: true
kkbh8khc

kkbh8khc1#

在我的例子中,我使用的是不带--service-ports参数的docker-compose run,因此忽略了端口Map。
示例:
docker-compose.yml

version: "3"

services:
    app-host:
        image: nginx:1.19.0-alpine
        working_dir: /app
        volumes:
            - ./:/app/
        ports:
            - "80:3000"

command

docker-compose run --service-ports app-host

参考资料:论坛docker-compose documentation

ozxc1zmp

ozxc1zmp2#

我的解决方案是添加network_mode: 'host'
这是完整的文件

version: '3'
    
    services:
      nginx:
        image: nginx
        ports:
          - "80:80"
        volumes: ['./:/app']
        network_mode: 'host'

注:This solution only works on Linux since network_mode: host is only available to Linux hosts
此解决方案有效的原因是network_mode: host导致Docker忽略端口Map和allows the service to directly share the network with the host machine,这完全消除了对端口Map的需求。

i34xakig

i34xakig3#

我试着在compose config中设置'attachable'网络属性,这个问题已经解决了。虽然还不清楚为什么会发生这种情况。
文章“Docker Stacks and Attachable networks”将可连接网络定义为一种群覆盖网络。
这意味着在该网络上创建的服务将允许docker run命令:

docker service create --publish 80:80 --network=core-infra --name 
docker run --network=core-infra -ti ...

这些行可以在docker-compose.yml文件中指定,结果是相同的:如果网络是可连接的,则docker run将能够使用它。
创建容器docker network inspect core-infra后,将显示网络的子网和其他诊断信息。
奇怪的是,从2.1开始,网络应该是默认可连接的,正如docker-compose issue 4711中提到的那样。
可连接网络帮助Docker Swarm Services与称为Swarm的早期版本的编排进行互操作。
遗留Swarm和Swarm Services之间的核心区别在于,遗留产品允许以命令式方式调度容器。声明式Swarm Services允许我们定义想要达到的最终状态,然后Swarm将应用和维护该状态。

v09wglhw

v09wglhw4#

这是我使用docker-compose up运行的,它工作得很好。

version: '3'
services:
  nginx:
      image: nginx
      ports:
             - 80:80

相关问题