Docker网络详解及pipework源码解读与实践

本文涉及的产品
公网NAT网关,每月750个小时 15CU
简介:

Docker网络详解及pipework源码解读与实践

Docker作为目前最火的轻量级容器技术,有很多令人称道的功能,如Docker的镜像管理。然而,Docker同样有着很多不完善的地方,网络方面就是Docker比较薄弱的部分。因此,我们有必要深入了解Docker的网络知识,以满足更高的网络需求。本文首先介绍了Docker自身的4种网络工作方式,然后通过3个样例 —— 将Docker容器配置到本地网络环境中、单主机Docker容器的VLAN划分、多主机Docker容器的VLAN划分,演示了如何使用pipework帮助我们进行复杂的网络设置,以及pipework是如何工作的。

1. Docker的4种网络模式

我们在使用docker run创建Docker容器时,可以用--net选项指定容器的网络模式,Docker有以下4种网络模式:

  • host模式,使用--net=host指定。
  • container模式,使用--net=container:NAME_or_ID指定。
  • none模式,使用--net=none指定。
  • bridge模式,使用--net=bridge指定,默认设置。

下面分别介绍一下Docker的各个网络模式。

1.1 host模式

众所周知,Docker使用了Linux的Namespaces技术来进行资源隔离,如PID Namespace隔离进程,Mount Namespace隔离文件系统,Network Namespace隔离网络等。一个Network Namespace提供了一份独立的网络环境,包括网卡、路由、Iptable规则等都与其他的Network Namespace隔离。一个Docker容器一般会分配一个独立的Network Namespace。但如果启动容器的时候使用host模式,那么这个容器将不会获得一个独立的Network Namespace,而是和宿主机共用一个Network Namespace。容器将不会虚拟出自己的网卡,配置自己的IP等,而是使用宿主机的IP和端口。

例如,我们在10.10.101.105/24的机器上用host模式启动一个含有web应用的Docker容器,监听tcp80端口。当我们在容器中执行任何类似ifconfig命令查看网络环境时,看到的都是宿主机上的信息。而外界访问容器中的应用,则直接使用10.10.101.105:80即可,不用任何NAT转换,就如直接跑在宿主机中一样。但是,容器的其他方面,如文件系统、进程列表等还是和宿主机隔离的。

1.2 container模式

在理解了host模式后,这个模式也就好理解了。这个模式指定新创建的容器和已经存在的一个容器共享一个Network Namespace,而不是和宿主机共享。新创建的容器不会创建自己的网卡,配置自己的IP,而是和一个指定的容器共享IP、端口范围等。同样,两个容器除了网络方面,其他的如文件系统、进程列表等还是隔离的。两个容器的进程可以通过lo网卡设备通信。

1.3 none模式

这个模式和前两个不同。在这种模式下,Docker容器拥有自己的Network Namespace,但是,并不为Docker容器进行任何网络配置。也就是说,这个Docker容器没有网卡、IP、路由等信息。需要我们自己为Docker容器添加网卡、配置IP等。

1.4 bridge模式

bridge模式是Docker默认的网络设置,此模式会为每一个容器分配Network Namespace、设置IP等,并将一个主机上的Docker容器连接到一个虚拟网桥上。下面着重介绍一下此模式。

1.4.1 bridge模式的拓扑

当Docker server启动时,会在主机上创建一个名为docker0的虚拟网桥,此主机上启动的Docker容器会连接到这个虚拟网桥上。虚拟网桥的工作方式和物理交换机类似,这样主机上的所有容器就通过交换机连在了一个二层网络中。接下来就要为容器分配IP了,Docker会从RFC1918所定义的私有IP网段中,选择一个和宿主机不同的IP地址和子网分配给docker0,连接到docker0的容器就从这个子网中选择一个未占用的IP使用。如一般Docker会使用172.17.0.0/16这个网段,并将172.17.42.1/16分配给docker0网桥(在主机上使用ifconfig命令是可以看到docker0的,可以认为它是网桥的管理接口,在宿主机上作为一块虚拟网卡使用)。单机环境下的网络拓扑如下,主机地址为10.10.101.105/24。

Docker完成以上网络配置的过程大致是这样的:

  1. 在主机上创建一对虚拟网卡veth pair设备。veth设备总是成对出现的,它们组成了一个数据的通道,数据从一个设备进入,就会从另一个设备出来。因此,veth设备常用来连接两个网络设备。
  2. Docker将veth pair设备的一端放在新创建的容器中,并命名为eth0。另一端放在主机中,以veth65f9这样类似的名字命名,并将这个网络设备加入到docker0网桥中,可以通过brctl show命令查看。

     
  3. 从docker0子网中分配一个IP给容器使用,并设置docker0的IP地址为容器的默认网关。

网络拓扑介绍完后,接着介绍一下bridge模式下容器是如何通信的。

1.4.2 bridge模式下容器的通信

在bridge模式下,连在同一网桥上的容器可以相互通信(若出于安全考虑,也可以禁止它们之间通信,方法是在DOCKER_OPTS变量中设置--icc=false,这样只有使用--link才能使两个容器通信)。

容器也可以与外部通信,我们看一下主机上的Iptable规则,可以看到这么一条

 
 
  1. -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE

这条规则会将源地址为172.17.0.0/16的包(也就是从Docker容器产生的包),并且不是从docker0网卡发出的,进行源地址转换,转换成主机网卡的地址。这么说可能不太好理解,举一个例子说明一下。假设主机有一块网卡为eth0,IP地址为10.10.101.105/24,网关为10.10.101.254。从主机上一个IP为172.17.0.1/16的容器中ping百度(180.76.3.151)。IP包首先从容器发往自己的默认网关docker0,包到达docker0后,也就到达了主机上。然后会查询主机的路由表,发现包应该从主机的eth0发往主机的网关10.10.105.254/24。接着包会转发给eth0,并从eth0发出去(主机的ip_forward转发应该已经打开)。这时候,上面的Iptable规则就会起作用,对包做SNAT转换,将源地址换为eth0的地址。这样,在外界看来,这个包就是从10.10.101.105上发出来的,Docker容器对外是不可见的。

那么,外面的机器是如何访问Docker容器的服务呢?我们首先用下面命令创建一个含有web应用的容器,将容器的80端口映射到主机的80端口。

 
 
  1. docker run -d --name web -p 80:80 fmzhen/simpleweb

然后查看Iptable规则的变化,发现多了这样一条规则:

 
 
  1. -A DOCKER ! -i docker0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.17.0.5:80

此条规则就是对主机eth0收到的目的端口为80的tcp流量进行DNAT转换,将流量发往172.17.0.5:80,也就是我们上面创建的Docker容器。所以,外界只需访问10.10.101.105:80就可以访问到容器中得服务。

除此之外,我们还可以自定义Docker使用的IP地址、DNS等信息,甚至使用自己定义的网桥,但是其工作方式还是一样的。

2. pipework的使用以及源码分析

Docker自身的网络功能比较简单,不能满足很多复杂的应用场景。因此,有很多开源项目用来改善Docker的网络功能,如pipeworkweaveflannel等。这里,就先介绍一下pipework的使用和工作原理。

pipework是由Docker的工程师Jérôme Petazzoni开发的一个Docker网络配置工具,由200多行shell实现,方便易用。下面用三个场景来演示pipework的使用和工作原理。

2.1 将Docker容器配置到本地网络环境中

为了使本地网络中的机器和Docker容器更方便的通信,我们经常会有将Docker容器配置到和主机同一网段的需求。这个需求其实很容易实现,我们只要将Docker容器和主机的网卡桥接起来,再给Docker容器配上IP就可以了。

下面我们来操作一下,我主机A地址为10.10.101.105/24,网关为10.10.101.254,需要给Docker容器的地址配置为10.10.101.150/24。在主机A上做如下操作:

 
 
  1. #安装pipework
  2. git clone https://github.com/jpetazzo/pipework
  3. cp ~/pipework/pipework /usr/local/bin/
  4. #启动Docker容器。
  5. docker run -itd --name test1 ubuntu /bin/bash
  6. #配置容器网络,并连到网桥br0上。网关在IP地址后面加@指定。
  7. #若主机环境中存在dhcp服务器,也可以通过dhcp的方式获取IP
  8. #pipework br0 test1 dhcp
  9. pipework br0 test1 10.10.101.150/24@10.10.101.254
  10. #将主机eth0桥接到br0上,并把eth0IP配置在br0上。这里由于是远程操作,中间网络会断掉,所以放在一条命令中执行。
  11. ip addr add 10.10.101.105/24 dev br0; \
  12. ip addr del 10.10.101.105/24 dev eth0; \
  13. brctl addif br0 eth0; \
  14. ip route del default; \
  15. ip route add default gw 10.10.101.254 dev br0

完成上述步骤后,我们发现Docker容器已经可以使用新的IP和主机网络里的机器相互通信了。

pipework工作原理分析

那么容器到底发生了哪些变化呢?我们docker attach到test1上,发现容器中多了一块eth1的网卡,并且配置了10.10.101.150/24的IP,而且默认路由也改为了10.10.101.254。这些都是pipework帮我们配置的。通过查看源代码,可以发现pipework br0 test1 10.10.101.150/24@10.10.101.254是由以下命令完成的(这里只列出了具体执行操作的代码)。

 
 
  1. #创建br0网桥
  2. #若ovs开头,则创建OVS网桥 ovs-vsctl add-br ovs*
  3. brctl addbr $IFNAME
  4. #创建veth pair,用于连接容器和br0
  5. ip link add name $LOCAL_IFNAME mtu $MTU type veth peer name $GUEST_IFNAME mtu $MTU
  6. #找到Docker容器test1在主机上的PID,创建容器网络命名空间的软连接
  7. DOCKERPID=$(docker inspect --format='{{ .State.Pid }}' $GUESTNAME)
  8. ln -s /proc/$NSPID/ns/net /var/run/netns/$NSPID
  9. #将veth pair一端放入Docker容器中,并设置正确的名字eth1
  10. ip link set $GUEST_IFNAME netns $NSPID
  11. ip netns exec $NSPID ip link set $GUEST_IFNAME name $CONTAINER_IFNAME
  12. #将veth pair另一端加入网桥
  13. #若为OVS网桥则为 ovs-vsctl add-port $IFNAME $LOCAL_IFNAME ${VLAN:+"tag=$VLAN"}
  14. brctl addif $IFNAME $LOCAL_IFNAME
  15. #为新增加的容器配置IP和路由
  16. ip netns exec $NSPID ip addr add $IPADDR dev $CONTAINER_IFNAME
  17. ip netns exec $NSPID ip link set $CONTAINER_IFNAME up
  18. ip netns exec $NSPID ip route delete default
  19. ip netns exec $NSPID ip route add $GATEWAY/32 dev $CONTAINER_IFNAME
  1. 首先pipework检查是否存在br0网桥,若不存在,就自己创建。若以"ovs"开头,就会创建OpenVswitch网桥,以"br"开头,创建Linux bridge。
  2. 创建veth pair设备,用于为容器提供网卡并连接到br0网桥。
  3. 使用docker inspect找到容器在主机中的PID,然后通过PID将容器的网络命名空间链接到/var/run/netns/目录下。这么做的目的是,方便在主机上使用ip netns命令配置容器的网络。因为,在Docker容器中,我们没有权限配置网络环境。
  4. 将之前创建的veth pair设备分别加入容器和网桥中。在容器中的名称默认为eth1,可以通过pipework的-i参数修改该名称。
  5. 然后就是配置新网卡的IP。若在IP地址的后面加上网关地址,那么pipework会重新配置默认路由。这样容器通往外网的流量会经由新配置的eth1出去,而不是通过eth0和docker0。(若想完全抛弃自带的网络设置,在启动容器的时候可以指定--net=none)

以上就是pipework配置Docker网络的过程,这和Docker的bridge模式有着相似的步骤。事实上,Docker在实现上也采用了相同的底层机制。

通过源代码,可以看出,pipework通过封装Linux上的ip、brctl等命令,简化了在复杂场景下对容器连接的操作命令,为我们配置复杂的网络拓扑提供了一个强有力的工具。当然,如果想了解底层的操作,我们也可以直接使用这些Linux命令来完成工作,甚至可以根据自己的需求,添加额外的功能。

2.2 单主机Docker容器VLAN划分

pipework不仅可以使用Linux bridge连接Docker容器,还可以与OpenVswitch结合,实现Docker容器的VLAN划分。下面,就来简单演示一下,在单机环境下,如何实现Docker容器间的二层隔离。

为了演示隔离效果,我们将4个容器放在了同一个IP网段中。但实际他们是二层隔离的两个网络,有不同的广播域。

 
 
  1. #在主机A上创建4Docker容器,test1test2test3test4
  2. docker run -itd --name test1 ubuntu /bin/bash
  3. docker run -itd --name test2 ubuntu /bin/bash
  4. docker run -itd --name test3 ubuntu /bin/bash
  5. docker run -itd --name test4 ubuntu /bin/bash
  6. #将test1test2划分到一个vlan中,vlanmac地址后加@指定,此处mac地址省略。
  7. pipework ovs0 test1 192.168.0.1/24 @100
  8. pipework ovs0 test2 192.168.0.2/24 @100
  9. #将test3test4划分到另一个vlan
  10. pipework ovs0 test3 192.168.0.3/24 @200
  11. pipework ovs0 test4 192.168.0.4/24 @200

完成上述操作后,使用docker attach连到容器中,然后用ping命令测试连通性,发现test1和test2可以相互通信,但与test3和test4隔离。这样,一个简单的VLAN隔离容器网络就已经完成。

由于OpenVswitch本身支持VLAN功能,所以这里pipework所做的工作和之前介绍的基本一样,只不过将Linux bridge替换成了OpenVswitch,在将veth pair的一端加入ovs0网桥时,指定了tag。底层操作如下:

 
 
  1. ovs-vsctl add-port ovs0 veth* tag=100

2.3 多主机Docker容器的VLAN划分

上面介绍完了单主机上VLAN的隔离,下面我们将情况延伸到多主机的情况。有了前面两个例子做铺垫,这个也就不难了。为了实现这个目的,我们把宿主机上的网卡桥接到各自的OVS网桥上,然后再为容器配置IP和VLAN就可以了。我们实验环境如下,主机A和B各有一块网卡eth0,IP地址分别为10.10.101.105/24、10.10.101.106/24。在主机A上创建两个容器test1、test2,分别在VLAN 100和VLAN 200上。在主机B上创建test3、test4,分别在VLAN 100和VLAN 200 上。最终,test1可以和test3通信,test2可以和test4通信。

 
 
  1. #在主机A
  2. #创建Docker容器
  3. docker run -itd --name test1 ubuntu /bin/bash
  4. docker run -itd --name test2 ubuntu /bin/bash
  5. #划分VLAN
  6. pipework ovs0 test1 192.168.0.1/24 @100
  7. pipework ovs0 test2 192.168.0.2/24 @200
  8. #将eth0桥接到ovs0
  9. ip addr add 10.10.101.105/24 dev ovs0; \
  10. ip addr del 10.10.101.105/24 dev eth0; \
  11. ovs-vsctl add-port ovs0 eth0; \
  12. ip route del default; \
  13. ip route add default gw 10.10.101.254 dev ovs0
  14. #在主机B
  15. #创建Docker容器
  16. docker run -itd --name test3 ubuntu /bin/bash
  17. docker run -itd --name test4 ubuntu /bin/bash
  18. #划分VLAN
  19. pipework ovs0 test1 192.168.0.3/24 @100
  20. pipework ovs0 test2 192.168.0.4/24 @200
  21. #将eth0桥接到ovs0
  22. ip addr add 10.10.101.106/24 dev ovs0; \
  23. ip addr del 10.10.101.106/24 dev eth0; \
  24. ovs-vsctl add-port ovs0 eth0; \
  25. ip route del default; \
  26. ip route add default gw 10.10.101.254 dev ovs0

完成上面的步骤后,主机A上的test1和主机B上的test3容器就划分到了一个VLAN中,并且与主机A上的test2和主机B上的test4隔离(主机eth0网卡需要设置为混杂模式,连接主机的交换机端口应设置为trunk模式,即允许VLAN 100和VLAN 200的包通过)。拓扑图如下所示(省去了Docker默认的eth0网卡和主机上的docker0网桥):

除此之外,pipework还支持使用macvlan设备、设置网卡MAC地址等功能。不过,pipework有一个缺陷,就是配置的容器在关掉重启后,之前的设置会丢失。

3. 总结

通过上面的介绍,我相信大家对Docker的网络已经有了一定的了解。对于一个基本应用而言,Docker的网络模型已经很不错了。然而,随着云计算和微服务的兴起,我们不能永远停留在使用基本应用的级别上,我们需要性能更好且更灵活的网络功能。pipework正好满足了我们这样的需求,从上面的样例中,我们可以看到pipework的方便之处。但是,同时也应注意到,pipework并不是一套解决方案,它只是一个网络配置工具,我们可以利用它提供的强大功能,帮助我们构建自己的解决方案。

原文发布时间:2015-01-20

本文来自云栖合作伙伴“linux中国”

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
目录
相关文章
|
6天前
|
Shell Linux Docker
自定义Docker网络
这篇文章介绍了如何使用Docker命令自定义网络,并通过创建和配置网络来实现容器间的通信。
16 6
自定义Docker网络
|
6天前
|
NoSQL 应用服务中间件 Redis
Docker跨宿主机容器通信-通过网络跨宿主机互联
这篇文章介绍了Docker容器跨宿主机通信的实现方法,包括Docker的四种网络模式(host、none、container、bridge)以及如何通过修改网络配置和添加路由规则来实现不同宿主机上的容器之间的互联。
16 0
Docker跨宿主机容器通信-通过网络跨宿主机互联
|
2天前
|
云安全 安全 网络安全
云计算环境下的网络安全策略与实践
【9月更文挑战第6天】在数字化浪潮中,云计算已成为企业转型和创新的强大引擎。随之而来的网络安全挑战亦日益突出,成为制约云服务发展的关键因素。本文深入探讨了云计算环境中的安全风险,并提出了一系列切实可行的网络安全策略。从基础的数据加密到高级的身份验证机制,再到细致的访问控制和入侵检测系统的应用,我们细致勾勒出一幅全面的云计算安全蓝图。通过实例分析,文章揭示了安全策略在实际场景中的应用效果,并对未来云计算安全的发展趋势进行了前瞻性的预测。旨在为云计算服务提供商和用户双方提供指导,共同构筑更为坚固的网络安全防线。
|
4天前
|
Cloud Native 持续交付 Docker
云原生技术实践:Docker容器化部署教程
【9月更文挑战第4天】本文将引导你了解如何利用Docker这一云原生技术的核心工具,实现应用的容器化部署。文章不仅提供了详细的步骤和代码示例,还深入探讨了云原生技术背后的哲学,帮助你理解为何容器化在现代软件开发中变得如此重要,并指导你如何在实际操作中运用这些知识。
|
5天前
|
监控 安全 网络安全
云计算与网络安全的融合之路:探索云服务中的信息安全实践
【9月更文挑战第3天】在数字化转型的浪潮中,云计算已成为现代企业不可或缺的技术基石。然而,随着数据和应用逐渐迁移至云端,网络安全和信息安全的挑战亦随之升级。本文将深入探讨云计算环境下的网络安全挑战,并分享如何通过策略和技术手段加强云服务的安全防护,确保企业资产与数据的完整性、可用性和保密性。
21 5
|
9天前
|
存储 安全 网络安全
云上防御:云计算中的网络安全实践与策略
【8月更文挑战第31天】在数字时代的浪潮中,云计算已成为企业信息技术架构的心脏。随之而来的网络安全挑战也日益严峻,如何在云端构建坚不可摧的安全防线成为业界关注的焦点。本文将深入探讨云计算环境下的网络安全措施,从基础的数据加密到复杂的入侵检测系统,提供代码示例和实践策略,旨在为读者揭开云计算安全的神秘面纱,并提供实用的安全工具和解决方案。
|
9天前
|
数据采集 Rust 安全
Rust在网络爬虫中的应用与实践:探索内存安全与并发处理的奥秘
【8月更文挑战第31天】网络爬虫是自动化程序,用于从互联网抓取数据。随着互联网的发展,构建高效、安全的爬虫成为热点。Rust语言凭借内存安全和高性能特点,在此领域展现出巨大潜力。本文探讨Rust如何通过所有权、借用及生命周期机制保障内存安全;利用`async/await`模型和`tokio`运行时处理并发请求;借助WebAssembly技术处理动态内容;并使用`reqwest`和`js-sys`库解析CSS和JavaScript,确保代码的安全性和可维护性。未来,Rust将在网络爬虫领域扮演更重要角色。
24 1
|
2天前
|
安全 算法 网络安全
网络安全与信息安全:知识分享与实践
本文将深入探讨网络安全漏洞、加密技术和安全意识等方面的知识。我们将分析常见的网络攻击方式,如病毒、木马和黑客攻击,并介绍如何通过防火墙、入侵检测系统等技术手段来防止这些攻击。同时,我们还将讨论密码学在保护数据安全中的重要性,包括对称加密、非对称加密和哈希函数等概念。最后,我们将强调提高个人和组织的安全意识的重要性,包括定期更新软件、使用强密码和多因素认证等措施。
|
9天前
|
自然语言处理 C# 开发者
Uno Platform多语言开发秘籍大公开:轻松驾驭全球用户,一键切换语言,让你的应用成为跨文化交流的桥梁!
【8月更文挑战第31天】Uno Platform 是一个强大的开源框架,允许使用 C# 和 XAML 构建跨平台的原生移动、Web 和桌面应用程序。本文详细介绍如何通过 Uno Platform 创建多语言应用,包括准备工作、设置多语言资源、XAML 中引用资源、C# 中加载资源以及处理语言更改。通过简单的步骤和示例代码,帮助开发者轻松实现应用的国际化。
18 0
|
9天前
|
存储 安全 网络安全
云端防御:云计算时代的网络安全策略与实践
【8月更文挑战第31天】 在数字化转型的浪潮中,云计算已成为企业信息技术架构的核心。然而,云服务的广泛应用也带来了新的安全挑战。本文将探讨云计算环境中的网络安全问题,分析云服务的安全风险,并提出相应的防护措施。文章旨在通过技术解析和代码示例,为读者提供一套实用的云网络安全策略,确保数据安全和业务连续性。