上述两项是Docker的默认值。如果调整过Docker守护进程的设置，或电脑上有些不同寻常的配置，则结果可能会略有不同。

现在即可使用刚查找出的恰当值来启动Resolvable容器：

$ DNSARGS=”—dns 8.8.8.8 —dns 8.8.4.4”
$ PORTARGS=”-p 172.17.42.1:53:53/udp”
$ VOLARGS=”-v /var/run/docker.sock:/tmp/docker.sock”
$ docker run -d —name res -h resolvable $DNSARGS $PORTARGS $VOLARGS \
gliderlabs/resolvable:master
5ebbe218b297da6390b8f05c0217613e47f46fe46c04be919e415a5a1763fb11

容器的启动过程中提供了以下3个关键信息。

• Resolvable需要知道在请求的地址无法映射到容器时向谁查询。答案是向上游DNS服务器查询。Resolvable会从容器内的/etc/resolv.conf获取这些值，—dns参数用于填充/etc/resolv.conf。虽然此处并不是严格必需的（指定的值是默认值），但在后面就能看到这还是相当有用的。
• 监听DNS请求的接口。使用Docker网桥的IP地址的好处在于无须将服务器暴露给外界（用0.0.0.0则会这样），且使用的是不变的IP地址（与使用容器IP地址不同）。
• Resolvable需要Docker套接字以便能查找容器名称。

对于每个运行的容器，Resolvable会创建两个名称，即<容器名称>.docker和<容器主机名>。可使用dig命令通过查找Resolvable容器自身对此进行测试（dig命令存在于Ubuntu的dnsutils包或CentOS的bind-utils中）：

$ dig +short @172.17.42.1 res.docker
172.17.0.22
$ dig +short @172.17.42.1 resolvable
172.17.0.22

这很有趣，但并不是十分有用——类似的信息使用docker inspect也可获得。不过，在启动配置使用这个新的DNS服务器的容器时，它的价值就体现出来了：

$ docker run -it —dns 172.17.42.1 ubuntu:14.04.2 bash
root@216a71584c9c:/# ping -q -c1 res.docker
PING res.docker (172.17.0.22) 56(84) bytes of data.
—- res.docker ping statistics —-
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.065/0.065/0.065/0.000 ms
root@216a71584c9c:/# ping -q -c1 www.google.com
PING www.google.com (216.58.210.36) 56(84) bytes of data.
—- www.google.com ping statistics —-
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 7.991/7.991/7.991/0.000 ms

此处证实了使用由Resolvable提供的DNS服务器可以同时访问其他容器和外界。但是，每次启动容器时都要指定—dns参数有些麻烦。好在，可以通过给Docker守护进程传递相关参数来节省时间。编辑守护进程参数（使用适合当前操作系统的方法），添加以下内容：

—bip=172.17.42.1/16 —dns=172.17.42.1

设置Docker守护进程参数　Docker守护进程的具体参数帮助详见附录B。

这些值来自本技巧开始时运行的用于查找Docker网桥细节的命令。读者需要根据自己的结果进行适当修改。—dns参数对守护进程的作用相当直观——它修改了容器使用的默认DNS服务器。与此同时，—bip将Docker网桥的配置固定了下来，这样在守护进程重启时它就不会发生潜在的变化（这会让所有容器DNS失效）。

在启动Resolvable时传递的DNS参数在这里很关键——如果未对其进行指定，Resolvable在向上游查询时将使用默认的DNS服务器，也就是指向它自身！如果这种情况发生，将产生巨量的日志，而客户端的查询将会超时。

一旦Docker守护进程完成重启，且Resolvable启动后，就可尝试启动一个容器：

$ docker run —rm ubuntu:14.04.2 ping -q -c1 resolvable
PING resolvable (172.17.0.1) 56(84) bytes of data.
—- resolvable ping statistics —-
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.095/0.095/0.095/0.000 ms

Resolvable具有一些决定性功能，虽然这里不对其进行详述，但是为了保持完整性稍作提及。如果将/etc/resolv.conf挂载到/tmp/resolv.conf上，该DNS服务器地址将被添加到宿主机的DNS服务器中，这样就可以在容器之外通过容器名称对其进行访问。使用systemd的用户可以通过将/run/systemd挂载到/tmp/systemd，并将/var/run/dbus/system_bus_socket挂载到容器中相同路径来实现类似的整合。

在使用多宿主机时，如何能方便地查找和连接到其他容器是一个热门话题。本书后续章节将对服务发现做更多详细论述。

8.2　使用Docker来模拟真实世界的网络

多数用户会将互联网当作一个黑盒看待，即通过某些方式从世界其他角落获取信息并显示在屏幕上。时不时会碰到网速慢或连接中断的情况，对ISP的抱怨屡见不鲜。

在构建的镜像包含需要进行连接的应用程序时，用户可能对哪些组件需要连接到哪里以及整体的设置情况有一个清晰的了解。但有一件事是不变的：还是会遭遇网速慢和连接中断的情况。即使是拥有并运营着自有数据中心的大型公司，也能观察到不可靠的网络及其引起的应用程序问题。

接下来介绍几种方法，对不可靠网络进行体验，以确定现实世界中可能面对的问题。

技巧71　使用Comcast模拟有问题的网络

尽管用户在进行跨多主机分发应用程序时希望网络状况尽可能好，但现实却是残酷的——分组（packet，也称数据包）丢失（也称丢包）、连接中断、网络分区比比皆是，尤其是在商用云服务供应商上。

在技术栈遭遇现实世界的这些情况之前对其进行测试以确认其行为是非常明智的—— 一个为高可用设计的应用程序不应在外部服务开始出现显著的额外延迟时陷入停顿。

问题

想要为单个容器应用不同的网络状况。

解决方案

使用Comcast（指的是网络工具，而非ISP）。

讨论

Comcast（https://github.com/tylertreat/Comcast）是一个娱乐化命名的工具，用于修改Linux机器的网络接口，以便对其应用某些不同寻常的（或者，对不走运的人而言是典型的）状况。

在Docker创建容器时，它会同时创建几个虚拟的网络接口——这也是容器具有不同IP并且可以相互通信的原因。因为这些都是标准网络接口，只要能查找出其网络接口名称，就可以在其上使用Comcast。这说起来容易做起来难。

以下Docker镜像包含了Comcast及其前置要求，以及一些优化：

$ IMG=dockerinpractice/comcast
$ docker pull $IMG
latest: Pulling from dockerinpractice/comcast
[…]
Status: Downloaded newer image for dockerinpractice/comcast:latest
$ alias comcast=”docker run —rm —pid=host —privileged \
-v /var/run/docker.sock:/var/run/docker.sock $IMG”
$ comcast -help
Usage of comcast:
　-cont=””: Container ID or name to get virtual interface of
　-default-bw=-1: Default bandwidth limit in kbit/s (fast-lane)
　-device=””: Interface (device) to use (defaults to eth0 where applicable)
　-dry-run=false: Specifies whether or not to commit the rule changes
　-latency=-1: Latency to add in ms
　-mode=”start”: Start or stop packet controls
　-packet-loss=”0”: Packet loss percentage (eg: 0.1%%)
　-target-addr=””: Target addresses, \
(eg: 10.0.0.1 or 10.0.0.0/24 or 10.0.0.1,192.168.0.0/24)
　-target-bw=-1: Target bandwidth limit in kbit/s (slow-lane)
　-target-port=””: Target port(s) (eg: 80 or 1:65535 or 22,80,443,1000:1010)
　-target-proto=”tcp,udp,icmp”: \
Target protocol TCP/UDP (eg: tcp or tcp,udp or icmp)

新增的优化提供了-cont选项，可以指向一个容器而无须查找虚拟网络接口的名称。请注意，为了赋予容器更多权限，docker run命令中增加了一些特殊的标志，这样Comcast就可以自由地对网络接口进行检查并应用变更。

为了展示Comcast可以带来的变化，先来看一下一个正常的网络连接是什么样的。打开一个新的终端，并运行以下命令来设置基准网络性能的预期：

$ docker run -it —name c1 ubuntu:14.04.2 bash
root@0749a2e74a68:/# apt-get update && apt-get install -y wget
[…]
root@0749a2e74a68:/# ping -q -c 5 www.docker.com
PING www.docker.com (104.239.220.248) 56(84) bytes of data.
—- www.docker.com ping statistics —-
5 packets transmitted, 5 received, 0% packet loss, time 4005ms （1）　　　　　　　　 
rtt min/avg/max/mdev = 98.546/101.272/106.424/2.880 ms （2）　　　　　　　　　　　　
root@0749a2e74a68:/# time wget -o /dev/null https://www.docker.com
real　　0m0.680s （3）　　　　　　　　　　 
user　　0m0.012s
sys　　 0m0.006s
root@0749a2e74a68:/#

（1）这台机器与www.docker.com的连接看起来是可靠的，没有分组丢失

（2）到www.docker.com的往返时间在100 ms左右

（3）下载www.docker.com的HTML首页总共花费时间大概是0.7 s

完成上述步骤后，保持该容器处于运行状态，然后对其应用一些网络状况：

$ comcast -cont c1 -default-bw 50 -latency 100 -packet-loss 20%
2015/07/29 02:28:13 Found interface vetha7b90a7 for container ‘c1’
sudo tc qdisc show | grep “netem”
sudo tc qdisc add dev vetha7b90a7 handle 10: root htb
sudo tc class add dev vetha7b90a7 parent 10: classid 10:1 htb rate 50kbit
sudo tc class add dev vetha7b90a7 parent 10:1 classid 10:10 htb rate 50kbit
sudo tc qdisc add dev vetha7b90a7 parent 10:10 handle 100: 
➥ netem delay 100ms loss 20.00%
sudo iptables -A POSTROUTING -t mangle -j CLASSIFY —set-class 10:10 -p tcp
sudo iptables -A POSTROUTING -t mangle -j CLASSIFY —set-class 10:10 -p udp
sudo iptables -A POSTROUTING -t mangle -j CLASSIFY —set-class 10:10 -p icmp
2015/07/29 02:28:13 Packet rules setup…
2015/07/29 02:28:13 Run sudo tc -s qdisc to double check
2015/07/29 02:28:13 Run comcast --mode stop to reset

上述命令应用了3种不同的状况：针对所有目标设置50 KB/s的带宽上限（唤起了对拨号的回忆），添加100 ms的延迟，以及20%的分组丢失率。

Comcast首先确定容器正确的虚拟网络接口，然后调用一些标准的Linux命令行网络工具来应用流量规则，并在执行过程中列出其所做的动作。来看一下容器是如何对此进行回应的：

root@0749a2e74a68:/# ping -q -c 5 www.docker.com
PING www.docker.com (104.239.220.248) 56(84) bytes of data.
—- www.docker.com ping statistics —-
5 packets transmitted, 2 received, 60% packet loss, time 4001ms
rtt min/avg/max/mdev = 200.453/200.581/200.709/0.128 ms
root@0749a2e74a68:/# time wget -o /dev/null https://www.docker.com
real　　0m9.673s
user　　0m0.011s
sys　　 0m0.011s

成功了！ping报告的延迟增加了100 ms，而对wget的计时展示了10倍左右的降速，与预期相当（带宽上限、额外的延迟及分组丢失同时产生了影响）。但是分组丢失有点儿奇怪——似乎比预期大了3倍。需要注意的很重要的一点是，ping只发送了少量的分组，而分组丢失不是精确的“五分之一”计数器——如果将ping次数提高到50，将会发现分组丢失结果与预期要接近得多。

注意，上面应用的规则对通过该网络接口的所有网络连接都有效，包括与宿主机及其他容器的连接。

现在告诉Comcast删除这些规则。Comcast还无法对单个状况进行添加或删除，因此修改某张网络接口上的任何东西意味着要完全删除或重新添加该网络接口上的规则。如果要恢复正常的容器网络操作，也必须删除这些规则。不过，在退出容器时无须考虑这些规则的删除——它们会在Docker删除虚拟网络接口时被自动删除：

$ comcast -cont c1 -mode stop
2015/07/29 02:31:34 Found interface vetha7b90a7 for container ‘c1’
[…]
2015/07/29 02:31:34 Packet rules stopped…
2015/07/29 02:31:34 Run sudo tc -s qdisc to double check
2015/07/29 02:31:34 Run comcast --mode start to start

如果读者有兴趣动手实践，可以深入挖掘Linux的流量控制工具，使用Comcast来生成要使用的命令示例集合。其可能性的完整性论述已经超出本技巧的范围，不过请记住，只要能将其放到容器内并连接到网络，就能使用它来做试验。

技巧72　使用Blockade模拟有问题的网络

对很多应用程序而言，Comcast是一个优秀的工具，不过有一个重要的使用场景它无法解决——如何将网络状况应用到全体容器中？手工对几十个容器运行Comcast将是非常痛苦的，上百个更是无法想象！这个问题对容器而言尤为相关，因为它们的启动代价非常低——如果在单台机器上运行上百个虚拟机而不是容器来模拟大型网络，将会遇到更大的问题，如内存不足！

在使用多台机器模拟网络时，有一种特殊类型的网络故障会在这种规模下变得有趣起来——网络分区。当一组网络化的机器被分成两个或更多部分时，这种情况就会出现，同一部分里的所有机器可以相互通信，但不同部分则无法通信。研究表明这种情况的发生比想象中要多得多，尤其是在消费级的云服务上！

遵循经典的Docker微服务线路可急剧缓解此类问题，而要理解服务如何对其进行处理，拥有用于做实验的工具就至关重要了。

问题

想要对大量容器进行网络状况编排设置，包括创建网络分区。

解决方案

使用Blockade。

讨论

Blockade（https://github.com/dcm-oss/blockade.git）是出自戴尔公司一个部门的开源软件，为“测试网络故障及分区”而生。看起来正是这里所需要的。

注意　在编写本书时，如果不做优化，官方的Blockade仓库无法与Docker 1.6.2之后的任何版本兼容。为了本技巧的需要，我们对其做了一些修改，希望可以贡献回去。如果读者想深入Blockade，请记住这一点。

Blockade通过读取当前目录中的配置文件（blockade.yml）来工作，该配置文件定义了容器启动的方式以及需要对其应用的状况。完整的配置细节可从Blockade文档中获得，因此这里只对核心部分进行说明。

首先需要创建一个blockade.yml：

containers:
　server:
　　image: ubuntu:14.04.2
　　command: /bin/sleep infinity
　　expose: [10000]
　client1:
　　image: ubuntu:14.04.2
　　command: sh -c “ping $SERVER_PORT_10000_TCP_ADDR”
　　links: [“server”]
　client2:
　　image: ubuntu:14.04.2
　　command: sh -c “ping $SERVER_PORT_10000_TCP_ADDR”
　　links: [“server”]
network:
　flaky: 50%
　slow: 100ms

上述配置中设置的容器代表由两个客户端连接的一个服务器。在实践中，可能是一个数据库服务器及其客户端应用程序，并且对要建模的组件数量没有任何限制。只要它能在一个compose.yml文件（见技巧68）中表示，就可以在Blockade中对其进行建模。

在server的配置中指定了要暴露的一个端口，但并未在其上提供服务也不会对其进行连接——这只是启用Docker的链接功能，并在客户端容器中暴露相关的环境变量以便让它们知道去ping哪个IP。如果使用了其他IP发现技巧，如本章讲述的DNS技巧（见技巧70），则这些链接就不是必需的。

这里暂时不用考虑network小节，稍后会对其进行说明。

与往常一样，使用Blockade的第一步是拉取镜像：

$ IMG=dockerinpractice/blockade
$ docker pull $IMG
latest: Pulling from dockerinpractice/blockade
[…]
Status: Downloaded newer image for dockerinpractice/blockade:latest
$ alias blockade=”docker run —rm —pid=host —privileged \
-v \$PWD:/blockade -v /var/run/docker.sock:/var/run/docker.sock $IMG”

可以看到，这里传递给docker run的参数与上一个技巧中的参数一致，只有一个例外——Blockade将当前目录挂载到容器中以便访问blockade.yml，并将状态存储在一个隐藏目录中。

网络化文件系统之痛　如果是运行在网络文件系统之上，第一次启动Blockade可能会遇到奇怪的权限问题，这可能是因为Docker正在尝试以root身份创建该隐藏的状态目录，而网络文件系统不予配合。解决方案是使用本地磁盘。

最后到了关键时刻——运行Blockade。要确保目前位于保存blockade.yml的目录中：

$ blockade up
NODE　　　 CONTAINER ID　 STATUS　 IP　　　　　 NETWORK　　PARTITION
client1　　8c4d956cf9cf　 UP　　　 172.17.0.53　NORMAL
client2　　fcd9af2b0eef　 UP　　　 172.17.0.54　NORMAL
server　　 b8f9f179a10d　 UP　　　 172.17.0.52　NORMAL

调试提示　在启动时，Blockade有时可能会报“/proc”中文件不存在的晦涩错误。首先检查容器是否在启动时马上退出，阻止了Blockade检查其网络状态。此外，请尽量不要使用Blockade的-c选项来指定自定义配置文件目录——容器内只有当前目录的子目录可用。

所有配置文件中定义的容器已经启动，并显示了已启动容器的一些有用信息。现在来应用一些基本的网络状况。在一个新的终端中持续打印client1的日志（使用docker logs -f 8c4d956cf9cf），以便在做修改时可以查看所发生的情况：

$ blockade flaky –all （1）
$ sleep 5 （2）　　　　　　　 
$ blockade slow client1 （3）　　　　　　
$ blockade status （4）
NODE　　　 CONTAINER ID　 STATUS　 IP　　　　　 NETWORK　　PARTITION
client1　　8c4d956cf9cf　 UP　　　 172.17.0.53　SLOW
client2　　fcd9af2b0eef　 UP　　　 172.17.0.54　FLAKY
server　　 b8f9f179a10d　 UP　　　 172.17.0.52　FLAKY
$ blockade fast –all （5）

（1）让所有容器的网络变得不稳定（分组丢失）

（2）延后下一条命令，让前一条命令有时间生效并输出一些日志

（3）让容器client1的网络变慢（为分组增加了延迟）

（4）检查容器所处的状态

（5）将所有容器恢复为正常操作

flaky和slow命令使用了之前配置文件中network一节定义的值——限定值无法在命令行中指定。如果有需要，可以在容器运行时编辑blockade.yml，然后有选择性地将新的限定值应用到容器上。需要注意的是，一个容器只能处在慢速网络或不稳定网络中，不能二者皆有。撇开这些限制，对成百上千个容器运行这一命令的便捷性还是相当可观的。

如果回头查看client1的日志，可以看到不同命令生效的时间：

64 bytes from 172.17.0.52: icmp_seq=638 ttl=64 time=0.054 ms （1）　
64 bytes from 172.17.0.52: icmp_seq=639 ttl=64 time=0.098 ms
64 bytes from 172.17.0.52: icmp_seq=640 ttl=64 time=0.112 ms
64 bytes from 172.17.0.52: icmp_seq=645 ttl=64 time=0.112 ms （2）
64 bytes from 172.17.0.52: icmp_seq=652 ttl=64 time=0.113 ms
64 bytes from 172.17.0.52: icmp_seq=654 ttl=64 time=0.115 ms
64 bytes from 172.17.0.52: icmp_seq=660 ttl=64 time=100 ms （3）　 
64 bytes from 172.17.0.52: icmp_seq=661 ttl=64 time=100 ms
64 bytes from 172.17.0.52: icmp_seq=662 ttl=64 time=100 ms
64 bytes from 172.17.0.52: icmp_seq=663 ttl=64 time=100 ms

（1）icmp_seq是连续的（没有分组丢失），time也比较低（延迟小）

（2）icmp_seq出现了一个大跳跃——flaky命令生效了

（3）time出现了一个大跳跃——slow命令生效了

虽然这很有用，不过在Comcast之上使用一些（可能是比较费力的）脚本也能实现，那么来看看Blockade的杀手锏功能——网络分区：

$ blockade partition server client1,client2
$ blockade status
NODE　　　 CONTAINER ID　 STATUS　 IP　　　　　 NETWORK　　PARTITION
client1　　8c4d956cf9cf　 UP　　　 172.17.0.53　NORMAL　　 2
client2　　fcd9af2b0eef　 UP　　　 172.17.0.54　NORMAL　　 2
server　　 b8f9f179a10d　 UP　　　 172.17.0.52　NORMAL　　 1

这会将3个节点划分成2个区域——服务器在其中一个区域，而客户端在另一个区域，它们之间无法进行通信。可以看到client1的日志停止了，因为所有的ping分组都丢失了！不过，两个客户端依然可以相互通信，这一点可以通过在二者之间发送一些ping分组来验证：

$ docker exec 8c4d956cf9cf ping -qc 3 172.17.0.54
PING 172.17.0.54 (172.17.0.54) 56(84) bytes of data.
—- 172.17.0.54 ping statistics —-
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.065/0.084/0.095/0.015 ms

没有分组丢失，延迟也很低……看起来是个不错的连接。分区及其他网络状况是独立操作的，因此可以在应用分区的同时试验分组丢失。可以定义的分区数量没有限制，因此可以尽情地对复杂场景进行试验。

最后一个建议是，将Blockade和Comcast组合起来能获得比它们单独提供的能力更强大。Blockade擅长创建分区以及完成启动容器的繁杂事务，添加Comcast则能实现每一个容器网络连接的细粒度控制！

8.3　Docker和虚拟网络

Docker的核心功能都与隔离性有关。前面几章已经展示了进程和文件系统隔离的好处，而本章呈现的是网络隔离。

可以认为网络隔离具有以下两个方面：

• 个体沙箱——每个容器具有各自用于监听的IP及端口集合，不会与其他容器（或宿主机）发生重叠；
• 组沙箱——这是个体沙箱的逻辑扩展，所有隔离的容器都被分组在同一个私有网络中，可以在不干扰主机网络（惹恼公司网络管理员）的情况下进行试验。

前面的两个技巧提供了这两个方面的一些实例——Comcast操纵单独的沙箱来为每个容器应用规则，而Blockade中的分区依赖对私有容器网络的全面监管能力来将其拆分成几部分。

这些场景的背后看起来有点儿像图8-2。

网桥工作的具体细节并不重要。简单来说，网桥在容器之间创建了一个扁平化网络（无须中间步骤即可直接通信），并将对外界的请求转发到外部连接上。

虚拟网络产生的灵活性极大地激发了第三方通过多种方式扩展网络系统以实现更复杂的用例。Docker 公司使用这些成果来引导当下（编写本书时）的工作，允许直接将网络扩展插入到Docker中而不是绕过它。

图8-2　宿主机上的Docker内部网络

技巧73　使用Weave建立一个基底网络

基底网络是构建于其他网络之上的软件级网络。从效果上看，它像是一个本地网络，但其背后还是通过其他网络进行通信。这代表着性能代价，这个网络相比本地网络稳定性要差一些，不过从可用性角度来看还是大有好处的：位置完全不同的节点可以像在同一个空间里一样进行通信。

实现这一点对Docker容器来说尤为有趣——容器可以像通过网络连接宿主机一样跨宿主机无缝地进行连接。这么做消除了规划单个宿主机上能容纳多少容器的迫切需要。

问题

想要跨宿主机进行容器间无缝通信。

解决方案

使用基底网络。

讨论

接下来将使用Weave（http://weave.works）来演示基底网络的原理，Weave是为这个目的设计的工具。图8-3展示了一个典型Weave网络的梗概。

图8-3　一个典型的Weave网络

在图8-3中，宿主机1无法访问宿主机3，不过它们可以像本地连接一样通过Weave网络相互通信。Weave网络不对公众开放——只对在Weave下启动的容器开放。这使得跨不同环境的代码开发、测试与部署变得相对简单，因为可以将所有情景中的网络拓扑都做成一样的。

1．安装Weave

Weave是一个二进制程序，可以在https://github.com/zettio/weave找到其安装说明。

Weave需要安装在要作为Weave网络一部分的所有宿主机上。可执行以下指令：

$ sudo wget -O /usr/local/bin/weave \
https://github.com/zettio/weave/releases/download/latest_release/weave
$ sudo chmod +x /usr/local/bin/weave

Weave二进制文件冲突　如果在此处遇到问题，机器上可能已经存在一个作为其他软件包一部分的Weave二进制文件。

2．设置Weave

要操作本示例，需要使用两台宿主机。此处分别将其命名为host1和host2。使用ping确保它们可以相互通信。接着获取两台宿主机的IP地址。

如何获取IP地址　一种获取宿主机IP地址的快速方法是使用浏览器访问http://ip-addr.es，或者运行curl http://ip-addr.es。

网络防火墙　如果在此处遇到问题，网络中可能存在某种形式的防火墙。如果不清楚，请与网络管理员确认。特别需要注意的是，TCP与UDP的6783端口需要同时打开。

在第一台宿主机上运行第一个Weave路由器：

host1$ curl http://ip-addr.es （1）
1.2.3.4
host1$ sudo weave launch （2）　　　　　　　
host1$ C=$(sudo weave run 10.0.1.1/24 -t -i ubuntu) （3）

（1）确认host1的IP地址

（2）以root身份在host1上启动Weave服务。这一步需要在每台宿主机上进行一次

（3）在容器内启动Weave路由器。以CIDR标记法为它指定一个IP地址和网络。此处给定的 IP 地址和网络定义了私有Weave网络的样子

什么是CIDR　CIDR是Classless Inter-Domain Routing（无类别域间路由）的缩写。它是分配IP地址和路由IP网络分组的一种方法。CIDR标记法由一个IP地址、一个斜杠及一个数字组成。最后的数字表示路由前缀中前导位的位数。其他位则形成了路由的地址空间。最后的数字越小，地址空间就越大。例如，一个192.168.2.0/24的网络将具有一个包含256个地址的8位地址空间，而一个16.0.0.0/8的网络将具有一个包含16 777 216个地址的地址空间。

在host2上可以执行类似的步骤，不过需要将host1的位置通知给Weave，并为它分配一个不同的IP地址：

host2$ curl http://ip-addr.es （1）　　　 
1.2.3.5
host2# sudo weave launch 1.2.3.4 （2）　　　　 
host2# C=$(sudo weave run 10.0.1.2/24 -t -i ubuntu) （3）

（1）确定host2的IP地址

（2）以root身份在host2上启动Weave服务。这一次添加了第一台宿主机的公共IP地址以便它可以连接到另一台宿主机上

（3）在容器内启动 Weave 路由器。为其指定了相同网络上与host1不同的IP地址

除了应用程序容器的IP地址的选择之外，host2上唯一的不同是要通知Weave，让它与host1上的Weave对等（通过host2可以访问到的IP地址或主机名及可选的“:端口”进行指定）。

3．测试连接

现在万事俱备，可以进行测试，看看容器是否能相互通信：

host1# docker attach $C （1）　　　 
root@28841bd02eff:/# ping -c 1 -q 10.0.1.2 （2）　　　　
PING 10.0.1.2 (10.0.1.2): 48 data bytes
—- 10.0.1.2 ping statistics —-
1 packets transmitted, 1 packets received, 0% packet loss （3）　　　　 
round-trip min/avg/max/stddev = 1.048/1.048/1.048/0.000 ms

（1）附加到本次交互会话早前返回的容器ID上

（2）ping 另一台服务器分配到的IP地址

（3）一个成功的ping响应

如果ping成功了，即可证实自行分配的私有网络内部的可连接性。现在可以将10.0.1.1分配给应用程序服务器，将10.0.1.2分配给Web服务器。

ICMP被阻塞？　如果（ping使用的）ICMP协议信息被防火墙阻塞，这一步就无法工作。如果出现这种情况，可以尝试telnet到另一台宿主机的6783端口来测试是否可以建立连接。

技巧74　Docker的网络与服务功能

Weave是一个优秀的工具，不过它依赖于Docker外部的一个工具，因此可能无法很好地与生态系统里的其他工具整合。

由于Weave这类工具的流行，Docker公司收集了对Docker内网络解决方案有兴趣的多家公司的反馈，并形成一个方案来尝试解决这些最迫切的需求，同时又不将人们限制在一个大而全的解决方案之中。这项工作还在进行中，不过已经接近发布了！

问题

想要一种由Docker公司支持的用于创建虚拟网络的解决方案。

解决方案

使用实验性的网络与服务功能。

讨论

在阅读本书时，Docker 可能已经在一个稳定版本中发布了（目前是）实验性的网络功能。这一点可以通过运行以下命令来确认：

$ docker network —help
Usage: docker network [OPTIONS] COMMAND [OPTIONS] [arg…]
Commands:
　create　　　　　　　　　 Create a network
　rm　　　　　　　　　　　 Remove a network
　ls　　　　　　　　　　　 List all networks
　info　　　　　　　　　　 Display information of a network
Run ‘docker network COMMAND —help’ for more information on a command.
　—help=false　　　 Print usage

如果提示类似‘network’ is not a docker command的信息，则表示需要安装Docker的实验性版本。要安装实验性功能，可查阅GitHub上的Docker Experimental Features（Docker实验性功能）页面：https://github.com/docker/docker/tree/master/experimental。

实验性功能发生根本变更　本书尽可能地保持本技巧的时效性，不过实验性功能往往会发生改变。在试验本技巧时，相应的指令可能需要做轻微改动。

这项功能的高级别目标是允许在Docker中使用网络插件把虚拟网络的创建抽象掉。这些插件要么是内置的，要么由第三方提供，都将提供一个虚拟网络。在这些场景的背后，插件将完成创建网络所需的所有必要工作，让用户可以接着使用它。在理论上，类似Weave的工具应该可以变成网络插件，带来更奇特的用例。在实践中，这个功能的设计很可能是一个迭代的过程。

运行以下命令可查看Docker拥有的网络清单：

$ docker network ls
NETWORK ID　　　　　NAME　　　　　　　TYPE
04365ecf2eaa　　　　none　　　　　　　null
c82bde52597d　　　　host　　　　　　　host
7e8c8a0eab7d　　　　bridge　　　　　　bridge

可以看出，这就是在启动容器时传递给docker run的—net选项的可选值。下面添加一个新的bridge网络（一个让容器可以在其中自由通信的扁平化网络）：

$ docker network create —driver=bridge mynet
3265097deff3847cb1f7b8e8bc924bae1c439d8bf6247458400e620b35447292
$ docker network ls | grep mynet
3265097deff3　　　　mynet　　　　　　　 bridge
$ ip addr | grep mynet
34: mynet: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue 
➥ state DOWN
　　inet 172.18.42.1/16 scope global mynet
$ ip addr | grep docker
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue 
➥ state DOWN
　　inet 172.17.42.1/16 scope global docker0

这创建了一个新的网络接口，它将使用与普通Docker网桥不同的一个IP地址范围。

接下来启动两个容器，将服务绑定到该网络中。目前，服务的概念是紧密结合在网络功能里的，容器要参与特定的网络必须具有一个服务名：

$ docker run -it -d —name c1 ubuntu:14.04.2 bash （1）
87c67f4fb376f559976e4a975e3661148d622ae635fae4695747170c00513165
$ docker service publish c1service.mynet （2）
ed190f2cc0887ac87e1024ebb425f653989582942ab25a341e3d3e2a980475f5
$ docker service attach c1 c1service.mynet （3）
$ docker run -it -d —name c2 \
—publish-service=c2service.mynet ubuntu:14.04.2 bash （4）
0ee74a3e3444f27df9c2aa973a156f2827bcdd0852c6fd4ecfd5b152846dea5b
$ docker service ls —network mynet （5）
SERVICE ID　　　NAME　　　　　NETWORK　　CONTAINER
ed190f2cc088　　c1service　　 mynet　　　87c67f4fb376 （6）
21aef543af70　　c2service　　 mynet　　　0ee74a3e3444

（1）启动一个名为c1的容器

（2）在mynet网络内部创建一个名为c1service的未关联的服务名

（3）将容器c1 与服务c1service关联起来

（4）在mynet网络内部创建一个名为c2 的容器以及一个c2service服务名

（5）展示两个容器现在已经将服务绑定到mynet里

（6）如果CONTAINER字段为空，记住要运行“docker service attach c1 c1service.mynet”来附加该服务

上述命令演示了注册服务的两种不同方法，即创建一个容器然后附加服务，以及一步完成创建和附加。

这二者之间存在一个差异。第一个容器将在启动时加入默认网络（通常是 Docker 网桥，不过这可以使用Docker守护进程的参数进行定制），然后添加一个新的网络接口以便可以同时访问mynet。第二个容器将只加入mynet——正常Docker网桥上的任何容器都无法访问它。

下面做一些连接性检查：