Docker镜像的存储机制-低调大师

Docker镜像的存储机制

2017-10-31 537

近几年 Docker 风靡技术圈，不少从业人员都或多或少使用过，也了解如何通过 Dockerfile 构建镜像，从远程镜像仓库拉取自己所需镜像，推送构建好的镜像至远程仓库，根据镜像运行容器等。这个过程十分简单，只需执行 docker build、docker pull、docker push、docker run 等操作即可。但大家是否想过镜像在本地到底是如何存储的?容器又是如何根据镜像启动的?推送镜像至远程镜像仓库时，服务器又是如何存储的呢?下面我们就来简单聊一聊。

Docker 镜像本地存储机制及容器启动原理

Docker 镜像不是一个单一的文件，而是有多层构成。我们可通过 docker images 获取本地的镜像列表及对应的元信息，接着可通过docker history <imageId> 查看某个镜像各层内容及对应大小，每层对应着 Dockerfile 中的一条指令。Docker 镜像默认存储在 /var/lib/docker/<storage-driver>中，可通过 DOCKER_OPTS 或者 docker daemon 运行时指定 --graph= 或 -g 指定。

Docker 使用存储驱动来管理镜像每层内容及可读写的容器层，存储驱动有 DeviceMapper、AUFS、Overlay、Overlay2、Btrfs、ZFS 等，不同的存储驱动实现方式有差异，镜像组织形式可能也稍有不同，但都采用栈式存储，并采用 Copy-on-Write(CoW) 策略。且存储驱动采用热插拔架构，可动态调整。那么，存储驱动那么多，该如何选择合适的呢?大致可从以下几方面考虑：

若内核支持多种存储驱动，且没有显式配置，Docker 会根据它内部设置的优先级来选择。优先级为 AUFS > Btrfs/ZFS > Overlay2 > Overlay > DeviceMapper。若使用 DeviceMapper 的话，在生产环境，一定要选择 direct-lvm, loopback-lvm 性能非常差。
选择会受限于 Docker 版本、操作系统、系统版本等。例如，AUFS 只能用于 Ubuntu 或 Debian 系统，Btrfs 只能用于 SLES (SUSE Linux Enterprise Server, 仅 Docker EE 支持)。
有些存储驱动依赖于后端的文件系统。例如，Btrfs 只能运行于后端文件系统 Btrfs 上。
不同的存储驱动在不同的应用场景下性能不同。例如，AUFS、Overlay、Overlay2 操作在文件级别，内存使用相对更高效，但大文件读写时，容器层会变得很大;DeviceMapper、Btrfs、ZFS 操作在块级别，适合工作在写负载高的场景;容器层数多，且写小文件频繁时，Overlay 效率比 Overlay2 更高;Btrfs、ZFS 更耗内存。

Docker 容器其实是在镜像的最上层加了一层读写层，通常也称为容器层。在运行中的容器里做的所有改动，如写新文件、修改已有文件、删除文件等操作其实都写到了容器层。容器层删除了，最上层的读写层跟着也删除了，改动自然也丢失了。若要持久化这些改动，须通过 docker commit <containerId> [repository[:tag]] 将当前容器保存成为一个新镜像。若想将数据持久化，或是多个容器间共享数据，需将数据存储在 Docker volume 中，并将 volume 挂载到相应容器中。

存储驱动决定了镜像及容器在文件系统中的存储方式及组织形式，下面分别对常见的 AUFS、Overlay 作一简单介绍。

AUFS

AUFS 简介

AUFS 是 Debian (Stretch 之前的版本，Stretch默认采用 Overlay2) 或 Ubuntu 系统上 Docker 的默认存储驱动，也是 Docker 所有存储驱动中最为成熟的。具有启动快，内存、存储使用高效等特点。如果使用的 Linux 内核版本为 4.0 或更高，且使用的是 Docker CE，可考虑使用Overlay2 (比 AUFS 性能更佳)。

配置 AUFS 存储驱动

① 验证内核是否支持 AUFS

$ grep aufs /proc/filesystems
nodev aufs

② 若内核支持，可在 docker 启动时通过指定参数 --storage-driver=aufs 选择 AUFS

AUFS 存储驱动工作原理

采用 AUFS 存储驱动时，有关镜像和容器的所有层信息都存储在 /var/lib/docker/aufs/ 目录下，下面有三个子目录：

/diff：每个目录中存储着每层镜像包含的真实内容
/layers：存储有关镜像层组织的元信息，文件内容存储着该镜像的组建镜像列表
/mnt：挂载点信息存储，当创建容器后，mnt 目录下会多出容器对应的层及该容器的 init 层。目录名称与容器 ID 不一致。实际的读写层存储在 /var/lib/docker/aufs/diff，直到容器删除，此读写层才会被清除掉。

采用 AUFS 后容器如何读写文件?

读文件

容器进行读文件操作有以下三种场景：
容器层不存在：要读取的文件在容器层中不存在，存储驱动会从镜像层逐层向下找，多个镜像层中若存在同名文件，上层的有效。
文件只存在容器层：读取容器层文件

容器层与镜像层同时存在：读取容器层文件

修改文件或目录

容器中进行文件的修改同样存在三种场景：

第一次写文件：若待修改的文件在某个镜像层中，AUFS 会先执行 copy_up 操作将文件从只读的镜像层拷贝到可读写的容器层，然后进行修改。在文件非常大的情况下效率比较低下。
删除文件：删除文件时，若文件在镜像层，其实是在容器层创建一个特殊的 writeout 文件，容器层访问不到，并没有实际删掉。

目录重命名：目前 AUFS 还不支持目录重命名。

OverlayFS

OverlayFS 简介

OverlayFS 是一种类似 AUFS 的现代联合文件系统，但实现更简单，性能更优。OverlayFS 严格说来是 Linux 内核的一种文件系统，对应的 Docker 存储驱动为 Overlay 或者 Overlay2，Overlay2 需 Linux 内核 4.0 及以上，Overlay 需内核 3.18 及以上。且目前仅 Docker 社区版支持。条件许可的话，尽量使用 Overlay2，与 Overlay 相比，它的 inode 利用率更高。

容器如何使用 Overlay/Overlay2 读写文件

读文件

读文件存在以下三种场景：

文件不存在容器层：若容器要读的文件不在容器层，会继续从底层的镜像层找
文件仅在容器层：若容器要读的文件在容器层，直接读取，不用在底层的镜像层查找
文件同时在容器层和镜像层：若容器要读的文件在容器层和镜像层中都存在，则从容器层读取

修改文件或目录

写文件存在以下三种场景：

首次写文件：若要写的文件位于镜像层中，则执行 copy_up 将文件从镜像层拷贝至容器层，然后进行修改，并在容器层保存一份新的。若文件较大，效率较低。OverlayFS 工作在文件级别而不是块级别，这意味着即使对文件稍作修改且文件很大，也须将整个文件拷贝至容器层进行修改。但需注意的是，copy_up 操作仅发生在首次，后续对同一文件进行修改，操作容器层文件即可
删除文件或目录：容器中删除文件或目录时，其实是在容器中创建了一个 writeout 文件，并没有真的删除文件，只是使其对用户不可见
目录重命名：仅当源路径与目标路径都在容器层时，调用 rename(2) 函数才成功，否则返回 EXDEV

远程镜像仓库如何存储镜像?

不少人可能经常使用 Docker，那么有没有思考过镜像推送至远程镜像仓库，是如何保存的呢?Docker 客户端是如何与远程镜像仓库交互的呢?

我们平时本地安装的 Docker 其实包含两部分：docker client 与 docker engine，docker client 与 docker engine 间通过 API 进行通信。Docker engine 提供的 API 大致有认证、容器、镜像、网络、卷、swarm 等，具体调用形式请参考：Docker Engine API(https://docs.docker.com/engine/api/v1.27/#)。

Docker engine 与 registry (即：远程镜像仓库)的通信也有一套完整的 API，大致包含 pull、push 镜像所涉及的认证、授权、镜像存储等相关流程，具体请参考：Registry API(https://github.com/docker/distribution/blob/master/docs/spec/api.md)。目前常用 Registry 版本为 v2，Registry v2 拥有断点续传、并发拉取镜像多层等特点。能并发拉取多层是因为镜像的元信息与镜像层数据分开存储，当 pull 一个镜像时，先进行认证获取到 token 并授权通过，然后获取镜像的 manifest 文件，进行 signature 校验。校验完成后，依据 manifest 里的层信息并发拉取各层。其中 manifest 包含的信息有：仓库名称、tag、镜像层 digest 等，更多，请参考：manifest 格式文档(https://github.com/docker/distribution/blob/master/docs/spec/manifest-v2-1.md)。

各层拉下来后，也会先在本地进行校验，校验算法采用 sha256。Push 过程则先将镜像各层并发推至 Registry，推送完成后，再将镜像的 manifest 推至 Registry。Registry 其实并不负责具体的存储工作，具体存储介质根据使用方来定，Registry 只是提供一套标准的存储驱动接口，具体存储驱动实现由使用方实现。

目前官方 Registry 默认提供的存储驱动包括：微软 Azure、Google gcs、Amazon s3、OpenStack swift、阿里云 OSS、本地存储等。若需要使用自己的对象存储服务，则需要自行实现 registry 存储驱动。网易云目前将镜像存储在自己的对象存储服务 nos 上，故专门针对 nos 实现了一套存储驱动，另外认证服务也对接了网易云认证服务，并结合自身业务实现了一套认证、授权逻辑，并有效地限制了仓库配额。

Registry 干的事情其实很简单，大致可分为：① 读配置 ;② 注册 handler ;③ 监听。本质上 Registry 是个 HTTP 服务，启动后，监听在配置文件设定的某端口上。当 http 请求过来后，便会触发之前注册过的 Handler。Handler 包含 manifest、tag、blob、blob-upload、blob-upload-chunk、catalog 等六类，具体请可参考 Registry 源码： /registry/handlers/app.go:92。配置文件包含监听端口、auth 地址、存储驱动信息、回调通知等。

原文发布时间为：2017-10-12

本文作者：姜政冬

本文来自云栖社区合作伙伴“51CTO”，了解相关信息可以关注。

微信关注我们

原文链接：https://yq.aliyun.com/articles/241428

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

浅谈：物联网、云计算、大数据、人工智能怎么区分与彼此关系？

一、物联网 1、什么是物联网? 物联网在之前被定义为通过射频识别(RFID)、红外线感应器、全球定位系统、激光扫描器、气体感应器等信息传感设备按约定的协议把任何物品与互联网连接起来进行信息交换，以实现智能化识别、定位、跟踪、监控和管理的一种网络，简言之物联网就是“物物相连的互联网”。后来被重新定义为当下几乎所有技术与计算机、互联网技术的结合，实现物体与物体之间：环境以及状态信息实时的实时共享以及智能化的收集、传递、处理、执行。广义上说，当下涉及的信息技术的应用，都可以纳入物联网的范畴。 2、物联网的关键技术传感器技术：这也是计算机应用中的关键技术。大家都知道，到目前为止绝大部分计算机处理的都是数字信号。自从有计算机以来就需要传感器把模拟信号转换成数字信号计算机才能处理。 RFID标签：也是一种传感器技术，RFID技术是融合了无线射频技术和嵌入式技术为一体的综合技术，RFID在自动识别、物品物流管理有着广阔的应用前景。嵌入式系统技术：是综合了计算机软硬件、传感器技术、集成电路技术、电子应用技术为一体的复杂技术。经过几十年的演变，以嵌入式系统为特征的智能终端产品随处可见;小到人们身边...

2017-11-01

494

过去几年间，大量家用血糖仪、血压计、手环等设备已经进入普通人生活，收集了大量数据。而医院也意识到医疗数据的价值，纷纷开始把医疗数据“上云”(存入云存储器中)，云计算的能力升级也让以前耗时费力的数据处理变得更容易。而以深度学习为代表的新一代人工智能技术对医疗影像、医疗数据的处理能力也有了很大变化。人工智能医疗不过，更完善的医疗数据获取和利用并非一帆风顺，不少医疗机构和医药公司在探索AI+医疗的过程中都走过一些弯路。目前，AI+医疗最大的问题在于数据的来源和质量，因为中国的医疗数据在医院和医院之间，医院和家庭之间往往存在信息孤岛，即使在同一个医院内部，要提取和利用数据还是涉及很多手工操作。举个很简单的例子，虽然现在信息技术已经非常普及了，但住院查房时，还是大主任在前面查，后面的人录音下来，整理录入系统。在朗锐慧康看来（www.lrioh.com），这种手工产生的数据，质量上存在比较大的问题。不同的疾病和临床检验会产生不同的数据，如果没有经过标准化和结构化的处理就将其提供给算法，会带来很严重的问题。根据观察，很多医疗数据还没结构化和标准化是AI在健康医疗领域应用的最大瓶颈。朗锐慧...

2017-11-01

519

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。