docker BRIDGE 和 HOST 模式有什么区别?

and*_*ndy 11 docker google-cloud-platform

你能给我一份指南或图表来理解差异吗?

我问这个问题的原因是我无法使用以下方法打开网站:

docker network create -d bridge mybridge 
docker run -d --net mybridge --name db redis 
docker run -d --net mybridge -e DB=db -p 8000:5000 --name web chrch/web 
Run Code Online (Sandbox Code Playgroud)

但我可以使用以下方法打开网站:

docker run --rm -d --network host --name my_nginx nginx
Run Code Online (Sandbox Code Playgroud)

我使用谷歌云平台VM实例并自己安装docker。

Ort*_*kni 15

根据有关桥接网络docker 文档

就 Docker 而言,桥接网络使用软件桥接器,允许连接到同一桥接网络的容器进行通信,同时提供与未连接到该桥接网络的容器的隔离。

根据有关主机网络docker文档

如果您为容器使用主机网络驱动程序,则该容器的网络堆栈不会与 Docker 主机隔离。例如,如果您运行绑定到端口 80 的容器并使用主机网络,则容器的应用程序将在主机 IP 地址的端口 80 上可用。

如果您想部署多个容器,它们之间使用私有内部网络连接,请使用桥接网络。如果你想部署一个容器连接到与主机相同的网络堆栈(并访问与主机相同的网络),请使用主机网络。如果您只是想发布一些端口,请使用--publish-p选项运行容器,例如-p 8080:80

  • 为了澄清起见,我将修改最后一句,如下所示:“如果您只是想发布一些端口,请使用桥接网络并使用...运行容器” (3认同)

Dav*_*aze 9

在您的第一个示例中,我希望应用程序可以通过主机的 IP 地址在端口 8000(重新映射的端口)和第二个端口 5000(主机网络没有重新映射选项)访问。如果有某种配置或防火墙问题阻止了它的工作,你应该解决这个问题,而不是用--net host.


Bridge 网络是 Docker 的标准网络模式。如果可能,您应该更喜欢它。令人困惑的是,它有两种不同的模式,但是您使用显式显示的形式docker network create是最佳实践,您应该尽可能使用它。主机网络完全禁用了 Docker 的网络隔离。这意味着容器可以看到并使用与主机可用的网络接口完全相同的网络接口,而无需中间的 NAT 层。

使用桥接网络,您需要docker run -p选择使特定端口在 Docker 之外可见。作为操作员,您可以重新映射端口、绑定到多宿主系统上的特定接口,或者干脆拒绝让其他主机看到服务。显式docker network create形式允许容器使用它们docker run --name作为主机名相互连接。如果您在同一主机上运行多个应用程序堆栈,则可以通过使用单独的网络将它们彼此部分隔离。每个容器都有自己独立的网络空间,localhost意思是“这个容器”。这种模式也是多主机系统(如 Docker Swarm 或 Kubernetes)中网络模型的一个简单步骤。

使用主机网络,以上都不起作用;您无法使用docker run --net host -p ...,也无法选择端口在何处或如何公开。您无法访问其他容器,除非它们被配置为自己发布端口。由于您使用的是主机的网络,因此localhost意味着主机对其自身的看法。

对于所有在 SO 答案中经常推荐的内容,--net host很少有必要。我能想到的两种情况是针对需要询问主机网络堆栈的服务(例如,像 Consul 这样的服务发现系统需要知道主机正在侦听的每个端口以进行通告)或针对服务它使用的端口集很大或不一致。如果您使用--net host是因为您localhost在应用程序中进行了硬编码,那么最好将其设置为可配置的..