Docker 1.9.0 "bridge"与自定义网桥网络导致主机文件和SSH_CLIENT环境变量存在差异



让我首先解释一下我要做什么,因为可能有多种方法可以解决这个问题。我有两个集装箱在码头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)(,,

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

[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

在docker 1.8.3中,我也可以在启动主机名时使用它们,在1.8.3中最后一条ping语句有效!

在docker1.9.0中,我看不到/etc/hosts中添加了任何内容,并且ping语句失败。这对我来说是个问题。所以我尝试创建一个自定义网络。。。

docker network create --driver bridge test

当我用--net=test启动两个容器时,我得到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

请注意,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版本一起使用。

  • 有没有什么方法可以自定义test网络,使其行为与默认的bridge网络类似

或者:

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

任何针对不同解决方案的帮助或建议都将不胜感激。。

编辑:2016年1月21日

显然,这个问题在1.9.1中得到了解决,docker 1.8中的桥接和1.9.1中的自定义(--net=测试),现在行为是正确的:

[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 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

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

首先,我认为不可能更改默认网络上的任何设置,即写入/etc/hosts。你显然不能删除默认网络,所以你不能用不同的选项重新创建它们。

第二

Docker非常小心,其主机范围的iptables规则将容器完全暴露给彼此的原始IP地址,因此从一个容器到另一个容器的连接应该始终看起来源自第一个容器自己的IP地址。docs.docker.com

我试着用我一直在玩的随机容器复制你的问题。在网络的网桥接口上运行wireshark,我没有看到我的ping数据包。由此,我得出结论,我的容器确实在相互直接交谈;主机没有进行路由和NAT。

您需要检查客户端容器ip route上的路由。你有去172.18.0.2/16的路线吗?如果你只有一个默认路由,它可以尝试通过docker主机发送所有内容。它可能会感到困惑,并伪装成与外界对话。

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

最新更新