一、Docker 数据卷管理
在实际使用过程中，我们需要把容器和数据进行隔离，因为容器在使用过程中可能随时要进行销毁，但是数据要保留下来，所以我们要做数据的持久化。
- 为什么要用数据卷
- docker分层文件系统
- 性能差
- 生命周期与容器相同
- docker数据卷
- mount到主机中，绕开分层文件系统
- 和主机磁盘性能相同，容器删除后依然保留
- 仅限本地磁盘，不能随容器迁移
- docker提供了两种卷：
- bind mount
- docker managed volume
1.1 bind mount
- bind mount
- 是将主机上的目录或文件mount到容器里。
- 使用直观高效，易于理解。
- 使用 -v 选项指定路径，格式 <host path>:<container path>
在做实验之前先把不用的资源删掉：
创建容器并创建文件：
可以看到持久化到本机的目录中了。如果存在则直接挂载，如果不存在则创建。可以看到某些镜像已经写好了将数据存入哪里，那我们在创建容器的时候就必须写这个路径。
如果我们只是想把数据挂接到容器内，而不是要对数据进行增改：
可以看到即可以对一个目录进行设置只读，也可以只对一个文件设置只读。
1.2 docker managed volume
- docker managed volume
- bind mount必须指定host文件系统路径，限制了移植性。
- docker managed volume 不需要指定mount源，docker自动为容器创建数据卷目录。
- 默认创建的数据卷目录都在 /var/lib/docker/volumes 中。
- 如果挂载时指向容器内已有的目录，原有数据会被复制到volume中。
即只有在镜像构建时有VOLUME参数，使用 docker managed volume 创建容器时才会做持久化，不然不会作持久化的。
可以看到registry镜像有VOLUME参数：
可以看到自动为我们作了持久化。可以看到在/var/lib/docker/volumes 下随机创建了目录做持久化：
且此种方式只能支持目录的挂载不能支持文件的挂载。
一般我们先创建一个卷：
在运行容器时，直接写刚刚创建的卷的名称，不需要写绝对路径，如果有的docker引擎会自动识别到：
可以看到已经挂接在指定位置：
如果使用bind mount再挂接会覆盖，但是用docker manger不会。
数据已经挂接过来了。这是容器内nginx发布目录的文件。
用bind mount方式：
即bind mount方式是将宿主机路径目录下的文件覆盖到容器内，是以宿主机路径下文件为准。如果我们考虑容器内路径数据的话，最好用docker管理卷的方式。
1.3 bind mount与docker managed volume对比
- bind mount与docker managed volume对比
- 相同点：两者都是 host 文件系统中的某个路径。
- 不同点：
注：docker管理卷可以用上面说的先创建卷，再进行挂接的方式对目录进行权限控制
二、跨节点存储
需要卷插件作支撑
docker 卷默认使用的是local类型的驱动，只能存在宿主机，跨主机的volume就需要使用第三方的驱动，可以查看以下链接: https://docs.docker.com/engine/extend/legacy_plugins/#volume-plugins
docker官方只提供了卷插件的api，开发者可以根据实际需求定制卷插件驱动。 https://docs.docker.com/engine/extend/plugins_volume/#volume-plugin-protocol
注：官方虽然提供了一些卷插件，但是不够全面，可以根据官方提供的API接口自己开发和docker相集成。
卷插件没有和docker引擎相集成，即它是第三方外部的插件，本身并不属于docker引擎的管理范畴，需要我们手动管理。当docker客户端向docker引擎提交需要挂载卷的请求时，docker引擎会去扫描缺省路径中的卷插件，扫描之后通过卷插件来完成数据的挂接。
- Docker Plugin 是以Web Service的服务运行在每一台Docker Host上的，通过HTTP协议传输RPC风格的JSON数据完成通信。
- Plugin的启动和停止，并不归Docker管理，Docker Daemon依靠在缺省路径下查找Unix Socket文件，自动发现可用的插件。
- 当客户端与Daemon交互，使用插件创建数据卷时，Daemon会在后端找到插件对应的 socket 文件，建立连接并发起相应的API请求，最终结合Daemon自身的处理完成客户端的请求。
convoy卷插件
实验之前先把server1、server2上不用的容器、网络、数据卷全删掉。
- 支持三种运行方式：devicemapper、NFS、EBS。
- 以下实验使用nfs方式。
- 下载软件：https://github.com/rancher/convoy/releases/download/v0.5.0/convoy.tar.gz
- 在所有节点提前挂载NFS存储。
此插件再使用前需要在底层安装NFS文件系统。我们需要在两个节点上需要一个共同的NFS文件系统：
创建nfs文件系统目录：
在server2上不需要启nfs服务，只需要将server1上的/nfsshare 挂接到 server2上的/nfsshare上：
此时两个目录中的文件就同步了：
设置通过卷插件让docker引擎可以调用此文件系统：
解压插件包：
创建docker的缺省路径：
启动并打入后台：
启动后会在这个路径下自动创建 socket 文件：
这个文件就是刚刚我们写到/etc/docker/plugins中的文件的内容：
打入后台的程序就是我们手动启动的，docker引擎不会主动启动这个程序，它只会扫描缺省目录中的内容。
两边主机需要同步，在server2上：
查看现在有什么卷：
使用插件创建卷：
此时再进入/nfsshare 中会发现创建了一个目录，由于nfs同步，在server2中也建立了此文件，且两边都是同步的：
使用docker命令也能看见我们创建的卷：
同样的，我们也能用docker来创建convoy卷：
两种方式创建出来是一样的：
用这种方式就能在两个节点上进行数据同步。我们此时创建容器指定容器内目录挂接到刚刚创建卷上：
在/nfsshare/vol1 中会有容器内nginx的默认发布页：
我们对此默认发布页面进行更改：
此时我们假设这个容器被意外的销毁了（直接删除）：
我们模拟此时该容器被集群迁移到了另外一个节点，我们以相同的命令在server2上创建相同的容器：
可以看到此时用户访问所看到的页面是不变的，因为两个节点间创建容器挂接的卷是相同的，数据是同步的。至此，我们就实现了跨节点的数据持久化（它仍然是基于底层nfs文件系统实现的）。
整套系统的回收删除：
若是删除步骤出了问题，可以将下面这个目录中的数据删掉，再重启docker就没问题了：
