电影频道做的网站广告,wordpress商城制作,景区网站建设策划案,沈阳seo顾问docker在实际使用中#xff0c;让运维人员诟病的#xff0c;除了安全问题外#xff0c;大概就是数据的问题了 很多人在初用docker的时候#xff0c;很多时候都忘记或不知道docker中需要保留的数据需要挂载到宿主机文件夹到容器内部对应目录#xff08;当然除了挂载宿主机目…docker在实际使用中让运维人员诟病的除了安全问题外大概就是数据的问题了 很多人在初用docker的时候很多时候都忘记或不知道docker中需要保留的数据需要挂载到宿主机文件夹到容器内部对应目录当然除了挂载宿主机目录还有其他解决方案我们后面会有文章介绍 当容器因为某些原因挂掉、无法重新启动的时候他们就认为数据丢失了找不回了这也是很多人对docker的一个认识误区网上没有一篇文章说docker数据的问题今天详细解释下docker数据在哪里 首先说一下这边以docker-ce 19.03.4版本举例GraphDriver是overlay2 这里说明下overlay技术是一种虚拟网络技术这里说的overlay是overlayfs是一种联合文件系统 我们通过docker info简单查看Storage Driver 也可以通过docker inspect 查看镜像或容器的详细信息
在GraphDriver部分可以看到使用的是什么文件系统之前旧内核的系统中的docker的GraphDriver是使用DeviceMapper由于overlay2性能比devicemapper好而且新版本docker-ce默认采用所以这里只研究overlay2 从上面的截图可以看到GraphDriver的data部分有四部分分别是LowerDir、MergerDir、UpperDir、WorkDir解释这几个概念之前先来回顾下docker的镜像的分层原理 docker镜像是一种轻量可执行的独立软件包 用来打包软件运行的环境和基于运行环境开发的软件 它包含运行某个软件所需要的所有内容包括代码、运行时的库、环境变量和配置文件 docker的镜像实际上由一层一层的文件系统组成这种层级的文件系统称为联合文件系统(unionFS) UnionFS联合文件系统union文件系统unionFS是一种分层、轻量级并且高性能的文件系统它支持 对文件系统的修改作为一次提交来一层层的叠加 同时可以将不同的目录挂载到同一个虚拟文件系统下。union文件系统是docker镜像的基础。镜像可以通过分层来进行继承。基于基础镜像没有父镜像可以制作各种的应用镜像 这种分层最大的好处就是资源共享 很多时候你pull镜像的时候如果是来源于相同的base镜像你可以看到pull的时候底下的层是已经pulled而且base64加密id是一样的这就是因为base镜像资源已经下载可以共享使用不需要重复下载 在容器中伴随联合文件系统的一个技术就是写时复制(CoW)该技术是linux内核的一个技术为了避免不必要的进程间复制操作在父进程fork子进程后父子进程共享同一副本当子进程需要调用exec写入的时候数据才会被复制从而父子进程各自有自己的副本 结合容器技术来看当处于镜像态的时候所有的层级都是只读的但是当docker run启动为容器态的时候在基础镜像上添加了一层可读写层这时肯定会在最上层可读写层进行文件写入就需要将要写入的文件从它存在的层复制到可读写层然后进行读写并隐藏只读层的旧文件这个就是利用了写时复制技术 回顾了这些基础之后接着看下overlay2的基础概念及原理 overlayfs在linux主机上只有两层一个目录在下层用来保存镜像(docker)另外一个目录在上层用来存储容器信息。在overlayfs中底层的目录叫做lowerdir顶层的目录称之为upperdir对外提供统一的文件系统为merged。当需要修改一个文件时使用CoW将文件从只读的Lower复制到可写的Upper进行修改这个复制出来的临时目录就是Workdir结果也保存在Upper层 以上就是GraphDriver的data部分的四部分可以从前面的图中看到lowerdir包含多个层因为它就是rootfs容器镜像也就是我们pull镜像的时候看到的层级 overlay2存储在/var/lib/docker/overlay2目录中如果你只有少数镜像比较好查看多个镜像的时候就只能通过docker inspect的方式查找对应镜像的层级id然后通过这个id去overlay2目录去找对应的overlayfs目录 在该目录下有个“l”目录这个目录是存放所有overlayfs目录的短名称的通过软连接的方式与overlyafs目录下的所有目录链接这个是为了在mount挂载的时候避免参数太长达到页面大小限制 接着我们分别看下LowerDir、MergerDir、UpperDir、WorkDir 我这里通过个redis容器来说明首先是lowerdirlowerdir因为有多个你可以一个一个进去看一下就能够看明白它每个层级存储的东西如下
LowerDir: /var/lib/docker/overlay2/3d56c8ea55a05f092442c3cdf01c49556a71b8f089a5772413ef566ec68bca31-init/diff :/var/lib/docker/overlay2/7e6a11d051174f5a71ce038268e6fa8a310d046032ed435b10ed7846f9eb2d92/diff :/var/lib/docker/overlay2/bbcd520d1d0d62323bcac4a66328164b99fa1704974ceffc412d348c6f7b55e9/diff /var/lib/docker/overlay2/dee456318494848b5ea4182ddb8f67f25969b121580afa9ff8aa73cf9c0d256e/diff :/var/lib/docker/overlay2/a45bb32d7cd7d2386d12826e4d8e524b410616d06cf1ec29f2eab03ba3eb80b2/diff :/var/lib/docker/overlay2/085f1022334a3727171e3d038ed59f69cb0c6199b93a84afeb1e0b1b8674abf1/diff 从上面可以看出来diff就是存储该层rootfs的目录而每个层级里面的link文件里面存储的就是l文件夹下的短名称的超链接除了最底层上层都有一个lower文件该文件里面就存储了它上层的短名称 而work目录用来联合挂载指定的工作目录 接着看MergedDir、UpperDir、WorkDir其实是指向一个层级id只是目录不同是不是觉得这个id这么熟悉其实在LowerDir的最上层的id就是这个只不过它最后面有个init这个init稍后介绍先来看下这三个目录 mergedir对外提供统一的视图这里可以看到整合了所有lowerdir层级的文件
因为是新启动的容器upperdir目录没有内容workdir目录因为写时复制很快所以通常也无法看到后面进入容器写入文件进行会在upperdir目录看到内容
关于init层
init层是以一个uuid-init结尾表示夹在只读层和读写层之间作用是专门存放/etc/hosts、/etc/resolv.conf等信息需要这一层的原因是当容器启动时候这些本该属于image层的文件或目录比如hostname用户需要修改但是image层又不允许修改所以启动时候通过单独挂载一层init层通过修改init层中的文件达到修改这些文件目的。而这些修改往往只在当前容器生效而在docker commit提交为镜像时候并不会将init层提交。该层文件存放的目录为/var/lib/docker/overlay2/init_id/diff 从上面这部分可以看到所有容器或者镜像的层级目录都存在overlay2目录下那么一个容器或者镜像是怎么把这些整合起来的答案是元数据关联元数据分为image元数据和layer元数据 镜像元数据存储在了/var/lib/docker/image/storage_driver/imagedb/content/sha256/目录下名称是以镜像ID命名的文件镜像ID可通过docker images查看这些文件以json的形式保存了该镜像的rootfs信息、镜像创建时间、构建历史信息、所用容器、包括启动的Entrypoint和CMD等等比如刚才的redis镜像 打开该文件是一个json格式文件但是没有vim默认没有格式化通过:%!python -m json.tool工具转换成json格式查看 其中rootfs部分 可以看到对应前面的6层overlayfs其排列也是有顺序的从上到下依次表示镜像层的最低层到最顶层
diff_id如何关联进行层具体说来docker 利用 rootfs 中的每个diff_id 和历史信息计算出与之对应的内容寻址的索引(chainID) 而chaiID则关联了layer层进而关联到每一个镜像层的镜像文件 layer元数据中layer对应镜像层的概念在 docker 1.10 版本以前镜像通过一个 graph 结构管理每一个镜像层都拥有元数据记录了该层的构建信息以及父镜像层 ID而最上面的镜像层会多记录一些信息作为整个镜像的元数据。graph 则根据镜像 ID(即最上层的镜像层 ID) 和每个镜像层记录的父镜像层 ID 维护了一个树状的镜像层结构。 在 docker 1.10 版本后镜像元数据管理巨大的改变之一就是简化了镜像层的元数据镜像层只包含一个具体的镜像层文件包。用户在 docker 宿主机上下载了某个镜像层之后docker 会在宿主机上基于镜像层文件包和 image 元数据构建本地的 layer 元数据包括 diff、parent、size 等。而当 docker 将在宿主机上产生的新的镜像层上传到 registry 时与新镜像层相关的宿主机上的元数据也不会与镜像层一块打包上传。 Docker 中定义了 Layer 和 RWLayer 两种接口分别用来定义只读层和可读写层的一些操作又定义了 roLayer 和 mountedLayer分别实现了上述两种接口。其中roLayer 用于描述不可改变的镜像层mountedLayer 用于描述可读写的容器层。具体来说roLayer 存储的内容主要有索引该镜像层的 chainID、该镜像层的校验码 diffID、父镜像层 parent、storage_driver 存储当前镜像层文件的 cacheID、该镜像层的 size 等内容。这些元数据被保存在 /var/lib/docker/image/storage_driver/layerdb/sha256/chainID/ 文件夹下 每个chainID目录下会存在三个文件cache-id、diff、zize cache-id文件
docker随机生成的uuid内容是保存镜像层的目录索引也就是/var/lib/docker/overlay2/中的目录这就是为什么通过chainID能找到对应的layer目录 如图对应的overlay目录为/var/lib/docker/overlay2/e701317468246c6188f1bff4f9b9c159648d86108bb02e0ef5f224fd49efd1f0
diff文件
保存了镜像元数据中的diff_id与元数据中的diff_ids中的uuid对应 size文件
保存了镜像层的大小 在 layer 的所有属性中diffID 采用 SHA256 算法基于镜像层文件包的内容计算得到。而 chainID 是基于内容存储的索引它是根据当前层与所有祖先镜像层 diffID 计算出来的具体算如下 如果该镜像层是最底层(没有父镜像层)该层的 diffID 便是 chainID。 该镜像层的 chainID 计算公式为 chainID(n)SHA256(chain(n-1) diffID(n))也就是根据父镜像层的 chainID 加上一个空格和当前层的 diffID再计算 SHA256 校验码。
综合上述一个完整的容器层如下图
回到开头启动后的容器数据存在哪里 可以肯定的是在可读写层结合overlayfs原理看就是在upperdir也就是可读写层中的diff目录比如我们进入容器在home目录下写入个测试文件然后查看diff目录 在mergedir目录下同样也有该文件 从实际中看并不是所有数据都在这个目录当启动容器的时候通过挂载本地目录的形式映射容器内部目录的时候数据不再存储在overlayfs而是直接存储在本地映射的目录 另外一种情况是当使用dockerfile指定workdir的情况下启动容器会自动挂载一个volume目录到workdir目录 那么这个时候存在workdir目录下的数据会存在自动映射的Source目录下 总结如下
只要不删除容器数据完全可以找回
