Docker存储卷

Docker存储卷

COW机制

Docker镜像由多个只读层叠加而成，启动容器时，Docker会加载只读镜像层并在镜像栈顶部添加一个读写层。

如果运行中的容器修改了现有的一个已经存在的文件，那么该文件将会从读写层下面的只读层复制到读写层，该文件的只读版本依然存在，只是已经被读写层中该文件的副本所隐藏，这就是“写时复制(COW)”机制。

对于这种方式来说，我们去访问一个文件，修改和删除等一类的操作，其效率会非常的低，因为隔着很多层镜像。

而要想绕过这种限制，我们可以通过使用存储卷的机制来实现。

什么是存储卷

存储卷就是将宿主机的本地文件系统中存在的某个目录直接与容器内部的文件系统上的某一目录建立绑定关系。这就意味着，当我们在容器中的这个目录下写入数据时，容器会将其内容直接写入到宿主机上与此容器建立了绑定关系的目录。

在宿主机上的这个与容器形成绑定关系的目录被称作存储卷。

使用存储卷的好处

如果容器中跑的进程的所有有效数据都保存在存储卷中，从而脱离容器自身文件系统之后，带来的好处是当容器关闭甚至被删除时，只要不删除与此容器绑定的在宿主机上的这个存储目录，我们就不用担心数据丢失了。因此就可以实现数据持久，脱离容器的生命周期而持久。

我们通过这种方式管理容器，容器就可以脱离主机的限制，可以在任意一台部署了docker的主机上跑容器，而其数据则可以置于一个共享存储文件系统上，比如nfs。

Docker的存储卷默认情况下是使用其所在的宿主机上的本地文件系统目录的，也就是说宿主机上有一块属于自己的硬盘，这个硬盘并没有共享给其他的Docker主机，而在这台主机上启动的容器所使用的存储卷是关联到此宿主机硬盘上的某个目录之上。

这就意味着容器在这台主机上停止运行或者被删除了再重建，只要关联到硬盘上的这个目录下，那么其数据还存在。但如果在另一台主机上启动一个新容器，那么数据就没了。而如果在创建容器的时候我们手动的将容器的数据挂载到一台nfs服务器上，那么这个问题就不再是问题了。

为什么要使用存储卷

关闭并重启容器，其数据不受影响，但删除Docker容器，则其更改将会全部丢失。

因此Docker存在的问题有：

• 存储于联合挂载文件系统中，不易于宿主机访问
• 容器间数据共享不便
• 删除容器其数据会丢失

而要解决这些问题，解决方案就是使用存储卷。

存储卷管理方式

存储卷（Data Volume）于容器初始化时被自动创建，由base image提供的卷中的数据会于此期间完成复制。

Volume的初衷是独立于容器的生命周期实现数据持久化，因此删除容器之时既不会删除卷，也不会对未被引用的卷做垃圾回收操作。

存储卷为Docker提供了独立于容器的数据管理机制，我们可以把镜像想象成静态文件，例如“程序”，把卷类比为动态内容，例如“数据”。所以镜像可以重用，而卷则可以共享。

卷实现了“程序(镜像)”和“数据(卷)”的分离，以及“程序(镜像)”和“制作镜像的主机”的分离，用户制作镜像时无须再考虑镜像运行的容器所在的主机的环境。

存储卷的分类

Docker有两种类型的卷，每种类型都在容器中存在一个挂载点，但其在宿主机上的位置有所不同：

• Bind mount volume（绑定挂载卷）：

  在宿主机上的路径要人工的指定一个特定的路径，在容器中也需要指定一个特定的路径，两个已知的路径建立关联关系

• Docker-managed volume（docker管理卷）：

  只需要在容器内指定容器的挂载点是什么，而被绑定宿主机下的那个目录，是由容器引擎daemon自行创建一个空的目录，或者使用一个已经存在的目录，与存储卷建立存储关系，这种方式极大解脱用户在使用卷时的耦合关系，缺陷是用户无法指定那些使用目录，临时存储比较适合;

容器数据管理

用户在使用Docker的过程中，往往需要能查看容器内应用产生的数据，或者需要把容器内的数据进行备份，甚至多个容器之间进行数据的共享，这必然涉及容器的数据管理操作。

容器中管理数据主要有两种方式：

• 数据卷（Data Volumes）
• 数据卷容器（Data Volumes Containers）

容器Volume使用语法：
Docker-managed volume

docker run -it --name CONTAINER_NAME -v VOLUMEDIR IMAGE_NAME

Bind mount volume

docker run -it --name CONTAINER_NAME -v HOSTDIR:VOLUMEDIR IMAGE_NAME

在容器中使用数据卷

在容器内创建一个数据卷

下面使用busybox镜像创建一个zsl1容器，并创建一个数据卷挂载到容器的/data目录下：

[root@localhost ~]# docker run -it --name zsl1 -v /data busybox
(另起一个终端)
root@localhost ~]# df -h
Filesystem           Size  Used Avail Use% Mounted on
overlay               17G  2.2G   15G  13% /var/lib/docker/overlay2/c4129ee11ded440f3ad6561b4dd47ef3ba66cfb6a8c5d69bc21a6f3548cdef6d/merged
[root@localhost ~]# docker inspect zsl1
......
"Mounts": [
            {
   
                "Type": "volume",