Docker 1.9.0“bridge”与自定义网桥相比，主机文件和SSH_CLIENT env变量有所不同 [英] Docker 1.9.0 "bridge" versus a custom bridge network results in difference in hosts file and SSH_CLIENT env variable

问题描述

我首先解释一下我要做的事情，因为可能有多种方法来解决这个问题。在Docker 1.9.0中有两个容器：

• node001（172.17.0.2）（ sudo docker run - net =<< bridge或test>> --name = node001 -h node001 --privileged -t -i -v / sys / fs / cgroup：/ sys / fs / cgroup<< image>> ）


• node002（172.17.0.3）（ ,, ）

当我使用 - net = bridge 启动它们时，我得到的正确值SSH_CLIENT 当我ssh从一个到另一个：

[root @ node001〜]＃ssh root@172.17。 0.3
root@172.17.0.3的密码：
[root @ node002〜]＃env | grep SSH_CLIENT
SSH_CLIENT = 172.17.0.3 56194 22
[root @ node001〜]＃ping -c 1 node002
ping：unknown host node002
/ p>

在docker 1.8.3中，我也可以使用我在启动时提供的主机名，在1.8.3中，最后一个ping语句工作！

在docker 1.9.0中，我没有看到任何东西被添加到 / etc / hosts 中，ping语句失败。这对我来说是个问题。所以我试图创建一个自定义网络...

docker network create --driver bridge test

当我使用 - net = test 启动两个容器时，我得到不同的值 code> SSH_CLIENT ：

[root @ node001〜]＃ssh root@172.18.0.3
root@172.18.0.3的密码：
[root @ node002〜]＃env | grep SSH_CLIENT
SSH_CLIENT = 172.18.0.1 57388 22
[root @ node001〜]＃ping -c 1 node002
PING node002（172.18.0.3）56（84）个字节的数据。
来自node002的64个字节（172.18.0.3）：icmp_seq = 1 ttl = 64 time = 0.041 ms


请注意，ip地址不是node001，它似乎代表了docker主机本身。主机文件是正确的，包含：

172.18.0.2 node001
172.18.0.2 node001.test
172.18。 0.3 node002
172.18.0.3 node002.test


我目前的解决方法是将docker 1.8.3与默认 bridge 网络，但我希望这可以与未来的docker版本一起工作。

• 是有任何方式我可以自定义测试网络，使其行为与默认的桥梁网络

或者：

• 也许使默认 bridge 网络在docker 1.9.0中写出 / etc / hosts 文件

对于不同解决方案的任何帮助或指针将不胜感激。

编辑：21-01-2016

显然，问题在1.9.1中已解决，在docker 1.8中使用 bridge ，并且使用自定义（--net =测试）在1。 9.1，现在的行为是正确的：

[root @ node001 tmp]＃ip route
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.5

[root @ node002 〜]＃env | grep SSH_CLIENT
SSH_CLIENT = 172.18.0.3 52162 22

在1.9.0中重试，看看我是不是疯了，是的，发生问题：

[root @ node001 tmp]＃ip route
默认通过172.18.0.1 dev eth0
172.18.0.0/16 dev eth0 proto kernel scope link src 172.18.0.3

[root @ node002〜] ＃env | grep SSH_CLI
SSH_CLIENT = 172.18.0.1 53734 22

所以在删除/停止/启动实例之后IP地址不完全相同，但是可以很容易地看出，ssh_client源ip在最后一个代码块中是不正确的。感谢@sourcejedi让我重新检查。

解决方案

首先，我不认为可以更改任何设置默认网络，即写入 / etc / hosts 。您显然无法删除默认网络，因此您无法使用不同的选项重新创建它们。

其次

< Dockquote>

Docker注意到其主机范围的iptables规则完全暴露容器到彼此的原始IP地址，因此从一个容器到另一个容器的连接应始终显示为源自第一个容器自己的IP地址。 docs.docker.com

我尝试使用随机容器再现您的问题。在网桥的接口上运行wireshark，我没有看到我的ping数据包。从此我得出结论，我的容器确实是直接相互交谈的;主机没有进行路由和NAT。

您需要检查客户端容器上的路由 ip route 。你有一条路线 172.18.0.2/16 ？如果您只有一个默认路由，它可能会尝试通过docker主机发送所有内容。它可能会被困惑，像伪装在外面的世界一样伪装。

如果您在特权容器中运行一些网络配置，可能会发生这种情况。我不知道发生了什么，如果你只是用 bash 启动它。

Let me first explain what I'm trying to do, as there may be multiple ways to solve this. I have two containers in docker 1.9.0:

• node001 (172.17.0.2) (sudo docker run --net=<<bridge or test>> --name=node001 -h node001 --privileged -t -i -v /sys/fs/cgroup:/sys/fs/cgroup <<image>>)
• node002 (172.17.0.3) (,,)

When I launch them with --net=bridge I get the correct value for SSH_CLIENT when I ssh from one to the other:

[root@node001 ~]# ssh root@172.17.0.3 root@172.17.0.3's password: [root@node002 ~]# env | grep SSH_CLIENT SSH_CLIENT=172.17.0.3 56194 22 [root@node001 ~]# ping -c 1 node002 ping: unknown host node002

In docker 1.8.3 I could also use the hostnames I supply when I start them, in 1.8.3 that last ping statement works!

In docker 1.9.0 I don't see anything being added in /etc/hosts, and the ping statement fails. This is a problem for me. So I tried creating a custom network...

docker network create --driver bridge test

When I launch the two containers with --net=test I get a different value for SSH_CLIENT:

[root@node001 ~]# ssh root@172.18.0.3 root@172.18.0.3's password: [root@node002 ~]# env | grep SSH_CLIENT SSH_CLIENT=172.18.0.1 57388 22 [root@node001 ~]# ping -c 1 node002 PING node002 (172.18.0.3) 56(84) bytes of data. 64 bytes from node002 (172.18.0.3): icmp_seq=1 ttl=64 time=0.041 ms

Note that the ip address is not node001's, it seems to represent the docker host itself. The hosts file is correct though, containing:

172.18.0.2 node001 172.18.0.2 node001.test 172.18.0.3 node002 172.18.0.3 node002.test

My current workaround is using docker 1.8.3 with the default bridge network, but I want this to work with future docker versions.

• Is there any way I can customize the test network to make it behave similarly to the default bridge network?

Alternatively:

• Maybe make the default bridge network write out the /etc/hosts file in docker 1.9.0?

Any help or pointers towards different solutions will be greatly appreciated..

Edit: 21-01-2016

Apparently the problem is fixed in 1.9.1, with bridge in docker 1.8 and with a custom (--net=test) in 1.9.1, now the behaviour is correct:

[root@node001 tmp]# ip route default via 172.17.0.1 dev eth0 172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.5

[root@node002 ~]# env | grep SSH_CLIENT SSH_CLIENT=172.18.0.3 52162 22

Retried in 1.9.0 to see if I wasn't crazy, and yeah there the problem occurs:

[root@node001 tmp]# ip route default via 172.18.0.1 dev eth0 172.18.0.0/16 dev eth0 proto kernel scope link src 172.18.0.3

[root@node002 ~]# env|grep SSH_CLI SSH_CLIENT=172.18.0.1 53734 22

So after remove/stop/start-ing the instances the IP-addresses were not exactly the same, but it can be easily seen that the ssh_client source ip is not correct in the last code block. Thanks @sourcejedi for making me re-check.

解决方案

Firstly, I don't think it's possible to change any settings on the default network, i.e. to write /etc/hosts. You apparently can't delete the default networks, so you can't recreate them with different options.

Secondly

Docker is careful that its host-wide iptables rules fully expose containers to each other’s raw IP addresses, so connections from one container to another should always appear to be originating from the first container’s own IP address. docs.docker.com

I tried reproducing your issue with the random containers I've been playing with. Running wireshark on the bridge interface for the network, I didn't see my ping packets. From this I conclude my containers are indeed talking directly to each other; the host was not doing routing and NAT.

You need to check the routes on your client container ip route. Do you have a route for 172.18.0.2/16? If you only have a default route, it could try to send everything through the docker host. And it might get confused and do masquerading as if it was talking with the outside world.

This might happen if you're running some network configuration in your privileged container. I don't know what's happening if you're just booting it with bash though.

这篇关于Docker 1.9.0“bridge”与自定义网桥相比，主机文件和SSH_CLIENT env变量有所不同的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！