gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-12-02 18:32:59 25 4
gpt4 key购买 nike

让我先解释一下我想要做什么,因为可能有多种方法可以解决这个问题。我在 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_CLIENT 的正确值当我从一个到另一个 ssh 时:
    [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 语句失败。这对我来说是个问题。所以我尝试创建一个自定义网络......
    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 的 docker 1.8.3网络,但我希望它适用于 future 的 docker 版本。
  • 有什么方法可以自定义test网络使其行为类似于默认 bridge网络?

  • 或者:
  • 可能会设为默认 bridge网络写出/etc/hosts docker 1.9.0 中的文件?

  • 任何有关不同解决方案的帮助或指示将不胜感激。

    编辑:21-01-2016

    显然问题在 1.9.1 中得到解决,在 docker 1.8 中使用桥接器,在 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 让我重新检查。

    最佳答案

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

    第二

    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



    我尝试使用我一直在玩的随机容器重现您的问题。在网络的桥接接口(interface)上运行wireshark,我没有看到我的ping包。由此我得出结论,我的容器确实在直接相互交谈;主机没有进行路由和 NAT。

    您需要检查客户端容器上的路由 ip route .您有前往 172.18.0.2/16 的路线吗? ?如果您只有默认路由,它可能会尝试通过 docker 主机发送所有内容。它可能会感到困惑并伪装成好像在与外界交谈一样。

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

    关于Docker 1.9.0 "bridge"与自定义桥接网络导致主机文件和 SSH_CLIENT 环境变量的差异,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/34066259/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com