保存和共享镜像

让 Docker 引以为傲的是它能够实现相比于其他虚拟化软件更快的环境迁移和部署，在这件事情上，轻量级的容器和镜像结构的设计无疑发挥了巨大的作用。通过将容器打包成镜像，再利用体积远小于其他虚拟化软件的 Docker 镜像，我们可以更快的将它们复制到其他的机器上。在这一节中，我们就专门来谈谈如何进行这样的迁移。

提交容器更改

之前我们已经介绍过了，Docker 镜像的本质是多个基于 UnionFS 的镜像层依次挂载的结果，而容器的文件系统则是在以只读方式挂载镜像后增加的一个可读可写的沙盒环境。

基于这样的结构，Docker 中为我们提供了将容器中的这个可读可写的沙盒环境持久化为一个镜像层的方法。更浅显的说，就是我们能够很轻松的在 Docker 里将容器内的修改记录下来，保存为一个新的镜像。

将容器修改的内容保存为镜像的命令是 docker commit，由于镜像的结构很像代码仓库里的修改记录，而记录容器修改的过程又像是在提交代码，所以这里我们更形象的称之为提交容器的更改。

$ sudo docker commit webapp
sha256:0bc42f7ff218029c6c4199ab5c75ab83aeaaed3b5c731f715a3e807dda61d19e

Docker 执行将容器内沙盒文件系统记录成镜像层的时候，会先暂停容器的运行，以保证容器内的文件系统处于一个相对稳定的状态，确保数据的一致性。

在使用 docker commit 提交镜像更新后，我们可以得到 Docker 创建的新镜像的 ID，之后我们也能够从本地镜像列表中找到它。

$ sudo docker images
REPOSITORY            TAG                 IMAGE ID            CREATED             SIZE
<none>                <none>              0bc42f7ff218        3 seconds ago       372MB
## ......

像通过 Git 等代码仓库软件提交代码一样，我们还能在提交容器更改的时候给出一个提交信息，方便以后查询。

$ sudo docker commit -m "Configured" webapp

为镜像命名

在上面的例子里，我们发现提交容器更新后产生的镜像并没 REPOSITORY 和 TAG 的内容，也就是说，这个新的镜像还没有名字。

之前我们谈到过，使用没有名字的镜像并不是很好的选择，因为我们无法直观的看到我们正在使用什么。好在 Docker 为我们提供了一个为镜像取名的命令，也就是 docker tag 命令。

$ sudo docker tag 0bc42f7ff218 webapp:1.0

使用 docker tag 能够为未命名的镜像指定镜像名，也能够对已有的镜像创建一个新的命名。

$ sudo docker tag webapp:1.0 webapp:latest

当我们对未命名的镜像进行命名后，Docker 就不会在镜像列表里继续显示这个镜像，取而代之的是我们新的命名。而如果我们对以后镜像使用 docker tag，旧的镜像依然会存在于镜像列表中。

$ sudo docker images
REPOSITORY            TAG                 IMAGE ID            CREATED             SIZE
webapp                1.0                 0bc42f7ff218        29 minutes ago      372MB
webapp                latest              0bc42f7ff218        29 minutes ago      372MB
## ......

由于镜像是对镜像层的引用记录，所以我们对镜像进行命名后，虽然能够在镜像列表里同时看到新老两个镜像，实质是它们其实引用着相同的镜像层，这个我们能够从镜像 ID 中看得出来 ( 因为镜像 ID 就是最上层镜像层的 ID )。正是这个原因，我们虽然创建了新的镜像，但对物理存储的占用空间却不是镜像大小直接翻倍，并且创建也在霎那之间。

除了使用 docker tag 在容器提交为新的镜像后为镜像命名这种方式外，我们还可以直接在 docker commit 命令里指定新的镜像名，这种方式在使用容器提交时会更加方便。

$ sudo docker commit -m "Upgrade" webapp webapp：2.0

镜像的迁移

在我们将更新导出为镜像后，就可以开始迁移镜像的工作了。

由于 Docker 是以集中的方式管理镜像的，所以在迁移之前，我们要先从 Docker 中取出镜像。docker save 命令可以将镜像输出，提供了一种让我们保存镜像到 Docker 外部的方式。

$ sudo docker save webapp:1.0 > webapp-1.0.tar

在默认定义下，docker save 命令会将镜像内容放入输出流中，这就需要我们使用管道进行接收 ( 也就是命令中的 > 符号 )，这属于 Linux 等系统控制台中的用法，这里我们不做详细讲解。

管道这种用法有时候依然不太友好，docker save 命令还为我们提供了 -o 选项，用来指定输出文件，使用这个选项可以让命令更具有统一性。

$ sudo docker save -o ./webapp-1.0.tar webapp:1.0

在镜像导出之后，我们就可以找到已经存储镜像内容的 webapp-1.0.tar 这个文件了。有兴趣的朋友，可以使用解压软件查看其中的内容，你会看到里面其实就是镜像所基于的几个镜像层的记录文件。

导入镜像

我们可以通过很多种方式将导出的镜像文件复制到另一台机器上，在这么操作之后，我们就要将镜像导入到这台新机器中运行的 Docker 中。

导入镜像的方式也很简单，使用与 docker save 相对的 docker load 命令即可。

$ sudo docker load < webapp-1.0.tar

相对的，docker load 命令是从输入流中读取镜像的数据，所以我们这里也要使用管道来传输内容。当然，我们也能够使用 -i 选项指定输入文件。

$ sudo docker load -i webapp-1.0.tar

镜像导入后，我们就可以通过 docker images 看到它了，导入的镜像会延用原有的镜像名称。

批量迁移

通过 docker save 和 docker load 命令我们还能够批量迁移镜像，只要我们在 docker save 中传入多个镜像名作为参数，它就能够将这些镜像都打成一个包，便于我们一次性迁移多个镜像。

$ sudo docker save -o ./images.tar webapp:1.0 nginx:1.12 mysql:5.7

装有多个镜像的包可以直接被 docker load 识别和读取，我们将这个包导入后，所有其中装载的镜像都会被导入到 Docker 之中。

导出和导入容器

也许 Docker 的开发者认为，提交镜像修改，再导出镜像进行迁移的方法还不够效率，所以还为我们提供了一个导出容器的方法。

使用 docker export 命令我们可以直接导出容器，我们可以把它简单的理解为 docker commit 与 docker save 的结合体。

$ sudo docker export -o ./webapp.tar webapp

相对的，使用 docker export 导出的容器包，我们可以使用 docker import 导入。这里需要注意的是，使用 docker import 并非直接将容器导入，而是将容器运行时的内容以镜像的形式导入。所以导入的结果其实是一个镜像，而不是容器。在 docker import 的参数里，我们可以给这个镜像命名。

$ sudo docker import ./webapp.tar webapp:1.0

在开发的过程中，使用 docker save 和 docker load，或者是使用 docker export 和 docker import 都可以达到迁移容器或者镜像的目的。

留言互动

在本节中，我们介绍了关于对 Docker 容器和镜像进行迁移的一些方法。这里给大家留一道思考题：

通过 Docker 进行的集群部署和其他虚拟化形式中的集群部署有怎样的区别，在部署过程中 Docker 又是如何发挥它优势的？

欢迎大家通过留言的方式说出你的看法。我会选出有代表性的优质留言，推荐给大家。

同时，如果你对保存和共享镜像还有疑问，或者有更好的实践角度，可以加入到这本小册的官方微信群中，参与对相关问题的讨论。