Docker容器与宿主机同网段互相通信

---

相关阅读：

Docker容器时间与宿主机同步

使用Docker搭建WordPress博客

Docker私有仓库搭建及镜像删除

Docker镜像的导入和导出

在Docker上部署Ambari

---

博主最近在解决docker与宿主机同网段通信的问题，写此文章记录一下整个过程。

遇到的问题

博主用两台docker容器做datanode，当时配置Docker网络时，使用了Bridge模式，docker0网段（172.0.1.x），宿主机网段(192.1.1.x)，使用外部客户端请求下载HDFS文件，去指定的datanode上拉去数据时，外部客户端无法连接到内部的docker容器，抛出的等待超时异常，并重试下载，更换请求的下载地址为可连接的宿主机datanode后， 才成功下载数据。

于是，想要对docker的网络配置进行修改，将docker容器的IP地址设置成与宿主机同网段，并且相互连通。

---

这里先要来说一下docker网络的四种方式：

1.Host模式：

Host 模式并没有为容器创建一个隔离的网络环境。

该模式下的Docker 容器会和Host宿主机共享同一个网络namespace， Docker Container可以和宿主机一样，使用宿主机的eth0，实现和外界的通信。

Host模式特点包括：

• 容器没有隔离的 network namespace
• 容器的 IP 地址同 Docker host 的 IP 地址
• 注意：容器中服务端口号不能与Host宿主机上已经使用的端口号相冲突
• host 模式能够和其它模式共存

2.Container模式

Container网络模式是 Docker 中一种较为特别的网络的模式。处于这个模式下的 Docker 容器会共享其他容器的网络环境，因此，至少这两个容器之间不存在网络隔离，而这两个容器又与宿主机以及除此之外其他的容器存在网络隔离。

3.None模式

None 网络就是什么都没有的网络。挂在这个网络下的容器除了 lo，没有其他任何网卡。需要我们自行去配置。

4.Bridge模式

Docker 容器默认使用Bridge模式的网络。

Docker的Bridge模式和VM虚拟机的Bridge模式不同，虽然也叫Bridge，但实质上类似于VM的NAT模式。

原理是在宿主机上虚出一块网卡bridge0，然后所有容器会桥接在这块网卡的网段上。默认情况下容器能访问外部网络，但外部网络无法访问容器，需要通过暴露容器端口的方式（docker run -p）让外部网络访问容器内的服务。

---

看完了上面的介绍，当前使用的Bridge模式不适合场景，修改网络配置。

写一下曾经试过的几种方法：

注意：

如果你需要宿主机与Docker容器互通，前面两种办法不要试！！！不好使！！！

如果你仅需要Docker容器与宿主机网段相同，容器与其他同网段节点相互通信，不与宿主机进行通信，可以使用第一种方法！！

第一种办法：

创建docker  macvlan

Docker官方在1.12版本之后引入了macvlan网络驱动，可以更简单的为容器配置桥接网络

介绍一下macvlan:

macvlan的原理是在宿主机物理网卡上虚拟出多个子网卡，通过不同的MAC地址在数据链路层进行网络数据转发的，它是比较新的网络虚拟化技术，需要较新的内核支持（Linux kernel v3.9–3.19 and 4.0+）

 docker network create -d macvlan --subnet=192.168.1.0/24 --gateway=192.168.1.1 -o parent=em1 mynet

参数说明：

-d macvlan  创建macvlan网络，使用macvlan网络驱动

–subnet 指定宿主机所在网段

–gateway 指定宿主机所在网段网关

-o parent 继承指定网段的网卡

测试一下：运行容器

docker  run --net=mynet --ip=192.168.1.100 --name=test -itd centos /bin/bash

使用宿主机去ping 192.168.1.100，这时，问题出现了

[root@node1 ~]# ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
From 192.168.1.100 icmp_seq=1 Destination Host Unreachable
From 192.168.1.100 icmp_seq=2 Destination Host Unreachable
From 192.168.1.100 icmp_seq=3 Destination Host Unreachable

目的地址不可达，使用别的机器去ping 192.168.1.100，ping通了，进入容器内，也ping不同宿主机。

使用macVLAN模式的容器，无法ping通宿主机，宿主机也无法ping通该容器，对其他同网段的服务器和容器都可以联通。

第二种办法：

在网上找到的另一种办法，编辑网卡配置文件

# vi ifcfg-eno16777736
TYPE=Ethernet
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
NAME=eno16777736
UUID=2b04503d-4c0d-4f0f-8790-7b6203739892
DEVICE=eno16777736
ONBOOT=yes
BRIDGE=br0

# vi ifcfg-br0
DEVICE=br0                                          
TYPE=Bridge
BOOTPROTO=static
ONBOOT=yes
DELAY=0
STP=yes
IPADDR=192.168.1.50
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
DNS=114.114.114.114

重启网络的时候，整个网络都down了，需要去机房弄服务器接显示器修改，查找相关资料的时候，帖子大多是复制粘贴的，不知道该他们真正的试过了没有，此方法并不靠谱。

第三种办法：

使用pipework为docker容器配置独立IP

安装pipework

wget https://github.com/jpetazzo/pipework/archive/master.zip
unzip master.zip 
cp pipework-master/pipework  /usr/local/bin/
chmod +x /usr/local/bin/pipework 

创建两个容器实例，并不需要默认docker0网桥分配的172.17.0.1网段，设置为–net=none

docker run -itd –name test1 –net=none  -h test1 centos /bin/bash    

docker run -itd –name test1 –net=none  -h test2 centos /bin/bash

接下来，使用pipework命令为容器设置固定IP

[root@node1 ~]# pipework br0 test1 192.168.1.52/24@192.168.1.1
[root@node2 ~]# pipework br0 test2 192.168.1.53/24@192.168.1.1

pipework包含了200多行的shell脚本

通过network namespace，veth pair以及linux bridge完成容器网络的设置，执行过程大概包括：

查看主机是否包含br0网桥，如果不存在就创建，向容器实例test1添加一块网卡，并配置固定IP：192.168.1.53，若test1已经有默认的路由，则删除掉，将@后面的192.168.1.1设置为默认路由的网关，将test1容器实例连接到创建的br0上。

进入test1容器中，测试与test2容器和网关的连通性

[root@test1 ~]# ping 192.168.1.53
PING 192.168.1.53 (192.168.1.53) 56(84) bytes of data.
64 bytes from 192.168.1.53: icmp_seq=1 ttl=64 time=0.296 ms
64 bytes from 192.168.1.53: icmp_seq=2 ttl=64 time=0.131 ms

[root@test1 ~]# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.762 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.209 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.238 ms

说明上面的配置没有问题

但是这时，还没有完，宿主机是ping不同容器的

宿主机有两个网卡，em1和em2，em1作为管理口192.168.1.50，em2没有使用，现在，我们只需要将宿主机的em2网卡添加到br0网桥即可

[root@node1 ~]# brctl addif br0 em2
[root@node1 ~]# brctl show
bridge name	bridge id		STP enabled	interfaces	
br0		8000.02d111808f50	no		em2
							veth1pl18006
							veth1pl184096
							veth1pl184872
docker0		8000.0242a42ada41	no	

然后再进行相关的测试

使用宿主机去ping 52/53

[root@node1 ~]# ping 192.168.1.52
PING 192.168.1.52 (192.168.1.52) 56(84) bytes of data.
64 bytes from 192.168.1.52: icmp_seq=1 ttl=64 time=0.109 ms
64 bytes from 192.168.1.52: icmp_seq=2 ttl=64 time=0.114 ms
64 bytes from 192.168.1.52: icmp_seq=3 ttl=64 time=0.111 ms

[root@node1 ~]# ping 192.168.1.53
PING 192.168.1.53 (192.168.1.53) 56(84) bytes of data.
64 bytes from 192.168.1.53: icmp_seq=1 ttl=64 time=0.119 ms
64 bytes from 192.168.1.53: icmp_seq=2 ttl=64 time=0.128 ms
64 bytes from 192.168.1.53: icmp_seq=3 ttl=64 time=0.131 ms

进入容器去ping宿主机

[root@test1 ~]# ping 192.168.1.50
PING 192.168.1.50 (192.168.1.50) 56(84) bytes of data.
64 bytes from 192.168.1.50: icmp_seq=1 ttl=64 time=0.035 ms
64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=0.049 ms
64 bytes from 192.168.1.50: icmp_seq=3 ttl=64 time=0.024 ms

[root@test2 ~]# ping 192.168.1.50
PING 192.168.1.50 (192.168.1.50) 56(84) bytes of data.
64 bytes from 192.168.1.50: icmp_seq=1 ttl=64 time=0.037 ms
64 bytes from 192.168.1.50: icmp_seq=2 ttl=64 time=0.030 ms
64 bytes from 192.168.1.50: icmp_seq=3 ttl=64 time=0.033 ms

再使用window主机去测试

正在 Ping 192.168.1.52 具有 32 字节的数据:
来自 192.168.1.52 的回复: 字节=32 时间=18ms TTL=64
来自 192.168.1.52 的回复: 字节=32 时间=1ms TTL=64
来自 192.168.1.52 的回复: 字节=32 时间=4ms TTL=64

192.168.1.52 的 Ping 统计信息:
    数据包: 已发送 = 3，已接收 = 3，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 1ms，最长 = 18ms，平均 = 7ms

正在 Ping 192.168.1.53 具有 32 字节的数据:
来自 192.168.1.53 的回复: 字节=32 时间=20ms TTL=64
来自 192.168.1.53 的回复: 字节=32 时间=7ms TTL=64
来自 192.168.1.53 的回复: 字节=32 时间=11ms TTL=64
来自 192.168.1.53 的回复: 字节=32 时间=2ms TTL=64

192.168.1.53 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 2ms，最长 = 20ms，平均 = 10ms

到这里，问题总算解决了，在ambari上添加两台新配置的容器节点，并分配datanode角色，将原有的bridge网络节点删除即可，外部客户端请求下载HDFS文件不再抛出异常

注意：pipework目前还有缺陷，容器重启后IP设置会自动消失，需要重新设置。

如果觉得本博客对您有帮助，可以赞助作者哦~