（1）运行已发布的ctlc/btsync镜像作为一个守护容器，称为btsync，然后开放必要的端口

（2）获取btsync容器的输出,以便记录键的内容

（3）记下这个键——运行该容器的时候它可能会有所不同

（4）启动一个交互容器，然后挂载上btsync服务器的卷

（5）添加一个文件到/data卷

在次服务器上，开启一个终端并运行这些命令来同步卷：

[host2]$ docker run -d —name btsync-client -p 8888:8888 \
-p 55555:55555 \
ctlc/btsync ALSVEUABQQ5ILRS2OQJKAOKCU5SIIP6A3 （1）
[host2]$ docker run -i -t —volumes-from btsync-client \
ubuntu bash （2）
$ ls /data　　　　　　　　　　　　　　　　　
shared_from_server_one （3）
$ touch /data/shared_from_server_two （4）　　
$ ls /data
shared_from_server_one　shared_from_server_two

（1）启动一个btsync客户端容器作为守护进程，并且传递运行在host1上的守护进程生成的键

（2）启动一个交互容器，通过客户端守护进程挂载卷

（3）在host1上创建的该文件已经被传送到了host2

（4）在host2上创建第二个文件

回到host1上运行的容器，应该能看到该文件正如第一个文件那样在宿主机之间被同步成完全一样的内容：

[host1]$ ls /data
shared_from_server_one　shared_from_server_two

这些文件的同步没有时序保证，因此可能不得不等待数据同步完成，尤其是在文件较大的情况下。

不保证百分百完美　由于数据是在互联网上传输的，而且是由一个没法掌控的协议来处理的，因此如果有任何安全性、扩展性或者性能要求的话，最好不要依靠它。

技巧21　保留容器的bash历史

在一个容器里实验时用户会认识到完成的时候可以擦掉所有痕迹，这是一个很开放的体验。但是这样做也会失去一些便利性。一个我们已经经历过很多次的痛点便是不能再重新调用我们之前在容器里运行的一系列命令。

问题

想要将容器的bash历史与宿主机上的命令历史共享。

解决方案

给docker run命令起一个别名来共享容器与宿主机的bash历史。

讨论

为了理解这个问题，我们打算展示一个简单的场景，在该场景中没有历史记录的话会很不方便。

试想一下用户在Docker容器里正在做一些实验，并且工作内容是一些有趣而又可以重复的事情。这里我们将使用一个简单的echo命令，但是它可能会是一长串复杂拼接的程序，最终生成一个有用的输出：

$ docker run -ti —rm ubuntu /bin/bash
$ echo my amazing command
$ exit

在一段时间后，用户想要重新调用早先运行过的那个难以置信的echo命令。但是，他不能再重新调用它了，而且也失去了在屏幕上可以切换过去的终端会话。出于习惯，他尝试在宿主机上翻看bash历史：

$ history | grep amazing

什么都没返回，因为bash历史被保存在了如今已经删除的容器里，而不是正在使用的宿主机上。为了在宿主机上共享bash历史，可以在运行Docker镜像时挂载一个卷。下面是一个例子：

$ docker run -e HIST_FILE=/root/.bash_history \ (1)
 -v=$HOME/.bash_history:/root/.bash_history \ (2)
 -ti ubuntu /bin/bash

（1）设置bash拾取的环境变量。这可以确保所用的bash历史文件就是挂载的那个文件

（2）将容器里root目录下的bash历史文件映射到宿主机上

分离容器的bash历史文件　用户可能想要将容器的bash历史和宿主机分离开。要达成这一点的话，一个办法便是改变前面-v参数的第一部分的值。

每次都要敲键盘还是挺烦人的，因此为了让它对用户更加友好，可以将这个别名放到~/.bashrc文件里：

$ alias dockbash=’docker run -e HIST_FILE=/root/.bash_history \
 -v=$HOME/.bash_history:/root/.bash_history

这仍然不是很平滑，如果想执行docker run命令，必须得记得敲dockbash。为了追求更完美的体验，可以将这些写到~/.bashrc文件里：

function basher() { （1）
　if [[ $1 = ‘run’ ]] （2）
　then
　　shift （3）
　　/usr/bin/docker run \ （4）　　
　　 -e HIST_FILE=/root/.bash_history \
　　 -v $HOME/.bash_history:/root/.bash_history “$@” （5）
　else
　　/usr/bin/docker “$@” （6）
　fi
}
alias docker=basher （7）

（1）创建一个叫basher的bash函数来处理docker命令

（2）确定basher/ docker的第一个参数是否是’run’。如果是 ……

（3）……删除传入的一系列参数中的一个

（4）运行之前运行的docker run命令，通过指定Docker命令的绝对路径来避免与接下来的docker别名混淆。在实施这一方案前需要先通过运行which docker命令找出宿主机上实际正在运行的Docker的运行时位置

（5）在run的后面传入实际参数给Docker运行时

（6）以完整原始传入的参数来运行docker命令

（7）给在命令行上调用的docker命令起一个别名映射到创建的basher函数。这可以确保调用docker的操作在bash从path里找到docker二进制之前被捕获

如今在下一次打开bash shell，运行任何docker run命令时，在该容器内运行的命令都将会被添加到宿主机的bash历史。一定要确保Docker的路径是正确的。例如，它的路径可能是/bin/docker。

别忘了注销宿主机的 bash 会话　为了让历史文件得到更新，将需要注销宿主机上的原始bash会话。这得归咎于bash的微妙机制以及它更新保存在内存里的bash历史的方式。如有疑问，不妨先退出所有已知的bash会话，然后再启动一个新的以尽量确保bash历史是最新的。

技巧22　数据容器

如果在一台宿主机上大量用到卷，容器启动的管理可能会变得很麻烦。用户可能也希望用Docke专门管理数据，而不是通过宿主机进行访问。更干净地管理这些东西的一种办法便是使用纯数据容器（data-only container）的设计模式。

问题

想要在容器里使用一个外部卷，但是只想让Docker访问这些文件。

解决方案

启动一个数据容器，然后在运行其他容器时使用—volumes-from标志。

讨论

图4-3展示了数据容器模式的结构，并且解读了它的工作原理。要注意的关键一点是，在第二台宿主机里，容器并不需要知道数据位于磁盘的哪个位置，它们只要了解数据容器的名字，一切便准备就绪。这样做可以使容器的操作更加具有可移植性。

与直接映射宿主机目录的方式相比，这种方法的另一个好处是这些文件的访问是由Docker管理的，这也就意味着不太可能出现非Docker进程影响其内容的情况。

纯数据容器不一定需要运行　一个常常让人困惑的问题便是纯数据容器是否需要运行。不需要！它只需要存在，在宿主机上运行过并且没有被删除。

让我们通过一个简单的例子直观地展示一下该如何使用这一技巧。首先，运行一个数据容器：

$ docker run -v /shared-data —name dc busybox \
　touch /shared-data/somefile

-v参数并没有将卷映射到一个宿主机目录，因此它将会在这个容器的管辖范围内创建一个目录。这个目录通过touch填充了一个文件，然后容器立刻退出了——一个数据容器被使用的时候并不需要处于运行状态。我们使用了一个小而实用的busybox镜像来减少我们的数据容器所需的额外成本。

图4-3　数据容器模式

然后便可以运行其他容器来访问刚创建的文件了：

docker run -t -i —volumes-from dc busybox /bin/sh
/ # ls /shared-data
somefile

—volumes-from标志允许通过挂载它们到当前容器的形式来引用数据容器里的文件——只需要给传入卷定义的ID即可。busybox镜像里没有bash，因此必须启动一个简化版shell来确认dc容器里的/shared-data目录对用户而言是的确可用的。

用户可以启动任意数量的容器，都从指定的数据容器的卷里读和写。

卷会持久化！　需要明白的重要一点是，使用这种模式会造成大量的磁盘消耗，这可能会导致调试变得相当困难。由于Docker在纯数据容器里管理卷，而且不会在最后一个引用它的容器已经退出的前提下删除该卷，因此，任何在该卷上的数据均会被保留下来。这是为了防止意外的数据丢失。有关这方面该如何管理的建议，见技巧35。

使用这种模式的话就无须使用卷——读者可能会发现这个方案比直接挂载一个宿主机目录执行起来要更困难些。但是，如果想要将管理数据的职责完全委派给Docker进行单点管理而不受其他宿主机进程干扰的话，那么数据容器会满足这一需求。

文件路径之争　如果应用程序是从多个容器写日志到同一数据容器的话，很重要的一点便是得确保每个容器日志文件写入的是一个唯一的文件路径。如果无法确保这一点，不同的容器便有可能覆盖或者截断该文件，从而造成数据的丢失，或者可能写入的数据是交错混杂的，这就很难解析文件中的内容。类似地，如果对数据容器调用—volumes-from，就是允许该容器潜在地覆盖自己的目录，因此也要小心这里的命名冲突。

技巧23　使用SSHFS挂载远程卷

前面我们讨论了该怎样挂载本地文件，但是很快又出现如何挂载远程文件系统的问题。例如，用户可能会打算在一台远程服务器上共享一个引用的数据库，然后将它当成是本地文件系统来使用。

虽然从理论上来说可以在宿主机系统及服务器上配置NFS，然后通过挂载该目录来访问远程的文件系统，但是对于大多数用户而言这里有一种更为快捷和简单的方式，无须在服务器上做任何配置（只要有SSH访问权限）。

需要root权限　用户需要有root权限才能使用这一技巧，而且需要安装FUSE（Linux的用户空间级的文件系统内核模块）。可以通过在一个终端里运行ls /dev/fuse查看文件是否存在来确认当前系统是否支持。

问题

想要挂载一个远程文件系统而无须任何服务器端的配置。

解决方案

使用SSHFS来挂载远程文件系统。

讨论

本技巧使用FUSE内核模块通过SSH提供一个标准的文件系统接口，后台的所有通信都是通过SSH完成的。SSHFS后台还提供了各种功能（如预读取远程文件），从而使用户产生一种文件就在本地的错觉。结果便是用户一旦登录到远程服务器，就可以看到上面的文件，就像这些文件在本地一样。图4-4帮助诠释了这一点。

图4-4　通过SSHFS挂载一个远程文件系统

变更不会持久化到容器　虽然这一技巧没有用到Docker卷功能，并且这些文件在文件系统上也是可见的，但是这一技巧并不会提供任何容器级别的持久化。任何变更都将只作用到远程服务器的文件系统。

用户可以从运行如下命令开始，命令内容可以根据环境做相应调整。

第一步便是在宿主机上启动一个容器并附加—privileged：

$ docker run -t -i —privileged debian /bin/bash

然后在它启动了之后，在容器里运行apt-get update && apt-get install sshfs来安装SSHFS。

在SSHFS安装成功后，按照如下步骤登录到远程宿主机：

$ LOCALPATH=/path/to/local/directory （1）
$ mkdir $LOCALPATH （2）
$ sshfs user@host:/path/to/remote/directory $LOCALPATH （3）

（1）选择一个远程位置对应的挂载目录

（2）创建本地挂载目录

（3）将这里的对应值替换成远程宿主机用户名，远程宿主机的地址以及远程路径

现在就可以在刚刚创建的那个文件夹里看到远程服务器对应路径下的内容了。

通过nonempty选项挂载已经存在内容的目录　挂载到一个新创建的目录是最简单的，但是如果使用-o nonempty选项的话也可以挂载一个已经存在一些文件的目录。可以查阅SSHFS帮助手册来了解更多细节。

要干净地卸载这些文件的话，可以按照如下方式使用fusermount，根据需要将其替换成对应的路径：

fusermount -u /path/to/local/directory

这是一种很不错的方法，以最小的成本在容器（和标准的Linux机器）里完成远程挂载。

技巧24　通过NFS共享数据

在一个大型企业里，它很有可能有一些已经在使用的NFS共享目录——NFS是一种经过验证的方案，用于从一个中央位置提取文件。对Docker而言，能够访问这些共享文件是一件非常重要的事情。

Docker并没有原生支持NFS，并且在每个容器上安装一个NFS客户端来挂载远程文件夹也不见得是一个最佳实践。相反，推荐的方案是设置一个容器充当从NFS到一个更为Docker友好的概念——卷的中转站。

问题

想要通过NFS无缝访问远程文件系统。

解决方案

使用一个基础设施数据容器来中转访问。

讨论

这一技巧是在技巧22的基础上构建的。图4-5从概念层面展示了其理念。

图4-5　一个用作NFS访问中转的基础设施容器

NFS服务器将一个内部目录公开为/export文件夹，它会被绑定挂载到NFS服务器宿主机上。Docker宿主机随后会使用NFS协议将该文件夹挂载到它的/mnt文件夹，然后再创建一个所谓的基础设施容器来绑定挂载的文件夹。

乍看上去这样做好像有一点儿过度设计，但是这样做的好处是，对Docker容器而言它提供了一个中间层：它们需要做的就是从一个预先约定好的基础设施容器挂载卷，然后由基础设施容器来处理内部设备的管道、可用性、网络等。

如何深入了解NFS超出了本书的讨论范畴。在这一技巧中，我们将通过一系列步骤在单台宿主机上配置这样的一个共享，NFS服务器的组件作为Docker容器运行在同一台宿主机上。该项实验已经在Ubuntu 14.04上测试通过。

假设用户想要共享宿主机上的/opt/test/db文件夹的内容，它里面有一个mybigdb.db的文件。

以root身份安装一个NFS服务器，然后创建一个开放权限的export目录：

# apt-get install nfs-kernel-server
# mkdir /export
# chmod 777 /export

绑定挂载该db目录到export目录：

# mount —bind /opt/test/db /export

现在应该可以在/export里看到/opt/test/db目录下的内容了。

持久化该绑定挂载　如果想要在下次重启的时候持久化这一操作，需要将opt/test/db/export none bind 0 0这一行加到/etc/fstab文件中。

现在添加这一行内容到/etc/exports文件中：

/export　　　　127.0.0.1(ro,fsid=0,insecure,no_subtree_check,async)

针对这个概念性验证示例，我们在127.0.0.1上做了本地挂载，这可能和目标有点儿差距。在一个真实场景里，用户可能会把这个锁定到一类 IP 地址，如192.168.1.0/24。不要将127.0.0.1替换为*从而对全世界开放，这是在玩儿火！

为了安全起见，我们这里做了只读（ro）挂载，但是用户可以通过将ro替换成rw做可读写挂载。别忘了如果要这么做的话，需要在async标志后面加上一个no_root_squash标志，但是在实施之前请先考虑一下安全性。

将NFS上共享的目录挂载到/mnt文件夹下，导出之前在/etc/exports里指定的文件系统，然后重启NFS服务以生效：

# mount -t nfs 127.0.0.1:/export /mnt
# exportfs -a
# service nfs-kernel-server restart

现在准备好运行基础设施容器：

# docker run -ti —name nfs_client —privileged -v /mnt:/mnt 
➥ busybox /bin/true

而现在可以运行容器——不需要权限也无须拥有底层实现的知识就可以访问目录：

# docker run -ti —volumes-from nfs_client debian /bin/bash
root@079d70f79d84:/# ls /mnt
myb
root@079d70f79d84:/# cd /mnt
root@079d70f79d84:/mnt# touch asd
touch: cannot touch `asd’: Read-only file system

采用一个命名规范以提高运维效率　如果需要管理大量的这种容器，可以通过设定一个命名规范，例如，针对一个暴露了/opt/database/livepath的容器起名为—name nfs_client_opt_database_live来简化管理。

这种挂载一个中央授权访问的共享资源供其他人在多个容器中使用的模式真的很强大，它可以使开发工作流变得更加简单。

安全性是无可替代的　请记住这一技巧只提供隐晦的（近乎没有）安全性保证。正如最后看到的那样，任何人只要能够运行Docker便拥有宿主机上的root权限。

技巧25　开发工具容器

作为一名工程师，如果发现自己常常苦恼的问题是，在其他机器上没有自己雪花般美丽独特的个人开发环境里的程序或配置，那么这一技巧也许正好适用。类似地，如果想和其他人分享自己精心定制的开发环境，Docker可以让这件事情变得更简单。

问题

想在其他人的机器上访问自己定制的开发环境。

解决方案

用自己的配置创建一个容器，然后把它放到注册中心上。

讨论

作为演示，这里将使用一个我们的开发工具镜像。读者可以通过运行docker pull dockerinpractice/docker-dev-tools-image来下载它。如果想查看Dockerfile，仓库地址是https://github.com/docker-in-practice/docker-dev-tools-image。

运行该容器非常简单——直接执行docker run -t -i dockerinpractice/docker-dev-tools-image就能给用户一个开发环境的shell。这里读者可以使用我们默认的配置，也可以就配置方面给我们一些建议。

本技巧和其他技巧配合起来更能体现其威力。这里读者可以看到一个开发工具容器，用来在宿主机网络和IPC栈上展示一个用户图形界面（GUI），然后挂载宿主机上的代码：

docker run -t -i \
-v /var/run/docker.sock:/var/run/docker.sock \ （1）
-v /tmp/.X11-unix:/tmp/.X11-unix \ （2）　　　　　　　
-e DISPLAY=$DISPLAY \ （3） 
—net=host —ipc=host \ （4）　　
-v /opt/workspace:/home/dockerinpractice \ （5）
dockerinpractice/docker-dev-tools-image

（1）挂载Docker套接字以访问宿主机上的Docker守护进程

（2）挂载X服务器Unix域套接字可以启动一个基于用户图形界面的应用（见技巧26）

（3）设置构建容器时的环境变量以使用宿主机的显示器

（4）这些参数绕过容器的网桥并且通过这些参数可以访问宿主机上的进程间通信文件（见技巧97）

（5）挂载工作区到该容器的home目录

上述命令提供了一个环境，它能够访问宿主机的下列资源：

• 网络；
• Docker守护进程（运行普通Docker命令，就像在宿主机上一样）；
• 进程间通信（IPC）文件；
• 如果需要的话，用X服务器启动基于用户图形界面的应用。

宿主机安全性　挂载宿主机目录时，小心不要挂载任何重要的目录，因为可能会破坏文件。通常需要避免挂载宿主机上root用户的任何目录。

4.2　运行容器

虽然本书的大部分内容都是关于正在运行的容器的，但是也有一些与在宿主机上运行容器相关的实战技巧不容易被注意到。我们将看看如何让GUI应用程序工作，包括顺畅地退出一个启动的容器而不是杀掉它，检查容器的状态和源镜像，以及关闭这些容器。

技巧26　在Docker里运行GUI

在技巧14中，我们已经看到一个在容器里由VNC服务器提供的GUI。这是一种在Docker容器中查看应用程序的方法，它是内置的，只需要一个VNC客户端便可以使用。

幸好有更轻量、集成度更高的方法在桌面上运行GUI，不过这需要做更多的设置。它会在宿主机上挂载一个目录以管理和X服务器的通信，以便容器可以访问到它。

问题

想要在一个容器里运行GUI，就像是正常的桌面应用一样。

解决方案

使用自己的用户凭证和程序创建镜像，然后将用户的X服务器绑定挂载到它上面。

讨论

图4-6展示了最终设置的工作原理。

容器会通过挂载宿主机的/tmp/.X11目录链接到宿主机，而这正是容器可以在宿主机的桌面上完成操作的原因所在。

首先在一个觉得合适的地方创建一个新目录，然后通过id命令确定用户ID和组ID，如代码清单4-1所示。

图4-6　和宿主机的X服务器通信

代码清单4-1　设置目录然后找出具体的用户信息

$ mkdir dockergui
$ cd dockergui
$ id （1）
uid=1000(dockerinpractice) \ （2）
gid=1000(dockerinpractice) \ （3）
groups=1000(dockerinpractice),10(wheel),989(vboxusers),990(docker)

（1）收集Dockerfile所需的用户信息

（2）记住用户ID（uid）。在这个例子里，它是1000

（3）记住组ID（gid）。在这个例子里，它是1000

现在创建一个叫Dockerfile的文件，如下所示：

FROM ubuntu:14.04
RUN apt-get update
RUN apt-get install -y firefox （1）
RUN groupadd -g GID USERNAME （2）
RUN useradd -d /home/USERNAME -s /bin/bash \
-m USERNAME -u UID -g GID （3）　　　　　　　　 
USER USERNAME （4）
ENV HOME /home/USERNAME （5）
CMD /usr/bin/firefox （6）

（1）安装Firefox作为GUI应用。用户可以把这个换成任何想要安装的应用

（2）把宿主机上的组添加到镜像里，把GID替换为组ID，把USERNAME替换为用户名

（3）把用户账号加到镜像里，把USERNAME替换为用户名，把UID替换为用户ID，把GID替换为组ID

（4）镜像应当以刚创建的用户身份运行。把USERNAME替换为用户名

（5）正确地设置HOME变量。把USERNAME替换为用户名

（6）默认在启动时运行Firefox

现在就可以基于该Dockerfile来构建镜像，然后把结果标记为“gui”了，如代码清单4-2所示。

代码清单4-2　构建gui镜像

$ docker build -t gui .

以代码清单4-3所示的方式运行它。

代码清单4-3　运行gui镜像

docker run -v /tmp/.X11-unix:/tmp/.X11-unix \ （1）
-e DISPLAY=$DISPLAY gui （2）
-h $HOSTNAME -v $HOME/.Xauthority:/home/$USER/.Xauthority （3）

（1）绑定挂载X服务器目录到容器……

（2）……在容器里将DISPLAY变量设置成宿主机上的相同值，这样程序便能知道与哪个X服务器通信……

（3）……并为容器提供合适的授权凭证

会看到弹出一个Firefox窗口！

可以使用这一技巧来避免桌面工作与开发工作混在一起。以Firefox为例，出于测试目的，开发人员可能想要看到应用程序在没有Web缓存、书签或者搜索历史的情况下的行为，并且这种查看可以重复。如果在尝试启动镜像和运行Firefox的时候出现无法打开显示器这样的出错信息的话，不妨查看技巧58以获取关于使容器启动的图形应用在宿主机上得以展示的更多方法。

技巧27　检查容器

虽然Docker命令提供了查看镜像和容器信息的能力，有时候用户也许也想了解这些Docker对象的内部元数据的更多信息。

问题

想要找出一个容器的IP地址。

解决方案

使用docker inspect查询和过滤容器的元数据。

讨论

docker inspect命令提供了一个以JSON格式查看Docker容器内部元数据的能力。该命令会产生大量的输出，因此在代码清单4-4中仅列出了一个镜像元数据的简明摘要。

代码清单4-4　检查镜像的原始输出

$ docker inspect ubuntu | head
[{
　　“Architecture”: “amd64”,
　　“Author”: “”,
　　“Comment”: “”,
　　“Config”: {
　　　　“AttachStderr”: false,
　　　　“AttachStdin”: false,
　　　　“AttachStdout”: false,
　　　　“Cmd”: [
　　　　　　“/bin/bash”
$

用户可以通过名字或ID来查看镜像和容器，不过它们的元数据会不太一样。例如，一个容器会有像“State”之类的运行时字段，但镜像是没有的（镜像是没有状态的）。

在这个例子里，用户想要在宿主机上找出一个容器的IP地址。为了做到这一点，可以使用docker inspect命令并附带format标志（如代码清单4-5所示）。

代码清单4-5　确定一个容器的IP地址

docker inspect \ （1）
—format ‘{{.NetworkSettings.IPAddress}}’ \ （2）
0808ef13d450 （3）

（1）使用docker inspect命令

（2）附加format标志。该标志会使用Go模板（不属于本书的内容范畴）来格式化输出。这里，会从inspect输出中的NetworkSettings字段里提取出IPAddress

（3）想要查看的DockerID

本技巧对自动化来说非常有用，因为这个接口比其他Docker命令可能会更稳定些。代码清单4-6给出的命令列出了所有正在运行的容器的IP地址，然后对它们执行ping命令。

代码清单4-6　拿到正在运行中的容器的IP然后逐个ping

$ docker ps -q | \ （1）
xargs docker inspect —format=’{{.NetworkSettings.IPAddress}}’ | \ （2）
xargs -l1 ping -c1 （3）
PING 172.17.0.5 (172.17.0.5) 56(84) bytes of data.
64 bytes from 172.17.0.5: icmp_seq=1 ttl=64 time=0.095 ms
—- 172.17.0.5 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

（1）拿到所有正在运行中的容器的ID

（2）针对所有容器ID执行inspect命令以获取它们的IP地址

（3）逐个取出IP地址，然后依次运行ping

注意，因为ping只接受单个IP地址，所以必须给xargs传入一个额外的参数，告诉它针对每个单独的行执行该命令。

设置一个正在运行的容器来测试　如果没有正在运行的容器的话，运行下面这条命令来获取一个：docker run -d ubuntu sleep 1000。

技巧28　干净地杀掉容器

如果容器终止时的状态对用户而言很重要，用户可能会想要了解docker kill和docker stop之间的区别。这一差异在需要应用程序正常关闭以保存数据时显得尤为重要。

问题

想要干净地终止一个容器。

解决方案

使用docker stop而不是docker kill。

讨论

要理解的关键点在于docker kill的行为和标准的kill命令行程序并不相同。

除非另有说明，kill程序的默认工作方式是向指定的进程发送TERM信号（即信号值为15）。这个信号表示程序应该终止，但是不要强迫程序终止。当这个信号被处理时，大多数程序将执行某种清理工作，但是该程序也可以执行其他操作，包括忽略该信号。

相反，KILL信号（即信号值为9）会强迫指定的程序终止。

令人困惑的是，docker kill对正在运行的进程使用的是KILL信号，这使得该进程没办法处理终止过程。这就意味着一些诸如包含运行进程ID之类的文件可能会残留在文件系统中。根据应用程序管理状态的能力，如果再次启动容器，这可能会也可能不会造成问题。

更令人不解的是，docker stop命令则像kill命令那样工作，发送的是一个TERM信号（见表4-1）。

表4-1　停止和杀死容器

总而言之，如果想使用kill就不要使用docker kill，而且最好养成使用docker stop的习惯。

技巧29　使用Docker Machine来置备Docker宿主机

在本机上安装Docker可能不是一件太困难的事情——有一个脚本可以很方便地用来做这件事，或者也就是几条命令添加几个适当的源到包管理器的事情。但是，当试图在其他宿主机上管理Docker安装时会很乏味。

问题

想要在与自己机器独立的Docker宿主机上启动容器。

解决方案

使用Docker Machine。

讨论

如果需要在多个外部宿主机上运行Docker容器，这一技巧就有用武之地了。需要它可能有下面几个原因：

• 通过在自己物理机里置备一台虚拟机来测试Docker容器之间的网络；
• 借助VPS供应商到一台更强力的机器上置备容器；
• 冒着损毁宿主机的风险去进行一些疯狂实验；
• 保留运行在多个云厂商的选择权。

无论什么原因，Docker Machine也许就是答案。它也是更复杂的编排工具（如Docker Swarm）的门户。

1．Docker Machine是什么

Docker Machine主要是一个便利程序。它将大量配置外部宿主机的繁琐的指令包装起来，变成一些易于上手的命令。如果对Vagrant很熟悉，这有着类似的体验：通过一个一致的接口使置备和管理其他机器环境变得更简单。如果把注意力放回到第2章里的架构概览图，查看该图的方式之一便是把它想象成一个客户端，它可以方便地管理不同的Docker守护进程（见图4-7）。

图4-7里列出的Docker宿主机提供商并不全，而且这个清单可能还会不断增长。在编写本书的时候有下列驱动可用，它允许使用给定的宿主机供应商来置备：

• Amazon Web Services（AWS）；
• Digital Ocean；
• Google Compute Engine；　
• IBM Softlayer；
• Microsoft Azure；　
• Microsoft Hyper-V；
• OpenStack；　
• Rackspace；
• Oracle VirtualBox；
• VMware Fusion；
• VMware vCloud Air；
• VMware vSphere。

图4-7　Docker Machine作为外部宿主机的一个客户端

根据驱动提供的功能，置备机器时必须指定的参数也会有很大的不同。与OpenStack的17个参数相比，用户的机器置备一台Oracle Virtualbox虚拟机在创建时只有3个可用的参数。

2．Docker Machine不是什么

需要指出的是，Docker Machine 不是一种 Docker 的集群解决方案。其他工具（像Docker Swarm）填补了这块功能，我们将在后面探讨这些。

3．安装

安装程序是一个简单的二进制文件。针对不同架构的下载链接和安装指令可以在https://github.com/docker/machine/releases找到。

迁移二进制文件？　用户可能想要把二进制文件放置到一个标准的位置，如/usr/bin，然后在继续之前先确保它被重命名或者符号链接到了docker-machine，因为下载的文件可能会有一个更长的带有运行架构的后缀名。

4．使用Docker Machine

为了演示Docker Machine的用法，可以从创建一个上面正常运行着Docker守护进程的虚拟机开始。

假定选用 VirtualBox 虚拟机管理器　为了让它能够正常运行，用户需要安装Oracle公司的VirtualBox。在大多数包管理器里均可以找到它。

$ docker-machine create —driver virtualbox host1 （1）
INFO[0000] Creating CA: /home/imiell/.docker/machine/certs/ca.pem 
INFO[0000] Creating client certificate: /home/imiell/.docker/machine/certs/ 
➥ cert.pem
INFO[0002] Downloading boot2docker.iso to /home/imiell/.docker/machine/cache/　
➥ boot2docker.iso…
INFO[0011] Creating VirtualBox VM…
INFO[0023] Starting VirtualBox VM…
INFO[0025] Waiting for VM to start…
INFO[0043] “host1” has been created and is now the active machine.（2）
INFO[0043] To point your Docker client at it, run this in your shell:
➥ $(docker-machine env host1)　 （3）

（1）使用docker-machine的create子命令来创建一个新的宿主机，然后通过—driver参数来指定它的类型。该宿主机已经被命名为host1

（2）现在机器已经创建好了

（3）运行这个命令来设置DOCKER_HOST环境变量，这将会设置Docker命令执行时所在的默认宿主机

Vagrant 用户在这里应该会有种找到家的感觉。通过执行上述命令，现在已经创建了一台机器，并且可以在上面管理Docker。如果按照输出里给出的指令操作，可以直接使用SSH连接到新的虚拟机：