Docker 1.9.0“bridge”与自定义桥接networking导致主机文件和SSH_CLIENT envvariables不同
让我先解释一下我正在做的事情,因为可能有多种方法来解决这个问题。 我在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)(
,,
)
当我用--net=bridge
启动它们的时候,当我从一个到另一个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语句正常工作!
在docker 1.9.0中,我看不到在/etc/hosts
添加什么东西,并且ping语句失败。 这对我来说是一个问题。 所以我试图创build一个自定义的networking…
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
我目前的解决方法是使用默认bridge
networking的docker1.8.3,但我希望这与未来的docker版本。
- 有什么办法可以自定义
test
networking,使其与默认bridge
类似?
或者:
- 也许使默认
bridge
networking在docker 1.9.0中写出/etc/hosts
文件?
任何帮助或指针不同的解决scheme将不胜感激..
编辑:21-01-2016
显然这个问题在1.9.1中得到了解决,在docker 1.8中使用bridge ,在1.9.1中使用自定义 (–net = test),现在行为是正确的:
[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让我重新检查。
首先,我不认为可以更改默认networking上的任何设置,即写入/etc/hosts
。 你显然不能删除默认的networking,所以你不能用不同的选项重新创build它们。
其次
Docker小心其主机范围的iptables规则将容器完全暴露给对方的原始IP地址,因此从一个容器到另一个容器的连接应该总是来自第一个容器自己的IP地址。 docs.docker.com
我试图用我一直在玩的随机容器来重现你的问题。 在networking的网桥接口上运行wireshark,我没有看到我的ping数据包。 由此我得出结论,我的集装箱确实是直接对话的; 主机没有做路由和NAT。
您需要检查您的客户端容器ip route
。 你有172.18.0.2/16
的路线吗? 如果你只有一个默认路由,它可以尝试通过docker主机发送一切。 它可能会混淆,做假装,仿佛在与外界交谈。
如果您在特权容器中运行某些networkingconfiguration,则可能会发生这种情况。 如果你只是用bash
启动它,我不知道发生了什么。