运维实操——docker容器（六）数据卷

1、Docker数据卷管理

docker分层文件系统的性能差，生命周期与容器相同，容器一旦删除，数据就没了。如果采用数据卷，mount到主机中，绕开分层文件系统，这样数据和主机磁盘性能相同，容器删除后依然保留数据，但是也有缺点，仅限本地磁盘，不能随容器迁移。
docker提供了两种数据卷：bind mount和managed volume。下图是对比

（1）bind mount

bind mount是将主机上的目录或文件挂载到容器里，使用直观高效，易于理解。
实验需要准备两台虚拟机，server1（172.25.11.1）和server2（172.25.11.2），已经装过docker
首先需要停掉docker-compose，净化环境。

使用nginx镜像后台运行一个容器，名字叫demo，-v参数指定路径，表示/data挂载到/usr/share/nginx/html

给data写入index.html文件，curl测试，显示了index.html文件的内容，说明读取的是挂载的/data的数据，并注意bind mount的方式是直接覆盖原来的/usr/share/nginx/html的内容。删除demo

进入demo，再次追加一个内容，curl测试出现了，说明bind mount 默认权限是读写rw

也可以设定只读，交互式进入容器，可以看到导入数据时被拒绝了。

（2）managed volume

bind mount必须指定host文件系统路径，限制了移植性，docker managed volume 不需要指定mount源，docker自动为容器创建数据卷目录。默认创建的数据卷目录都在 /var/lib/docker/volumes 中，如果挂载时指向容器内已有的目录，原有数据会被复制到volume中。
虽然可以不指定mount源，但是会生成一大串字符串，不利于记忆，所以先创建一个卷webdata，使用nginx镜像后台运行一个容器，名字叫demo，-v参数指定路径，表示 /var/lib/docker/volumes/webdata挂载到/usr/share/nginx/html

可以去 /var/lib/docker/volumes目录下查看，确实有webdata

不指定mount源时，也没问题，会产生很长的字符串子目录，可以看到这种挂载方式不是简单的覆盖，而是把原来的文件复制到现在的子目录里。

2、卷插件简介

docker官方只提供了卷插件的api，开发者可以根据实际需求定制卷插件驱动。Docker Plugin 是以Web Service的服务运行在每一台Docker Host上的，通过HTTP协议传输RPC风格的JSON数据完成通信。Plugin的启动和停止，并不归Docker管理，Docker Daemon依靠在缺省路径下查找Unix Socket文件，自动发现可用的插件。当客户端与Daemon交互，使用插件创建数据卷时，Daemon会在后端找到插件对应的 socket 文件，建立连接并发起相应的API请求，最终结合Daemon自身的处理完成客户端的请求。

3、convoy卷插件实操

convoy卷插件实现，支持三种运行方式：devicemapper、NFS、EBS，以下实验使用nfs方式。

准备convoy.tar.gz安装包
server1安装nfs-utils，server2也安装nfs-utils

server1创建nfs目录，共享所有东西的读写权限，不转换身份，为了避免麻烦，权限777，重启nfs

server2创建nfs目录，挂载server1的/mnt/nfs

server1解压，并放入/usr/local/bin，使其可执行，后台开启convoy。server2也一样的操作

server1创建/etc/docker/plugins/目录，放置socket文件的路径，convoy list可以使用了，但是因为还没卷，所以是空的。server2也一样的操作

server1执行convoy create vol1创建卷vol1，就可以看到了

server2也可以看到

server1后台运行容器，使用卷vol1

curl可以看到发布信息，现在server1删除这个demo

server2后台运行容器，使用卷vol1

server2又可以看到数据了。