netstat是什么　netstat是一个命令，允许用户查看本地网络栈上的相关网络信息。它常用于确定网络套接字的状态。

通常使用net=host标志有几个原因。首先，它可以让外界服务更容易连接到容器。不过这样也会失去为容器创建端口映射的好处。例如，如果有两个容器都监听80端口，使用这种方式的话将无法在同一个宿主机上同时运行它们。其次，使用这个标志时网络性能相比Docker网络会有显著提升。

图12-1展示了Docker中的网络分组（也称数据包）和本地网络中的分组必须经过的层数。尽管本地网络只需通过宿主机的TCP/IP栈到网卡（network interface card，NIC）,但Docker必须额外维护一个虚拟以太网对（也称为veth对，它是对使用以太网电缆的物理连接的虚拟表示），veth对和宿主机网络之间有一个网桥，并且有一个网络地址转换（network address translation，NAT）层。在正常的使用场景里，这样的开销可以导致Docker网络的速度仅有本地宿主机网络的一半。

图12-1　Docker网络与本地网络对比

2．PID

PID命名空间标志与其他命名空间很相似：

imiell@host:/$ docker run ubuntu ps -p 1 （1）　 
　PID TTY　　　　　TIME CMD
　　1 ?　　　　　　00:00:00 ps （2）
imiell@host:/$ docker run —pid=host ubuntu ps -p 1 （3）
　PID TTY　　　　　TIME CMD
　　1　?　　　　　00:00:27 systemd （4）

（1）在容器化环境中运行ps命令，显示只有一个PID为1的进程

（2）运行的ps 命令是该容器中唯一的进程，而且PID为1

（3）运行同样的ps命令但不使用PID命名空间，展示了主机的进程的视图

（4）这次PID为1的进程是systemd命令，它是宿主机的操作系统的启动进程。读者看到的展示可能有所不同，这取决于所使用的发行版

上面的示例演示了在具有宿主机PID视图的容器中，systemd 进程ID为1，而在没有该视图的情况下，能看到的唯一一个进程是ps命令本身。

3．挂载

如果要访问宿主机的设备，可以使用—device标志来使用特定设备，或者使用—volume标志来挂载宿主机的整个文件系统：

docker run -ti —volume /:/host ubuntu /bin/bash

此命令将宿主机的/目录挂载到容器的/host目录。读者可能想知道为什么不能把宿主机的/目录挂载到容器的/目录，原因是这是docker命令明确禁止的行为。

读者可能还想知道是否可以使用这些标志创建一个与宿主机几乎无法区分的容器。这个问题我们将在下一节讨论。

4．类宿主机容器

可以使用这些标志位来创建一个几乎拥有宿主机透明视图的容器：

host:/$ docker run -ti —net=host —pid=host —ipc=host \ （1）　
—volume /:/host \ （2）
busybox chroot /host （3）

（1）使用3个host参数(net,pid,ipc)运行容器

（2）将宿主机的根文件系统挂载到容器的/host目录。Docker不允许将卷挂载到/目录，所以用户必须指定/host子目录卷

（3）启动BusyBox容器。用户只需要chroot命令，而这是一个包含该命令的小镜像。执行chroot可以使被挂载的文件系统就像root一样展现给用户

具有讽刺意味的是，Docker被称为“吃了类固醇的chroot”，而这里我们使用某些特性作为框架，以一种破坏chroot主要设计目标之一（即保护宿主机系统）的方式运行chroot。在这一点上我们尽量不要想得太复杂。

在任何情况下，很难想象有人会在现实世界中使用这个命令（有指导性的）。如果读者想到的话，请联系我们。

也就是说，用户可能更想将它作为一个更有用的命令的基础，像这样：

$ docker run -ti —workdir /host \
　 —volume /:/host:ro ubuntu /bin/bash

—workdir /host将容器启动时的工作目录设置为宿主机的文件系统的根目录，使用—volume参数进行挂载。卷规格说明的:ro部分意思是宿主机文件系统以只读模式挂载。

执行该命令可以给用户一个文件系统的只读视图，从而拥有一个环境安装工具（使用标准的Ubuntu包管理工具）并进行检查。例如，可以使用一个运行了nifty工具的镜像来向宿主机的文件系统报告安全问题，而不用将该工具安装到宿主机上。

不安全！　正如前面的讨论中暗示的那样，带上这些标志的话会引入更多的安全风险。在安全性方面，使用它们应该被视为等同于运行时使用—privileged标志。

在本技巧中，读者学到了该如何绕过容器中Docker的一些抽象。我们将在接下来的技巧里一起看看如何绕过Docker底层磁盘存储的限制。

技巧98　Device Mapper存储驱动和默认的容器大小

Docker附带了一些默认支持的存储驱动（storage driver）。它们在处理层上提供了不同的方法，每种方法都有自己的优点和缺点。可以在https://docs.docker.com/engine/userguide/storagedriver/找到更多相关的Docker文档。

CentOS和Red Hat上默认的存储驱动是devicemapper，Red Hat为其加入了更多的支持，用以替代AUFS（Ubuntu使用的默认存储驱动），因为当时它具备bug更少、使用上更灵活的特点。

Device Mapper术语　Device Mapper是一项Linux技术，它通过提供以某些用户定义的方式将物理设备映射到虚拟设备，从而抽象对物理设备的访问。本技巧中我们谈论的devicemapper指的是在Device Mapper之上构建的Docker存储驱动的名称。

devicemapper驱动的默认行为是分配一个文件，将其视为可读取和写入的“设备”。但是，这个文件有一个固定的最大容量，当它空间不足时不会自动增加。

问题

使用Device Mapper存储驱动时，Docker容器上的可用空间已耗尽。

解决方案

更改Docker容器的最大容量。

讨论

为了说明这个问题，不妨尝试运行下面的Dockerfile：

FROM ubuntu:14.04
RUN truncate —size 11G /root/file

如果没有更改Docker守护程序上关于存储驱动的任何默认配置，应该会看到下面这样的输出：

$ docker build .
Sending build context to Docker daemon 24.58 kB
Sending build context to Docker daemon
Step 0 : FROM ubuntu:14.04
Pulling repository ubuntu
d2a0ecffe6fa: Download complete
83e4dde6b9cf: Download complete
b670fb0c7ecd: Download complete
29460ac93442: Download complete
Status: Downloaded newer image for ubuntu:14.04
 —-> d2a0ecffe6fa
Step 1 : RUN truncate —size 11G /root/file
 —-> Running in 77134fcbd040
INFO[0200] ApplyLayer exit status 1 stdout:　stderr: write /root/file:
no space left on device

这次构建最终会失败，因为尝试创建11 GB文件时失败，并且抛出“no space left”的错误消息。注意，在执行这一命令时，我们的机器上仍然有超过200 GB的磁盘空间，因此该容器并没有达到机器范围的限制。

如何知道是否在使用devicemapper　如果运行docker info，它会在输出中告诉用户使用了哪个存储驱动。如果输出中有devicemapper，那么说明用户正在使用devicemapper，也就是说本技巧可能与用户相关。

默认情况下，devicemapper容器的空间限制为 10 GB。要改变这个设定，需要清理Docker文件夹，重新配置Docker守护进程，然后重新启动。参见附录B了解有关如何在发行版上重新配置Docker守护程序的详细信息。

空间限制已被更改　大约在本书出版时，devicemapper限制已升至100 GB，因此，读者的容器的空间限制可能会比这里提到的要高。

要更改该配置，需要在Docker选项中添加或替换dm.basesize项，使其大于试图创建的11 GB文件：

—storage-opt dm.basesize=20G

一个典型的文件可能如下所示：

DOCKER_OPTIONS=”-s devicemapper —storage-opt dm.basesize=20G”

在重新启动Docker守护进程后，可以重新执行之前运行过的docker build命令：

# ocker build —no-cache -t big .
Sending build context to Docker daemon 24.58 kB
Sending build context to Docker daemon
Step 0 : FROM ubuntu:14.04
 —-> d2a0ecffe6fa
Step 1 : RUN truncate —size 11G /root/file
 —-> Running in f947affe7900
 —-> 39766546a1a5
Removing intermediate container f947affe7900
Successfully built 39766546a1a5

可以看到11 GB的文件被成功创建。

这是devicemapper存储驱动的运行时约束，无论用户是使用Dockerfile构建镜像还是运行容器，都是如此。

12.2　在容器出问题时——调试Docker

在本节中，我们将介绍几个技巧，帮助读者了解和解决在Docker容器中运行的应用程序遇到的一些问题。我们将介绍到在使用宿主机的工具来调试问题时如何“跳入”容器的网络，然后通过直接监控网络接口来了解一个更具有“实践性”的解决方案。

最后，我们将演示Docker抽象是如何被破坏的，从而导致容器在一个宿主机上工作，而在其他宿主机上不工作，以及如何在一个生产系统上对其进行调试。

技巧99　使用nsenter调试容器的网络

在理想世界中，用户可以使用socat（见技巧4）在大使容器（ambassador container）中诊断问题。用户可以启动一个额外的容器，并确保连接转到这个作为代理的新容器。该代理允许诊断和监控连接，然后将其转发到正确的地方。但是，现实世界里，往往不那么方便（或可能）设置这样一个只用于调试的容器。

大使容器模式　见技巧66对大使模式的描述。

读者已经在技巧14中了解了docker exec命令。本技巧讨论nsenter，这个工具和docker exec命令看起来很相似，但允许在容器中使用自己机器上的工具，而不是局限于容器已经安装的东西。

问题

想要调试容器中的网络问题，但使用的工具却不在容器中。

解决方案

使用nsenter来跳到容器的网络，但是工具仍然在宿主机上。

讨论

如果Docker宿主机上还未安装nsenter，可以通过以下命令来安装：

$ docker run -v /usr/local/bin:/target jpetazzo/nsenter

这将在/usr/local/bin中安装nsenter，然后便即刻可以使用。nsenter也可能包含在所使用的系统发行版中（在util-linux包）。

读者可能已经注意到，一般可用的BusyBox镜像默认不附带bash。作为一个初步的演示，我们将展示如何使用宿主机的bash程序进入容器：

$ docker run -ti busybox /bin/bash
FATA[0000] Error response from daemon: Cannot start container
➥ a81e7e6b2c030c29565ef7adb94de20ad516a6697deeeb617604e652e979fda6: 
➥ exec: “/bin/bash”: stat /bin/bash: no such file or directory
$ CID=$(docker run -d busybox sleep 9999) （1）
$ PID=$(docker inspect —format {{.State.Pid}} $CID) （2） 
$ sudo nsenter —target $PID \ （3）
—uts —ipc —net /bin/bash （4）　　　　　　　 
root@781c1fed2b18:~#

（1）启动BusyBox容器并保存容器ID（CID）

（2）检查容器，提取进程ID（PID）（见技巧27）

（3）运行nsenter，指定—target标志位来进入容器。可能无须带上sudo

（4）通过余下的参数指定进入容器时的命名空间（见技巧97，了解更多关于命名空间的知识）。这里的关键点是不使用—mount标志，因为它会使用容器的文件系统，而该文件系统没有安装 bash。指定/bin/bash 作为可执行命令来启动容器

需要指出的是虽然不能直接访问容器的文件系统，但是用户可以使用宿主机拥有的所有工具。

我们之前的某个需求是想有一种办法找出宿主机上哪个veth接口设备对应于哪个容器。例如，有时候我们需要快速将容器从网络上卸载，而不必使用第8章中的任何工具来模拟网络中断。但是，一个没有特权的容器无法关闭网络接口，所以我们需要找出 veth 接口的名称然后在宿主机上完成这项任务：

$ docker run -d —name offlinetest ubuntu:14.04.2 sleep infinity 
fad037a77a2fc337b7b12bc484babb2145774fde7718d1b5b53fb7e9dc0ad7b3
$ docker exec offlinetest ping -q -c1 8.8.8.8 （1）
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
—- 8.8.8.8 ping statistics —-
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.966/2.966/2.966/0.000 ms
$ docker exec offlinetest ifconfig eth0 down （2）
SIOCSIFFLAGS: Operation not permitted
$ PID=$(docker inspect —format {{.State.Pid}} offlinetest)
$ nsenter —target $PID —net ethtool -S eth0 （3）
NIC statistics:
　　 peer_ifindex: 53
$ ip addr | grep ‘^53’ （4）　　　　　　　
53: veth2e7d114: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
➥ master docker0 state UP
$ sudo ifconfig veth2e7d114 down （5）
$ docker exec offlinetest ping -q -c1 8.8.8.8 （6）
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. （7）
—- 8.8.8.8 ping statistics —-
1 packets transmitted, 0 received, 100% packet loss, time 0ms

（1）尝试从新容器内部执行ping命令验证连接成功与否

（2）我们不能关闭容器中的接口。注意，用户的接口可能不是eth0, 所以如果该命令不生效，那么不妨试试通过ifconfig找出主接口的名称

（3）进入该容器的网络空间，使用ethtool命令从宿主机查找对等接口的索引，即虚拟接口的另一端

（4）查找宿主机上的接口列表，从而找出容器的对应veth接口

（5）查找宿主机上的接口列表，从而找出容器的对应veth接口

（6）关闭虚拟接口

（7）从容器内部使用ping命令验证连接是失败的

作为最后一个例子，读者可能想要在容器里使用的程序应该是tcpdump，这是一种在网络接口上记录所有TCP分组的工具。要使用它，需要使用—net命令运行nsenter，这样可以在宿主机上“查看”容器的网络，这样一来便可以使用tcpdump监控分组。

例如，下面代码中的tcpdump命令会将所有分组记录到/tmp/google.tcpdump文件中（我们假设用户仍然在前面启动的nsenter会话中）。然后，我们可以通过访问网页触发一些网络流量：

root@781c1fed2b18:/# tcpdump -XXs 0 -w /tmp/google.tcpdump &
root@781c1fed2b18:/# wget google.com
—2015-08-07 15:12:04— http://google.com/
Resolving google.com (google.com)… 216.58.208.46, 2a00:1450:4009:80d::200e
Connecting to google.com (google.com)|216.58.208.46|:80… connected.
HTTP request sent, awaiting response… 302 Found
Location: http://www.google.co.uk/?gfe_rd=cr&ei=tLzEVcCXN7Lj8wepgarQAQ
➥ [following]
—2015-08-07 15:12:04—
➥ http://www.google.co.uk/?gfe_rd=cr&ei=tLzEVcCXN7Lj8wepgarQAQ
Resolving www.google.co.uk (www.google.co.uk)… 216.58.208.67,
➥ 2a00:1450:4009:80a::2003
Connecting to www.google.co.uk (www.google.co.uk)|216.58.208.67|:80…
➥ connected.
HTTP request sent, awaiting response… 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’
index.html　　　　　　[ <=>　　　　　　　　] 18.28K —.-KB/s in 0.008s
2015-08-07 15:12:05 (2.18 MB/s) - ‘index.html’ saved [18720]
root@781c1fed2b18:# 15:12:04.839152 IP 172.17.0.26.52092 >
➥ google-public-dns-a.google.com.domain: 7950+ A? google.com. (28)
15:12:04.844754 IP 172.17.0.26.52092 >
➥ google-public-dns-a.google.com.domain: 18121+ AAAA? google.com. (28)
15:12:04.860430 IP google-public-dns-a.google.com.domain >
➥ 172.17.0.26.52092: 7950 1/0/0 A 216.58.208.46 (44)
15:12:04.869571 IP google-public-dns-a.google.com.domain >
➥ 172.17.0.26.52092: 18121 1/0/0 AAAA 2a00:1450:4009:80d::200e (56)
15:12:04.870246 IP 172.17.0.26.47834 > lhr08s07-in-f14.1e100.net.http:
➥ Flags [S], seq 2242275586, win 29200, options [mss 1460,sackOK,TS val
➥ 49337583 ecr 0,nop,wscale 7], length 0

“Temporary failure in name resolution”错误　这取决于读者的网络配置，读者可能需要临时修改resolv.conf文件，使DNS查找可以正常工作。如果收到“Temporary failure in name resolution”错误，请尝试将 nameserver 8.8.8.8 这行添加到/etc/resolv.conf文件的顶部。别忘了在完成实验后还原它。

这也展示了Docker另外一个备受瞩目的使用场景——在Docker提供的隔离网络环境中调试网络问题会更加容易。试着记住tcpdump的一些正确的参数，从而妥善地过滤掉一些不相关的分组，这在半夜里维护系统时会是一个容易出错的环节。使用前面的方法，大可忘掉这一点，使用tcpdump捕获容器内的所有内容，而无须在镜像里安装（或不必安装）它。

技巧100　无须重新配置，使用tcpflow进行实时调试

tcpdump是网络诊断的事实标准，如果需要深入调试网络问题，它可能是大多数人首选的工具。

但 tcpdump 通常用于显示分组摘要以及检查分组首部和协议信息——它对于两个程序之间应用层数据流的展示并不是很完善。但是这些信息在调查两个应用程序间的通信问题时可能非常重要。

问题

需要监控容器化应用程序的通信数据。

解决方案

使用tcpflow捕获通过接口的流量。

讨论

tcpflow类似于tcpdump（接受相同的模式匹配表达式），但是它的目的是更好地了解应用程序的数据流。可以通过系统包管理工具安装tcpflow，但是，如果系统包中没有，我们也为此准备了一个可用的Docker镜像，它在功能上与通过包管理工具安装的效果一样：

$ IMG=dockerinpractice/tcpflow
$ docker pull $IMG
$ alias tcpflow=”docker run —rm —net host $IMG”

这里有两种方式通过Docker使用tcpflow，一是将其指向docker0接口，并使用分组过滤表达式只检索想要的分组，或者使用上一个技巧的方法来找到感兴趣的容器的veth接口，并捕获该接口。

表达式过滤更加强大，因为它可以让用户深入了解感兴趣的流量，所以我们将展示一个简单的示例以便读者可以快速上手：

$ docker run -d —name tcpflowtest alpine:3.2 sleep 30d 
fa95f9763ab56e24b3a8f0d9f86204704b770ffb0fd55d4fd37c59dc1601ed11 
$ docker inspect -f ‘{{ .NetworkSettings.IPAddress }}’ tcpflowtest 
172.17.0.1
$ tcpflow -c -J -i docker0 ‘host 172.17.0.1 and port 80’
tcpflow: listening on docker0

在上面的示例中，我们要求tcpflow以彩色的方式打印容器中通过80端口（通常用于HTTP流量）的流入或流出流量。现在，读者可以通过在容器的新终端中访问网页来体验上述命令的效果：

并不是只有这种情况会导致Docker抽象不工作。容器还有可能无法工作在特定的内核上，因为应用程序可能对宿主机上的文件做出一些假设。虽然这种情况发生的概率很小，但是它确实存在，重要的是要警惕这种风险。

1．SELinux

可以让Docker抽象无法工作的一个例子是与SELinux交互的任何东西。如第10章所讨论的，SELinux是在内核中实现的安全层，它游离于正常的用户权限之外。

Docker通过这层来增强容器的安全性，即管理可以在容器里执行什么操作。例如，如果你是容器的root用户，那么你也是宿主机上的root用户。虽然很难，但是一旦容器被攻破，也就同时获得了宿主机的root权限。这并非不可能。之前已经有漏洞被曝光，而且可能还存在一些社区还未发觉的漏洞。SELiux等于提供了另一层保护，即使root用户从容器侵入宿主机，这里对其在宿主机上可以执行的操作也做了一些限制。

到目前为止还算不错，但是对Docker来说，问题在于SELinux是在宿主机上实现的，而不是容器内部。这就意味着在容器里运行的应用程序查询SELinux并发现它是开启的状态时，可能会促使它们对运行的环境做出某些假设。如果不满足这些预期，则会以意想不到的方式失败。

在下面的示例中，我们运行一个安装了Docker的CentOS 7 Vagrant机器，并且在里面安装了一个Ubuntu 12.04容器。如果我们执行一条相当简单的命令来添加一个用户的话，退出码会是12，这代表有错误，并且提示用户没有被成功创建：

[root@centos vagrant]# docker run -ti ubuntu:12.04
Unable to find image ‘ubuntu:12.04’ locally
Pulling repository ubuntu
78cef618c77e: Download complete
b5da78899d3a: Download complete
87183ecb6716: Download complete
82ed8e312318: Download complete
root@afade8b94d32:/# useradd -m -d /home/dockerinpractice dockerinpractice
root@afade8b94d32:/# echo $?
12

同样的命令在ubuntu：14.04容器上却可以正常工作。如果想尝试重现这个结果，需要一台CentOS 7（或类似的）机器。但是出于学习的目的，这对于接下来技巧中使用的任何命令和容器已经足够了。

$?是做什么的　在bash中，$?给出最后一条执行命令的退出码。退出码的含义因命令而异，但通常退出码为0意味着调用成功，非零码指示某种错误或异常条件。

2．调试Linux API调用

我们知道容器之间可能的不同是由于在宿主机上运行的内核API之间存在差异性，strace可以帮助确定调用内核API之间的差异。

什么是strace　strace是一个工具，它允许嗅探一个进程对Linux API所做的调用（也称为系统调用）。这是一个非常有用的调试和教学工具。

首先，需要使用相应的包管理工具在容器上安装strace，然后使用strace命令运行不同的命令。下面是失败的useradd调用的一些输出示例：