一直一来，对于多个容器需要共享访问同一数据目录，或者需要持久化容器内数据（如数据库）时，我们都是采用挂载目录形式（bind mounts），将宿主机的某一目录挂载到容器内的指定目录，这种方式能解决问题，但这种方式也一直有一些缺点：
- 容器在不同的服务器部署需要根据实际磁盘挂载目录修改路径
- 不同操作系统的文件和目录权限会搞得你昏头转向，火冒三丈 ????
而这些问题，使用Volume就可以解决。我们先来对比一下bind mounts和docker volume，然后看volume是如何解决bind mounts的问题的。先来看一张图：
这张图说明bind mount和volume其实都是利用宿主机的文件系统，不同之处在于volume是docker自身管理的目录中的子目录，所以不存在权限引发的挂载的问题，并且目录路径是docker自身管理的，所以也不需要在不同的服务器上指定不同的路径，你不需要关心路径（其实也不全是，下面会关心 ????）。接下来就来看看bind mount和volume的不同用法吧。
1. 容器在不同的服务器部署需要根据实际磁盘挂载目录修改路径
例如：
在Linux系统中，我们经常使用"/var/someDir"作为挂载目录；
然而到了Mac上，/var/ 并不是真实存在的目录，Mac用户会告诉你，我们比Linux更先进，我们不用 /var/，用户不需要；
在Windows系统中，Windows用户会反问你：/var/ 是什么？C盘、D盘是最合理的划分～～
2. 不同操作系统的文件和目录权限会搞得你昏头转向，火冒三丈 ????
本来在Linux系统中测试的挺好，结果到了Windows上挂载路径各种问题，这里就不一一细说了，没有遇到这些问题的可以尝试一下，体验体验。不过在Mac中还好一些，毕竟和Linux同宗。
Docker中除了挂载方式，还有一种Volume可以持久化数据，说到这里有点汗颜，使用Docker这么久，一直把挂载当成Volume，不过也不怪我，Docker-compose文件中在volume段中写容器和宿主机挂载路径映射关系也没问题，就一直这么误解了。。（花式甩锅????）
其实“挂载”和“Docker Volume”并不是一回事，有一定的区别，Docker Volume是声明式的，Docker Engine本身会占用系统的某个目录，Linux一般为"/var/lib/docker"，Mac和Windows下都可以调节。当我们声明一个volume，Docker会默认在占用的路径下为volume分配一个路径，例如：
相对于挂载，volume是Docker Engine在自己的“地盘”分配了一个路径作为挂载点，自己地盘的权限肯定是安排的明明白白。所以，以上挂载宿主机路径的问题都解决了。????
在使用时，直接用volume名称代替宿主机路径名就行，假设我们上面创建了名为"test_vol"的volume：
- docker run -d -v "test_vol:/var/data" some_image，这样就将容器内的/var/data目录挂载到了"test_vol"的挂载点；
- docker-compose中类似，不过要在docker-compose.yaml文件中声明volume，我们还是拿上面的例子修改一下：
Attention !! ⚠️
- 需要注意 volume 会引起 docker目录膨胀，因为既要存镜像，又要存 volume，最好不要放在系统盘，将 docker 的安装目录配置到其他更大的挂载盘。
- 两者有一个不同的行为：当容器外的对应目录是空的，volume会先将容器内的内容拷贝到容器外目录，而mount会将外部的目录覆盖容器内部目录！！
- volume 还有一个不如bind mount的地方，不能直接挂载文件，例如挂载nginx容器的配置文件：nginx.conf。
这里需要说明，类似于配置文件这种单文件方式并不适合使用volume，bind mount虽然也可以解决，但由于config文件中包含一些类似于数据库密码等敏感信息，因此，最好的方式是使用tmpfs。
kubernetes的volume也体现出类似的设计，subPath虽然可以解决配置文件挂载的问题，但实际最好的方式是使用configMap。