作者：匿蟒
原文：https://note.qidong.name/2018...

曾经部署的容器化服务，也不是不须要保护的。而且，因为生产环境往往有这样那样的严格要求，往往须要些非常规操作。Image（镜像）、Container（容器）和Volume（数据卷）的迁徙，就是一类有用的非常规操作。

以下镜像，均以最简略的Alpine为例。

Image

镜像的迁徙，实用于离线环境。

个别离线环境，都会自建Docker Registry。无论官网的，还是最近风行的Harbor，都是不错的抉择。然而，这个世界上就是有些环境，或者说一些环境在某些期间，没有外网，也没有外部的Registry。这个时候要部署Docker的服务，怎么办？

只能通过镜像的迁徙。实际上，Harbor的offline installer，就是采纳这种模式。

Save

# use stdoutdocker save alpine > /tmp/alpine.tar# or write to a file directlydocker save alpine -o /tmp/alpine.tar

举荐应用-o的模式，因为利用stdout的做法尽管直观，但在某些场景下有效，比方利用ssh近程执行命令。

Load

# use stdoutdocker load < /tmp/wekan.tar# or read from a file directlydocker load -i /tmp/wekan.tar

Container

容器的迁徙，实用于曾经上线，且状态简单、从零开始启动不能失常工作的服务。容器迁徙的包，蕴含了镜像。

Export

先筹备一个正在运行的服务，并且弄脏环境。

$ docker run --rm -d --name test alpine tail -f /dev/null9232f0c1dafe0f29918f281ca37bb41914677e818cb6f252abf3dab3be04fbb2$ docker exec test touch proof$ docker exec test ls -hl proof-rw-r--r-- 1 root root 0 Nov 20 14:33 proof#执行导出操作：docker export test -o test.tar

Import

首先，敞开方才运行的服务。

$ docker kill testtest#执行导入操作：$ docker import test.tar test-imgsha256:e03727eeba7e16dd3acfcc7536f1244762508f9b6b9856e49cc837c1b7ffa444

要留神的是，import后失去的是一个镜像，相当于是执行了docker commit后的内容。当然，docker commit不是一个举荐的操作，所以容器的导入、导出，就显得不是那么的悦目。

最初，查看之前创立的文件。

$ docker run --rm -d --name test test-img tail -f /dev/nullee29cb63bb2d3ed8ac890789ba80c4fe4078b9d5343a8952b6217d64b4dcbe23$ docker exec test ls -hl proof-rw-r--r-- 1 root root 0 Nov 20 14:33 proof

能够看到，后面创立的文件是存在的，并且工夫戳完全一致。

Volume

数据卷的迁徙，比拟麻烦。Docker并未提供官网的简略计划。

当然，间接用root用户拜访文件系统的Docker数据，比方默认的/var/lib/docker/volumes/下的文件夹，间接进行打包操作，也不是不行。但这毫无疑问是最蹩脚的计划。

目前参考《Use volumes | Docker Documentation》，找到的最佳计划是，用另一个容器，把数据卷内容打包，并且通过挂载的模式传递到宿主机。

Backup

首先，筹备一个Volume。

$ docker run --rm -d --name test -v test-vol:/data test-img tail -f /dev/nullf4ff81f4c31025ff476fbebc2c779a915b43ba5940b5bcc42e3ef9b1379eaeab$ docker exec test touch /data/proof$ docker exec test ls -hl proof-rw-r--r-- 1 root root 0 Nov 20 14:40 proof

执行备份操作：

$ docker run --rm -v test-vol:/volume -v $PWD:/backup alpine tar cvf /backup/backup.tar volumevolume/volume/proof

间接在已运行容器中打包，而后通过docker cp复制进去，也是一个计划。但这会对正在运行的容器有影响，不倡议在真正重要的容器中应用。

这里利用了一个Alpine镜像来执行操作。实际上，任何一个自带tar的镜像都是能够的。

Restore

首先，清理方才的容器和数据卷。

$ docker kill testtest$ docker volume rm test-voltest-vol

执行还原操作：

docker run --rm -v test-vol:/volume -v $PWD:/backup alpine tar xf /backup/backup.tar

最初，查看还原后的后果。

$ docker run --rm -v test-vol:/data alpine ls -ahl /datatotal 8drwxr-xr-x 2 root root 4.0K Nov 20 14:48 .drwxr-xr-x 1 root root 4.0K Nov 20 14:50 ..-rw-r--r-- 1 root root 0 Nov 20 14:40 proof

论断

以上三招六式，其实都不是惯例伎俩。

Image的传递，更应该依赖于外部Docker Registry而非tar。（当然，也有例外，比方集群部署大镜像的P2P计划，兴许能够借鉴这个伎俩。）

Container的状态，应该是可弃的。一个运行了很长时间的Container，应该是能够restart、甚至kill后再从新run也不影响既有性能的。任何有依赖的状态，都应该思考长久化、网络化，而不能单纯地保留在本地文件系统中。

Volume的手动迁徙，确实能够采纳上述形式。然而，Volume须要手动迁徙、备份吗？这须要业余而欠缺的插件来实现。

如有谬误之处，敬请斧正，也欢送点赞、转发反对，更多干货文章请关注民工哥微信公众号，咱们一起成长。