如何理解docker联合文件系统、分层、数据卷、数据卷容器。

Docker 镜像讲解

镜像是一种轻量级、可执行的独立软件包，用来打包软件运行环境和基于运行环境开发的软件，它包含运行某个软件所需的所有内容，包括代码、运行时、库、环境变量和配置文件。
所有的应用，直接打包docker镜像，就可以直接跑起来！
如何得到镜像：从远程仓库下载、朋友拷贝、自己制作一个镜像dockerfile

UninoFS（联合文件系统）

UninoFS：是一种分层、轻量级并且高性能的文件系统，它支持对文件系统的修改作为一次提交来一层层的叠加，同时可以将不同目录挂载到同一个虚拟文件系统下，UninoFS文件系统是docker镜像的基础，镜像可以通过分层来实现的，基于基础镜像（没有父镜像），可以制作各种具体的应用镜像。
特性：一次同时加载多个文件系统，但是从外面看起来，只能看到一个文件系统，联合加载会把各层文件系统叠加起来，这样最终的文件系统会保函所有底层的文件和目录。

Docker镜像加载原理

Docker的镜像实际上由一层一层的文件系统组成，这种层级的文件系统（UinnioFS）
（系统启动需要引导加载）黑屏-开机-显示屏幕 --加载
Bootfs（boot file system）主要包括bootloader和kernel，bootloader主要时引导加载kernal，Linux刚启动时会加载bootfs文件系统，在Docker镜像的最底层是bootfs，这一层与我们典型的Linux系统时一样的，包含boot加载器和内核，当boot加载完成之后整个内核都在内存中了，此时内存的使用权已有bootfs转交给内核，此时也会卸载bootfs。
Rootfs（root file system）在bootfs之上，包含的就是典型的linux系统中的/dev /proc /bin /etc 等标准目录和文件，rootfs就是各种不同的操作系统发行版，比如Ubuntu，Centos
对于一个精简的OS(内核)，rootfs可以很小，只需要包含最基本的命令，工具和程序库就可以了，因为底层直接用Host（主机的）的Kernel,自己只需要提供rootfs就可以了，由此可见对于不同的linux发行版，bootfs基本时一致的，因此不同的发行版可以公用bootfs

分层的原理

所有的docker镜像都起始于一个基础镜像层，当进行修改或者增加新的内容时，就会在当前镜像层之上，创建新的镜像层，比如：假设基于Ubuntu Linux 16.04创建一个新的镜像，这就是新镜像的第一层，如果在该镜像中添加python包，就会在基础镜像层之上创建第二个镜像层，如果继续添加一个安全补丁，就会创建第三个镜像层，该镜像当前已经包含3个镜像层。
在添加额外的镜像层的同时，镜像始终保持是当前所有镜像的组合，理解这一点非常重要！
注意：假如在docker中又添加了python的最新版本，这时，docker并不会新增加一层，而是用最新版本的python替换了原来的旧版本python！
扩展：
Linux上可用的存储引擎有AUFS,Overlay2，Device mapper， btrfs，以及ZFS顾名思义，每种存储引擎都是基于Linux中对应的文件系统或块设备技术，并且每种存储引擎都有其独特的性能特点。
Docker在windows上仅支持windowsfiler一种存储引擎，该引擎基于NTFS文件系统之上实现了分层和Cow

Docker 数据卷

数据卷的由来：数据不应该存放在容器中，因为如果删除容器，那么数据就会丢失！
因此急需一个持久化技术来解决这个问题! docker数据卷应运而生！
因此,我们可以带着下面这个想法来学习技术！
所有的技术由来都是为了解决当时所遇到的困难而生的
数据卷：将容器的数据和宿主机进行共享
比如一个容器时mysql，这个容器有自己的文件系统，并且是隔离的，Linux也有自己的文件系统，这个Linux文件系统在容器外面，我们需要将mysql容器中的文件系统和Linux文件系统做映射！

数据卷的使用
方式一：直接使用命令挂载 -v
docker run -it -v 主机目录地址:容器内目录
可以通过docker inspect id 查看容器相关信息

Source ： 主机内地址
Destination ： 容器内地址
测试1、可以自己测试一下在挂载的宿主机上新建文件，然后查看容器中是否可以查看到！
测试2、在容器中新建文件，再去宿主机上查看文件是否可以找到！
测试3、删除容器，看宿主机上的文件是否被影响！

这个测试过程就不展示了！只有实战才能掌握真知！

具名挂载和匿名挂载
匿名挂载：-v 容器内路径
注意：此时并没有指定容器外的路径，此时容器会和宿主机自动挂载到一个位置
例如：dockre run -d -p –name nginx1 -v /etc/nginx

我们可以通过：docker volume ls 来查看容器挂载的数据卷名字

具名挂载
例如：docker run -d -P --name=nginx2 -v bins9:/etc/nginx nginx
见上图
也可以通过docker volume inspect 数据卷名字。 来查看数据卷具体挂载情况

拓展
通过 -v 容器内路径 + ro或者rw 改变读写权限

数据卷容器

数据卷容器的出现是为了解决容器之间数据共享问题！
我们来做一个简单测试和探寻数据卷容器的秘密
**测试：**多个mysql数据共享！
数据卷容器命令：–volume-from
前提：使用dockerfile自己创建一个镜像，并指定共享的文件夹
我的dockerfile文件：

通过VOLUME指定了两个共享数据卷（这个是匿名挂载，因为并没有指定数据卷名字）

步骤1、启动一个容器命名 bins01

步骤2、启动一个容器命名bins02 并将bins02挂载我bins01上

步骤3、启动一个容器命名bins03 并将bins03挂载我bins02上

此时我们再bins03中的共享文件夹volume01新建一个bins03.java文件然后去bins01中查看是否可以查看到


注意看root@后面跟的容器id是不一样的。
因此测试1的结论是可以看到的。
猜想：是不是bins03共享文件给bins02，然后bins02共享文件给bins01，所以bins03和bins01文件也互相共享了？
因此我们需要再做一个测试来验证这一点！
**测试2、**如果我们将bins02 删除，再在bins03中建一个文件，那么bins01中是否还能同步呢？
步骤1、将bins02停止，并且删除

步骤2、现在只剩下bins03和bins01，然后在bins03中创建文件bins.java

步骤3、去bins01容器中查看，是否还可以传递到！

我的天啊！！！！！竟然会有！！！

这究竟是怎么回事呢？？

为什么bins01和bins03还能保证数据同步呢？
思考：
我们创建容器的过程
bins01启动的时候是匿名挂载到宿主机上的。
bins02启动的时候并没有指定挂载路径，而是通过- -volume-from bins01 来挂载到bins01上。
bins03启动的时候并没有指定挂载路径，而是通过- -volume-from bins02 来挂载到bins02上。
大胆猜想：
bins02启动的时候是否是通过 - -volume-from bins01 将bins02上的文件也挂载到了和bins01相同位置的宿主机目录下！
bins03启动的时候是否是通过 - -volume-from bins02将bins03上的文件也挂载到了和bins02相同位置的宿主机目录下！

开始操办：
查看bins01的容器相关信息 通过mounts找到挂载到宿主机的目录

bins01容器挂载信息

因为bins03和bins01的挂载信息是一致的，在此就不列举了！
可以发现bins01和bins03这两个容器都挂载到相同的宿主机目录下，因此也就解释了，为什么我们删除bins02，在bins03下创建文件，bins01中也可以获取到！

结论：
容器之间配置信息的传递，数据卷容器的生命周期一直持续到没有容器使用为止！