认识 Docker Volume

---

---

容器技术使用了 rootfs 机制和 Mount Namespace，构建出了一个同宿主机完全隔离开的文件系统环境。
那么这时候还需要考虑两个问题：

1、宿主机上的文件和目录，怎么才能让容器里的进程访问到？
2、而容器里进程新建的文件，怎么才能让宿主机获取到？

这正是 Docker Volume 要解决的问题：Volume 机制，允许你将宿主机上指定的目录或者文件，挂载到容器里面进行读取和修改操作。

---

一、宿主机目录挂载到容器

那么，Docker 是如何做到把一个宿主机上的目录或者文件，挂载到容器里面去呢？

当容器进程被创建之后，
尽管开启了 Mount Namespace，但是在执行 chroot（或者 pivot_root）之前，容器进程一直可以看到宿主机上的整个文件系统。

而宿主机的文件系统包括了容器镜像，容器镜像的各个层，保存在 /var/lib/docker/aufs/diff 目录下，
在容器进程启动后，它们会被联合挂载到 /var/lib/docker/aufs/mnt/ 目录中，这样容器所需的 rootfs 就准备好了。

所以，
我们只需要在 rootfs 准备好之后，在执行 chroot 之前，
把 Volume 指定的宿主机目录（比如 /home 目录）挂载到指定的容器目录（比如 /test 目录）在宿主机上对应的目录（即 /var/lib/docker/aufs/mnt/[可读写层 ID]/test）上，
这个 Volume 的挂载工作就完成了。

另外，由于此时 Mount Namespace 已经开启；所以，这个挂载事件只在这个容器里可见。
你在宿主机上，是看不见容器内部的这个挂载点的； 这就保证了容器的隔离性不会被 Volume 打破。

---

二、 bind mount 原理

上面用到的挂载技术，就是 Linux 的绑定挂载（bind mount）机制。
它的主要作用就是，允许你将一个目录或者文件，而不是整个设备，挂载到一个指定的目录上。
并且，这时你在该挂载点上进行的任何操作，只是发生在被挂载的目录或者文件上，而原挂载点的内容则会被隐藏起来且不受影响。

bind mount 绑定挂载实际上是一个 inode 替换的过程：
在 Linux 操作系统中，inode 可以理解为存放文件内容的“对象”，而 dentry，也叫目录项，就是访问这个 inode 所使用的“指针”。

如上图所示，

mount --bind  /home /test

会将 /home 挂载到 /test 上，相当于将 /test 的 dentry，重定向到了 /home 的 inode。

当我们修改 /test 目录时，实际修改的是 /home 目录的 inode。
所以一旦执行 umount 命令，/test 目录原先的内容就会恢复：因为修改真正发生在的，是 /home 目录里。

所以，在一个正确的时机，进行一次绑定挂载，Docker 就可以成功地将一个宿主机上的目录或文件挂载到容器中，让容器里的进程访问到。

这样，进程在容器里对这个 /test 目录进行的所有操作，都实际发生在宿主机的对应目录 /home 里，而不会影响容器镜像的内容。

---

三、Volume 信息 是否会被 docker commit 提交？

那么，这个 /test 目录里的内容，既然挂载在容器 rootfs 的可读写层，它会不会被 docker commit 提交掉呢？
也不会。
容器的镜像操作，比如 docker commit，都是发生在宿主机空间的。
而由于 Mount Namespace 的隔离作用，宿主机并不知道这个绑定挂载的存在。
在宿主机看来，容器中可读写层的 /test 目录（/var/lib/docker/aufs/mnt/[可读写层 ID]/test），始终是空的。

所以，容器 Volume 里的信息并不会被 docker commit 提交掉；但这个挂载点目录 /test 本身会出现在新的镜像当中。

---

volume 本质上只是宿主机上的一个独立目录，而并不属于 rootfs 的一部分！

---

参考文档：张磊老师的 深入剖析Kubernetes