一、Docker底层存储机制介绍
对于Docker来讲，它作为容器运行的底层引擎，在组织和运行其容器时，每个容器内运行一个程序及子程序，容器启动时依赖于底层可能不止一层的只读镜像联合挂载启动而成。它底层能够存储此类分层构建并联合挂载镜像的文件系统包含AUFS、Overlayfs2、devmapper文件系统。最后一定要在最上层构建一个可写层。对于此可写层来说，所有在容器中所执行的写操作（对数据的修改、对内容的修改），都是保存在最上层的可写层。对下层内容的增删改操作我们需要使用“写时复制”（COW）机制来实现
写时复制机制是；如果一个文件在最底层是存在的，在任意层中被标记为删除，那么用户最上层就看不到这个文件了。用户能看到的只能是没被标记为删除的或者被标记为删除而用户在最上层又自己创建了同名的文件。
对于这种方式来说，我们去访问一个文件（修改删除等一类的操作），在访问和使用时，效率会非常的低。尤其是那些对I/O要求较高的应用比如redis、mysql。如mysql本身就对I/O要求就较高，如果mysql运行又是将数据写在容器内的联合挂载的最上层的可写层文件系统上，那么在容器停止时，数据将被删除。而且在实现数据存取时其效率的低下也是必然的情形。要想绕过这种使用的限制，我们可以通过使用存储卷的机制来实现。
二、存储卷介绍
所谓存储卷可以简单想象成在特权级的名称空间（宿主机）当中找一个本地文件系统之上存在某一个目录，把这个目录直接与容器内部的文件系统之上的某一个目录建立绑定关系，随后，容器内的进程向这个目录中写数据时，是直接被写在宿主机的目录上的，这和使用mount --bind命令的功能非常相似，这样就使得我们容器内部进程在实现数据保存时，能绕过容器内部文件系统的限制，从而与宿主机的文件系统建立了关联关系。这使得我们可以在宿主机和容器内共享数据和内容。可以让我们的容器直接访问宿主机的内容。同样的，也可以让宿主机直接向容器供给内容。这就相当于说让两个本来是隔离的mount名称空间在某个子路径上建立一定程度的绑定关系，从而使得在两个容器之间的文件系统的某个子路径上不在是隔离的，而且能够实现共享的效果。这种关联关系能够让容器之间在跨文件系统共享数据时，变得容易了，而在宿主机上的这个目录（与容器内的文件系统建立绑定关系的）对于容器来说，就被称作volume（存储卷）。存储卷带来的好处是当容器关闭甚至是删除时。我们都不用 担心数据丢书了，只要不删除绑定的在宿主机上的目录（存储卷）就可以。随后再次重建这个容器时，我们能让它关联到同一个存储卷上，就可以使用相同的数据。因此就能够数据持久脱离容器的生命周期而持久。
docker默认的存储卷是在本地的宿主机的文件系统之上，如果容器要在多个docker host之间迁移（使用docker 集群），我们还可以添加共享存储，如NFS文件系统使得容器内的有状态应用可以将迁移变的容易
2.1、容器内的文件系统存在的问题
关闭并重启容器，其数据不受影响，但删除容器，将同时删除容器数据
存储于联合挂载文件系统中，不易于宿主机访问
容器间数据共享不便
2.2、volume的好处
volume的初衷是独立于容器的生命周期实现数据持久化，因此删除容器时，不会删除其数据，也不会对未被引用的卷做垃圾回收工作。因此我们使用存储卷就是为了解决容器内的联合挂载文件系统所带来的问题。
2.3、volume的种类
Docker有两种类型的卷，每种类型都在容器中存在一个挂载点，但在宿主机上的位置有所不同
Bind mount volume：在宿主机和容器内的路径需要人工分别指定一个特定路径，两个已知路径建立绑定关系
docker run --name web1 -it -v HOSTDIR:VOLUMEDIR nginx:latest
Docker managed volume：只需要在容器内指定容器内的挂载点是哪里，而被绑定的是宿主机上的哪个路径下的目录由Docker的daemon自行创建一个空目录或者使用一个已存在的目录与存储卷建立绑定关系。
码头工人第五回(码头工人存储卷)
