文章目录
一、前言
在之前的nginx案例中，修改nginx的html页面时，需要进入nginx内部。并且因为没有编辑器，修改文件也很麻烦。
这就是因为容器与数据（容器内文件）耦合带来的后果。
要解决这个问题，必须将数据与容器解耦，这就要用到数据卷了。
二、数据卷
**数据卷（volume）**是一个虚拟目录，指向宿主机文件系统中的某个真实目录。
假设这里有个docker的主机，在这个主机上就会由docker去管理很多数据卷，所有的数据卷一定会指向宿主机文件系统中的一个目录 /var/lib/docker/volumes。
作用：将容器与数据分离，解耦合，提高数据的复用性，方便操作容器内数据，保证数据安全
比如说我现在利用docker创建了一个新的数据券，这个数据券的名字叫：html，那么docker一定会在这个指定的宿主机文件系统下创建出html目录。当再次创建一个新的数据卷时，它同样会在volumes（卷）目录下再创建一个真实目录，每一个数据卷都会跟一个真实的目录进行映射。
所以你可以认为：数据券它是一个虚拟的，并不真实，它只是一个概念；而真正指向的是硬盘上的真实的文件夹。
当我们的Container（容器）在创建之后，它就可以使用数据卷。比方说，我们现在有一个nginx容器，nginx的html目录是在 /usr/share/nginx/html ，这是容器内的目录，将来如果我们放任不管，nginx所有html文件、静态文件都会创建到这个目录下，所有配置都会放到 /etc/nginx/conf 目录下，这时就是数据与容器耦合了。
现在我们可以让nginx的内部目录与数据卷进行关联，当它与数据卷进行关联时，它的本质是在跟宿主机文件系统上的目录进行关联。这个时候，docker就会去管理这个容器了。比如说我在这个nginx容器的html目录里写了点东西，这些东西会立即写到宿主机的文件系统里。而反过来，如果说我在宿主机文件系统里，对html文件夹里面的某一个文件进行了修改，这个修改也会立即反映到容器内的这样一个目录里面去。这就可以说，宿主机文件系统和Container通过html数据卷建立起了联系。
一旦完成数据卷挂载，对容器的一切操作都会作用在数据卷对应的宿主机目录了。
这样，我们操作宿主机的/var/lib/docker/volumes/html目录，就等于操作容器内的/usr/share/nginx/html目录了
那么我们之前的问题由此就解决了
- 修改不方便：现在对宿主机文件系统的html目录下的任意修改，一定会反映到跟这个对应数据卷关联的容器内部，再也不需要进入容器内部修改了。
- 数据共享：只需要让第二个nginx容器的config目录也来挂载config数据卷，也就是说两个容器可以挂在同一个卷上，也就是说，原来在conf做的一切修改，在新的容器里也能看见。
- 数据安全 / 删除：删除没关系，因为容器删了，但是数据卷不会跟着删，数据卷是挂载在容器的目录上，将来来了新版本的容器，只需要接着挂载到这个数据卷上，这样就可以共享以前旧的数据了。
三、数据卷(volume)操作命令
数据卷操作是一个二级命令，第一级是 docker volume ，接下来才是真正的命令
数据卷操作的基本语法如下：
docker volume [COMMAND]
docker volume命令是数据卷操作，根据命令后跟随的command来确定下一步的操作：
create 数据卷名称：创建一个volumeinspect 数据卷名称（其中volume可以省略）：查看一个或多个数据卷详细信息，包括关联的宿主机目录位置ls：列出所有的volumeprune：删除所有未使用的数据卷rm 数据卷名称：删除一个或多个指定的volume
四、案例：创建和查看数据卷
需求：创建一个数据卷，并查看数据卷在宿主机的目录位置
首先通过 docker volume --help 来查看帮助文档
① 创建数据卷，后面跟上数据卷的名称
以下就是创建了一个名为html的数据卷
docker volume create html
② 查看所有数据卷
docker volume ls
结果：
③ 查看数据卷详细信息卷
docker volume inspect html
特别需要关注的就是它的挂载点：我们创建的 html 这个数据卷关联的宿主机目录为/var/lib/docker/volumes/html/_data ，多了一个 _data，这里面是真实存储的。
④ 删除所有未使用的数据卷
docker volume prune