对docker来讲，作为容器运行的底层引擎，在运行容器时候每个容器内只运行一个程序及子程序，对于容器来讲，底层通过多层镜像联合挂载启动而成。底层能够存储此类分层构建并实现联合挂在文件系统包含：aufs，overlay2，在其上层会构建一个读写层
白话存储卷
对于读写层来讲，所有在容器中执行的操作，包括修改等，都在最上层的。对下层内容的操作，增删操作，就是通过“写时复制(COW)”来实现
如果一个A文件在最底层是存在的，而在layer1上标记为删除，那么在layer2上就看不见这个A文件了，用户肯定也看不到这个文件。同样，在layer0上的A文件，在Layer2上标记删除，在用户层仍然看不到这个文件。
在到达最上层之前被标记为删除，对于最上层的用户来讲都是不可见的，如果没有标记为删除，或者标记为删除后，用户又创建建立一个同样的，一模一样的同样的文件，用户也是可见的。
通常，在需要持久化存储服务的时候，如mysql,mariadb这类的应用，如果数据存放在最上的可写层，一方面性能较差且不说，容器在停止的时候，数据就会被删除（下图左）。要想绕过这种限制，就可以使用存储卷的机制来实现。存储卷可以在宿主机的某个文件目录，将这个目录与容器内部的文件系统之上的访问路径或者文件建立绑定关系。如下图
此后数据写入就直接写到宿主机的目录中，如上图右侧。这种方式类似于mount绑定的方式。这样一来容器文件在保存时候绕过容器的限制，通过宿主机的文件系统建立了关联关系，和容器内共享文件，也可以向容器供给文件。
容器宿主机是隔离的，通过这样的方式就可以与容器，容器与宿主机之间建立某个目录的绑定关系，在跨容器共享数据这样就简单多了。
容器内文件系统建立绑定关系的目录相对于容器来将就称为volume，也称为存储卷。
这样一来，容器删除，容器绑定宿主机的这个存储卷目录中的数据就不会消失，容器再次启动的时候也可以再次接着使用，只要宿主机不会坏掉，数据就在。
假设现在我们使用一个共享文件系统，宿主机也能驱动文件系统存储服务（假设NFS），这就意味着每个主机都能使用，而后主机上的容器会关联宿主机的某个目录，当容器数据保存后，事实上是保存在存储文件系统之上。
还有一个好处在于，假设这个容器被删除，下次这个容器启动在那个机器上就不在局限于单机之上，在集群内多机器也能够访问到存储系统，存储系统上的目录依旧在，依然可以访问到这些数据。
如果一个有状态应用的数据数据存储在容器内，在删除重建后数据再可用是关键的。
在一些有状态的应用就可能会需要持久存储数据，而无状态的应用大多不需要持久存储，还有一种有状态无需存储(只需要保存在内存中)。
当然，在docker本身是借助宿主机的磁盘，容器关联的是宿主机的磁盘上的目录而已。也就是宿主机本地的。这个卷(volume)在上面提到，是一个或多个目录，此类目录可绕过联合文件系统，与宿主机上的某目录绑定关联。
在容器用到存储卷的时候，并不需要手动去创建，容器run的时候卷(volume)就会被创建，由base image提供的卷中的数据在此期间完成复制。存储卷volume独立于容器的生命周期实现持久化，因此删除容器之时不会删除卷。
卷为docker提供了独立容器的管理机制，镜像可以重用，而卷可以共享。如果将数据写在根上，依然会保存在联合文件系统目录当中，如果保存在卷上，就写如到宿主机的卷上，也就是关联到宿主机的目录上。
