Docker镜像存储overlayfs的使用

一、概述

  Docker中的镜像采用分层构建设计,每个层可以称之为“layer”,这些layer被存放在了/var/lib/docker/<storage-driver>/目录下,这里的storage-driver可以有很多种如:AUFS、OverlayFS、VFS、Brtfs等。可以通过docker info命令查看存储驱动,(笔者系统是centos7.4):

通常ubuntu类的系统默认采用的是AUFS,centos7.1+系列采用的是OverlayFS。而本文将介绍以OverlayFS作为存储驱动的镜像存储原理以及存储结构。

二、OverlayFS 介绍

  OverlayFS是一种堆叠文件系统,它依赖并建立在其它的文件系统之上(例如ext4fs和xfs等等),并不直接参与磁盘空间结构的划分,仅仅将原来底层文件系统中不同的目录进行“合并”,然后向用户呈现,这也就是联合挂载技术,对比于AUFS,OverlayFS速度更快,实现更简单。 而Linux 内核为Docker提供的OverlayFS驱动有两种:overlay和overlay2。而overlay2是相对于overlay的一种改进,在inode利用率方面比overlay更有效。但是overlay有环境需求:docker版本17.06.02+,宿主机文件系统需要是ext4或xfs格式。

联合挂载

   overlayfs通过三个目录:lower目录、upper目录、以及work目录实现,其中lower目录可以是多个,work目录为工作基础目录,挂载后内容会被清空,且在使用过程中其内容用户不可见,最后联合挂载完成给用户呈现的统一视图称为为merged目录。以下使用mount将演示其如何工作的。

使用mount命令挂载overlayfs语法如下:

mount -t overlay overlay -o lowerdir=lower1:lower2:lower3,upperdir=upper,workdir=work merged_dir

创建三个目录A、B、C,以及worker目录:

然后使用mount联合挂载到/tmp/test 下:

然后我们再去查看/tmp/test目录,你会发现目录A、B、C被合并到了一起,并且相同文件名的文件会进行“覆盖”,这里覆盖并不是真正的覆盖,而是当合并时候目录中两个文件名称都相同时,merged层目录会显示离它最近层的文件:

同时我们还可以通过mount命令查看其挂载的选项:

以上这样的方式也就是联合挂载技术。

Docker中的overlay驱动

  介绍了overlay驱动原理以后再来看Docker中的overlay存储驱动,以下是来自docker官网关于overlay的工作原理图:

在上述图中可以看到三个层结构,即:lowerdir、uperdir、merged,其中lowerdir是只读的image layer,其实就是rootfs,对比我们上述演示的目录A和B,我们知道image layer可以分很多层,所以对应的lowerdir是可以有多个目录。而upperdir则是在lowerdir之上的一层,这层是读写层,在启动一个容器时候会进行创建,所有的对容器数据更改都发生在这里层,对比示例中的C。最后merged目录是容器的挂载点,也就是给用户暴露的统一视角,对比示例中的/tmp/test。而这些目录层都保存在了/var/lib/docker/overlay2/或者/var/lib/docker/overlay/(如果使用overlay)。

演示

启动一个容器

查看其overlay挂载点,可以发现其挂载的merged目录、lowerdir、upperdir以及workdir:

overlay2的lowerdir可以有多个,并且是软连接方式挂载,后续我们会进行说明。

如何工作

当容器中发生数据修改时候overlayfs存储驱动又是如何进行工作的?以下将阐述其读写过程:

读:

  • 如果文件在容器层(upperdir),直接读取文件;
  • 如果文件不在容器层(upperdir),则从镜像层(lowerdir)读取;

修改:

  • 首次写入: 如果在upperdir中不存在,overlay和overlay2执行copy_up操作,把文件从lowdir拷贝到upperdir,由于overlayfs是文件级别的(即使文件只有很少的一点修改,也会产生的copy_up的行为),后续对同一文件的在此写入操作将对已经复制到容器的文件的副本进行操作。这也就是常常说的写时复制(copy-on-write)
  • 删除文件和目录: 当文件在容器被删除时,在容器层(upperdir)创建whiteout文件,镜像层(lowerdir)的文件是不会被删除的,因为他们是只读的,但without文件会阻止他们显示,当目录在容器内被删除时,在容器层(upperdir)一个不透明的目录,这个和上面whiteout原理一样,阻止用户继续访问,即便镜像层仍然存在。

注意事项

  • copy_up操作只发生在文件首次写入,以后都是只修改副本,
  • overlayfs只适用两层目录,,相比于比AUFS,查找搜索都更快。
  • 容器层的文件删除只是一个“障眼法”,是靠whiteout文件将其遮挡,image层并没有删除,这也就是为什么使用docker commit 提交保存的镜像会越来越大,无论在容器层怎么删除数据,image层都不会改变。

三、overlay2镜像存储结构

从仓库pull一个ubuntu镜像,结果显示总共拉取了4层镜像如下:

此时4层被存储在了/var/lib/docker/overlay2/目录下:

这里面多了一个l目录包含了所有层的软连接,短链接使用短名称,避免mount时候参数达到页面大小限制(演示中mount命令查看时候的短目录):

处于底层的镜像目录包含了一个diff和一个link文件,diff目录存放了当前层的镜像内容,而link文件则是与之对应的短名称:

在这之上的镜像还多了work目录和lower文件,lower文件用于记录父层的短名称,work目录用于联合挂载指定的工作目录。而这些目录和镜像的关系是怎么组织在的一起呢?答案是通过元数据关联。元数据分为image元数据和layer元数据。

image元数据

  镜像元数据存储在了/var/lib/docker/image/<storage_driver>/imagedb/content/sha256/目录下,名称是以镜像ID命名的文件,镜像ID可通过docker images查看,这些文件以json的形式保存了该镜像的rootfs信息、镜像创建时间、构建历史信息、所用容器、包括启动的Entrypoint和CMD等等。例如ubuntu镜像的id为47b19964fb50:

查看其对应的元数据(使用vim :%!python -m json.tool格式化成json) 截取了其rootfs的构成:

上面的 diff_id 对应的的是一个镜像层,其排列也是有顺序的,从上到下依次表示镜像层的最低层到最顶层:

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目录。以chainID为d801a12f6af7beff367268f99607376584d8b2da656dcd8656973b7ad9779ab4 对应的目录为 130ea10d6f0ebfafc8ca260992c8d0bef63a1b5ca3a7d51a5cd1b1031d23efd5,也就保存在/var/lib/docker/overlay2/130ea10d6f0ebfafc8ca260992c8d0bef63a1b5ca3a7d51a5cd1b1031d23efd5

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 校验码。

mountedLayer 信息存储的可读init层以及容器挂载点信息包括:容器 init 层ID(init-id)、联合挂载使用的ID(mount-id)以及容器层的父层镜像的 chainID(parent)。相关文件位于/var/lib/docker/image/<storage_driver>/layerdb/mounts/<container_id>/ 目录下。如下启动一个id为3c96960b3127的容器:

查看其对应的mountedLayer三个文件:

可以看到initID是在mountID后加了一个-init,同时initID就是存储在/var/lib/docker/overlay2/的目录名称:

查看mountID还可以直接通过mount命令查看对应挂载的mountID,对应着/var/lib/docker/overlay2/目录,这也是overlayfs呈现的merged目录:

在容器中创建了一文件:

此时到宿主的merged目录就能看到对应的文件:

关于init层

  init层是以一个uuid+-init结尾表示,夹在只读层和读写层之间,作用是专门存放/etc/hosts、/etc/resolv.conf等信息,需要这一层的原因是当容器启动时候,这些本该属于image层的文件或目录,比如hostname,用户需要修改,但是image层又不允许修改,所以启动时候通过单独挂载一层init层,通过修改init层中的文件达到修改这些文件目的。而这些修改往往只读当前容器生效,而在docker commit提交为镜像时候,并不会将init层提交。该层文件存放的目录为/var/lib/docker/overlay2/<init_id>/diff

小结

通过以上的内容介绍,一个容器完整的层应由三个部分组成,如下图:

  • 镜像层:也称为rootfs,提供容器启动的文件系统
  • init层: 用于修改容器中一些文件如/etc/hostname、/etc/resolv.conf等
  • 容器层:使用联合挂载统一给用户提供的可读写目录。

四、总结

  本文介绍了以overlayfs作为存储驱动的的镜像存储原理其中每层的镜像数据保存在/var/lib/docker/overlay2/<uuid>/diff目录下,init层数据保存了在 /var/lib/docker/overlay2/<init-id>/diff目录下,最后统一视图(容器层)数据在 /var/lib/docker/overlay2/<mount_id>/diff目录下,docker通过image元数据和layer元数据利用内容寻址(chainID)将这些目录组织起来构成容器所运行的文件系统。

参考:

《use overlayfs driver 》

《Docker 镜像之存储管理》

到此这篇关于Docker镜像存储overlayfs的使用的文章就介绍到这了,更多相关Docker镜像存储overlayfs内容请搜素我们以前的文章或下面相关文章,希望大家以后多多支持我们!

(0)

相关推荐

  • 修改Docker默认镜像和容器的存储位置的方法

    本文介绍了修改Docker默认镜像和容器的存储位置的方法,分享给大家,具体如下: 一.Why Docker默认的镜像和容器存储位置在/var/lib/docker中,如果仅仅是做测试,我们可能没有必要修改,但是当大量使用的时候,我们可能就要默认存储的位置了. 二.How 2.1 修改docker.service文件 cd /etc/systemd/system/multi-user.target.wants vim docker.service ExecStart=/usr/bin/docker

  • 浅析Docker私有镜像库与阿里云对象存储 OSS

    Docker私有镜像库 Docker 私有镜像库与阿里云对象存储 OSS 镜像管理是 Docker 的核心,为了满足企业或组织内部分享镜像,Docker 官方在 Github上 建立了一个开源项目 docker-registry,专门用于自建 Docker 的私有镜像库. 快速启动支持阿里云对象存储 OSS 的 docker-registry 您可以从 https://github.com/docker/docker-registry 下载并安装 docker-registry,通过 pip 安

  • Docker镜像存储overlayfs的使用

    一.概述 Docker中的镜像采用分层构建设计,每个层可以称之为"layer",这些layer被存放在了/var/lib/docker/<storage-driver>/目录下,这里的storage-driver可以有很多种如:AUFS.OverlayFS.VFS.Brtfs等.可以通过docker info命令查看存储驱动,(笔者系统是centos7.4): 通常ubuntu类的系统默认采用的是AUFS,centos7.1+系列采用的是OverlayFS.而本文将介绍以O

  • 详解docker pull下来的镜像存储在哪里

    20200804补充:文章可能说法有误.大佬可查询其他答案. docker pull xxx,就可以把想要的镜像拉下来直接使用,但是pull下来的镜像存储在哪里呢?这里做下记录: 此处docker 版本为:Docker version 1.13.1 1. 进入docker目录,如下: root@iZuf6axmuekh1n14dwcufmZ:/# cd var/lib/docker/ root@iZuf6axmuekh1n14dwcufmZ:/var/lib/docker# ls aufs co

  • 修改Docker镜像默认存储位置的方法(解决方法)

    由于系统初始分区的原因,导致操作系统中对应 / 分区不会太大,通过 /var 目录不会单独分区.如果上面运行 Docker 服务,经过长时间的使用,会使原本就比较大的分区越来越不够用.如何更好地的处理这个问题呢? 1. 使用软链接 我们知道在操作系统当中,默认情况下 Docker 容器的存放位置在 /var/lib/docker 目录下面,可以通过下面命令查看具体位置. # 默认存放位置 $ sudo docker info | grep "Docker Root Dir" 解决默认存

  • Docker Desktop更改镜像存储位置的实现

    Docker Desktop默认安装在C盘,默认镜像存储位置在 C:\用户\Administrator\AppData\Local\Docker\wsl\ WSL WSL 的全称叫做:Windows Subsystem for Linux,即「适用于 Linux 的 Windows 子系统」,可让开发人员按原样运行 GNU/Linux 环境 – 包括大多数命令行工具.实用工具和应用程序 – 且不会产生传统虚拟机(a traditional virtual machine)或双启动设置开销. Do

  • 详解制作各种docker镜像

    做了一个星期的镜像,收货颇多,现在整理记录下来,当做工作笔记吧.把常用的几个镜像的Dockerfile分享下. 制作基础docker镜像 第一步:设置Docker镜像源 复制代码 代码如下: yum install -y yum-priorities && rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm && rpm --import /etc/pki/rp

  • Docker aufs存储驱动layer、diff、mnt目录的区别介绍

    Docker基础信息 首先,先查询Docker使用的后端存储.使用命令docker info,主要关注Storage Driver相关的部分. $ docker info ... Server Version: 1.12.6 Storage Driver: aufs Root Dir: /var/lib/docker/aufs Backing Filesystem: extfs Dirs: 84 Dirperm1 Supported: true ... 由上可见,Docker的版本是1.12.6

  • Docker 镜像、容器、仓库的概念及应用详解

    Docker 镜像.容器.仓库的概念 Docker镜像 Docker镜像(Image)类似于虚拟机的镜像,可以将他理解为一个面向Docker引擎的只读模板,包含了文件系统. 例如:一个镜像可以完全包含了Ubuntu操作系统环境,可以把它称作一个Ubuntu镜像.镜像也可以安装了Apache应用程序(或其他软件),可以把它称为一个Apache镜像. 镜像是创建Docker容器的基础,通过版本管理和增量的文件系统,Docker提供了一套十分简单的机制来创建和更新现有的镜像.用户可以从网上下载一个已经

  • Docker数据存储总结

    阅读本文前,希望你已经对Volumes,Bind mounts和tmpfs mounts有了初步的了解,具体可以参考以下文章: Docker数据存储之Volumes Docker数据存储之Bind mounts Docker数据存储之tmpfs mounts 下图展示了Volumes,Bind mounts和tmpfs mounts三种存储技术的不同: Volumes的使用场景 在多个容器间共享数据. 无法确保Docker主机一定拥有某个指定的文件夹或目录结构,使用Volumes可以屏蔽这些宿主

  • Docker数据存储之Volumes详解

    默认容器的数据的读写发生在容器的存储层,当容器被删除时其上的数据将会丢失.所以我们应该尽量保证容器存储层不发生写操作,为了实现数据的持久化存储我们需要选择一种方案来保存数据,当前有以下几种方式: Volumes Bind mounts tmpfs mounts 下图展示了这三种技术: Volumes Volumes(数据卷)是一个可供一个或多个容器使用的位于宿主机上特殊目录,它拥有以下特性: 数据卷可以在容器间共享和重用 对数据卷的写入操作,不会对镜像有任何影响 数据卷默认会一直存在,即使容器被

  • Docker镜像分层的原理详解

    base镜像 base镜像有两层含义: 不依赖其他镜像,从scratch构建 其他镜像可以之为基础进行扩展 所以,base镜像一般都是各种Linux发行版本的Docker镜像,比如:Ubuntu,Debian或者CentOS等. base镜像提供的都是最小安装的Linux发行版本. 我们大部分镜像都将是基于base镜像构建的.所以,通常使用的是官方发布的base镜像.可以在docker hub里找到.比如centos:https://hub.docker.com/_/centos 我们可以自己构

随机推荐