简介： 常言道，startup 有 startup 的好，大厂有大厂的好，那么大厂究竟好在哪呢？拿硅谷老牌大厂们 FLG 来说，如果要问最令人怀念的是什么？Free food 和基础设施(Infrastructure)一定是会上榜的，两者均极大提升了广大应用开发者的幸福指数。那么能不能“让天下没有难做的应用”呢？请大家把目光投向正在兴起的云原生生态。

 

前言

常言道，startup 有 startup 的好，大厂有大厂的好，那么大厂究竟好在哪呢？拿硅谷老牌大厂们 FLG 来说，如果要问最令人怀念的是什么？Free food 和基础设施(Infrastructure)一定是会上榜的，两者均极大提升了广大应用开发者的幸福指数。那么能不能“让天下没有难做的应用”呢？请大家把目光投向正在兴起的云原生生态。

在云原生生态中，容器服务包括了镜像和容器引擎两个部分。其中容器镜像作为核心的云原生应用制品，打包了完整的操作系统和应用运行环境，应用的迭代也因为使用了这种不可变架构而变得更简单，更频繁。

本文将围绕着容器镜像这一核心，分享它的相关知识和业界的思考与实践。

容器镜像的概念

1）容器镜像

容器镜像有一个官方的类比，"生活中常见的集装箱"，虽然拥有不同的规格，但箱子本身是不可变的（Immutable），只是其中装的内容不同。

对于镜像来说，不变的部分包含了运行一个应用软件（如 mysql）所需要的所有元素。开发者可以使用一些工具（如 Dockerfile）构建出自己的容器镜像，签名并上传到互联网上，然后需要运行这些软件的人可以通过指定名称（如 example.com/my-app）下载、验证和运行这些容器。

2）OCI 标准镜像规范

在 OCI 标准镜像规范出台之前，其实有两套广泛使用的镜像规范，分别是 appc 和 docker v2.2，但“合久必分，分久必合”，有意思的是两者的内容已经在各自的发展中逐步同化了，所以 OCI 组织顺水推舟地在 docker v2.2 的基础上推出了 oci image format spec，规定了对于符合规范的镜像，允许开发者只要对容器打包和签名一次，就可以在所有的容器引擎上运行该容器。

这份规范给出了 OCI image 的定义：

This specification defines an OCI Image, consisting of a manifest, 
an image index (optional), a set of filesystem layers, and a configuration.

3）容器的工作流程

一个典型的容器工作流程是从由 developers 制作容器镜像开始的（build），然后上传到镜像存储中心（ship），最后部署在集群中（run）。

容器镜像技术发展中遇到的问题

不得不说，容器镜像的设计是很出彩的，首先它蕴含了“完整的操作系统就是一个包”的优秀思想，带着大家跳出了安装包的思路，又提出了诸如 dockerfile 这样的提升开发者体验的 killer features，还能利用分层结构来节约时间空间。

不过，"金无足赤，人无完人"，优秀的设计并不等于优秀的实践，下面来聊一聊问题具体出在哪。

1. 容器镜像使用者

1）问题一：启动容器慢

容器启动慢的情况普遍发生在当用户启动一个很大 size 的容器镜像时，由于在容器准备阶段需要三步（以 overlayfs 为例）：

• download 镜像。

• unpack 镜像。

• 使用 overlayfs 将容器可写层和镜像中的只读层聚合起来提供容器运行环境。

其中，download 镜像时需要 download 整个镜像，不能实现文件数据按需加载。再加上 download 镜像本身受限于网络带宽的影响，当容器镜像 size 在到几个 G 时，下载时间会较长，破坏了容器原本优秀的用户体验。

2）问题二：较高的本地存储成本

不同镜像之间可以共享的最小单位是镜像中的层，它的缺点之一是在 deduplication 上的效率是较低的，原因是：

• 首先，层内部存在重复的数据。

• 其次，层与层之间可能存在大量重复的数据，但即使有微小的差别，也会被作为不同的层。

• 再次，根据 OCI image spec 对删除文件和 hardlink 的设计，一个镜像内部可能存在已经被上层删除的文件仍然存在于下层中，并包含在镜像中。

所以，当不同镜像的容器被调度到同一台机器上运行时，镜像本身在本地文件系统中所占的存储空间是一笔不可忽视的成本开销。

2. 镜像提供者侧

这里的提供者主要指容器服务的镜像中心。

1）问题一：巨大的存储浪费

• 存在大量相似镜像 造成这种情况有两个原因：

  • 首先，上面提到的层的缺点，在容器镜像中心会产生许多相似镜像。

  • 其次，OCI image 使用了 tar+gzip 格式来表达镜像中的层，而 tar 格式并不区分 tar archive entries ordering，这带来一个问题，即如果用户在不同机器上 build 去同一个镜像，最终可能会因为使用了不同的文件系统而得到不同的镜像，然后用户上传之后，镜像中心中会存在若干不同镜像的实质内容是完全相同的情况。

• 镜像去重效率低：虽然镜像中心有垃圾回收来实现去重功能，但其仍然以层为单位，所以只能在有完全相同 hash value 的层之间去重。

2）问题二：云原生软件供应链带来的新需求

随着时间推移，和软件供应链一起发展的还有对软件供应链环节的多样性攻击手段。安全防护是软件供应链中非常重要的组成，不光体现在对软件本身的安全增强，也体现在对供应链本身的安全增强。而因为应用运行环境被前置到了容器镜像中，所以对容器镜像的安全，包括对镜像的漏洞扫描和签名成为了容器服务提供者的必要能力。

对容器镜像的思考和讨论

1. 业界的尝试

针对前面所述的问题，业界大小厂也是集思广益，各显神通，下面提几个典型的项目：

1）CernVM-FS

使用了 fuse 按需从远程加载需要的数据。

2）Slacker

通过设计一个镜像的 benchmark 贡献了几个有意思的理论基础：

• 事实上，容器启动时间很长。

• 启动时数据读写放大系数很大（启动时中只使用 6% 的数据）。

• 分析了 57 个 docker image 的 layer 数量，发现一半以上的 image 的 layer 数量大于 9。

Slacker 最终使用了按需加载和减少镜像层数将启动速度提高了 5-20 倍。

3）SquashFs

Oracle 使用 Linux SquashFS 来替代 targz 存储容器 image layer 的内容，去掉了 unpack tar 的环节。

2. OCI 社区中的讨论

自 2019 年开始，对于镜像本身的吐槽慢慢多了起来，发酵了一年多，OCI 社区觉得时机成熟了，从 2020 年 6 月开始，花了一个多月时间密集讨论了当前 OCI 镜像规范的缺陷，以及 OCIv2 镜像格式（*）需要满足哪些要求。

（*）OCIv2 在这里只是一个宣传命名，实际上 OCIv2 是当前 OCI 镜像规范的改进，而不会是一个全新的镜像规范。

1）OCI 镜像规范的缺陷

经过讨论得出目前的缺陷主要有两点：

• tar 格式标准

  • tar 格式并不区分 tar archive entries ordering，这带来一个问题，即如果用户在不同机器上去 build 同一个镜像，最终可能会因为使用了不同的文件系统而得到不同的镜像，比如在文件系统 A 上的 order 是 foo 在 bar 之前进入 tar，在文件系统 B 上的 order 是 bar 在 foo 之前进入 tar，那么这两个镜像是不同的。
  • 当 tar 被 gzip 压缩过之后不支持 seek，导致 run container 之前必须先下载并解压 targz 的 image layers，而不能实现文件数据按需加载。

• 以层为镜像的基本单位

  • 内容冗余：不同层之间相同信息在传输和存储时都是冗余内容，在不读取内容的时候无法判断到这些冗余的存在。
  • 无法并行：单一层是一个整体，对同一个层既无法并行传输，也不能并行提取。
  • 无法进行小块数据的校验，只有完整的层下载完成之后，才能对整个层的数据做完整性校验。
  • 其他一些问题：比如，跨层数据删除难以完美处理。

2）下一代镜像格式的要求

这次镜像格式大讨论从一个邮件和一份共享文档开始，并促成了多次在线的 OCI 社区讨论会议。最后的结论也很鼓舞人心，在这份共享文档中可以找到对 OCIv2 镜像格式需要满足的要求的详细描述。我们可以将这些要求分类为：

（*）: 诸如 file timestamp 等只在一个特定机器上有意义的 metadata 是没有必要存在于镜像中的。

可以看出，上面这些要求明确了容器镜像的下一步重点在易用、效率、安全三个方面，达到在 "build - ship - run" 这三个阶段协同优化的目的。

3. 阿里云在容器镜像上的思考

阿里云一直积极地推动和发展云原生生态，提供了基础设施“阿里云容器镜像服务（ACR）”作为用户云原生容器化的第一站，负责提供容器镜像、Helm Chart 等 OCI Artifacts 管理和分发服务。同时我们也在结合容器业务现状深化对容器镜像格式的理解，不断地总结什么是满足发展需求的容器镜像格式，这里可以概括为以下几点，新的镜像格式需要：

• 满足容器 "build once, run anywhere" 的理念。
• 实现在镜像中心和容器运行结点上存储资源上的高效使用。
• 在容器镜像的全链路上（build, ship, run）比现有的 OCI 镜像格式速度更快。
• 能够扩展在安全上的能力。
• 最大程度兼容已有基础设施，普惠大多数用户。

阿里云沙箱容器的镜像加速

相比于社区的讨论重点放在了新的镜像格式的设计上，阿里云更关心如何设计出一套优化全链路的镜像方案，为客户带来能够应用在生产中的价值。

在明确以上在技术发展过程中产生的需求之后，我们为阿里云沙箱容器设计了新的镜像格式 Rafs，并为 CNCF 下的 Dragonfly 项目引入了容器镜像服务，它能够极大缩短镜像下载时间，并提供端到端的镜像数据一致性校验，从而让用户能够更安全快捷地管理容器应用。

1. Rafs: 镜像格式

Rafs 把一个容器镜像只分成元数据和数据两层。其中：

• 元数据层：元数据层是一颗自校验的哈希树。每个文件和目录都是哈希树中的一个附带哈希值的节点。一个文件节点的哈希值是由文件的数据确定，一个目录节点的哈希值则是由该目录下所有文件和目录的哈希值确定。
• 数据层：每个文件的数据被按照固定大小切片并保存到数据层中。数据切片可以在不同文件以及不同镜像中的不同文件共享。

2. Nydus: Dragonfly 的容器镜像服务

除了使用上面的镜像格式 Rafs，Nydus 还包含一个负责解析容器镜像的 FUSE 用户态文件系统进程。

nydus 能够解析 FUSE 或者 virtiofs 协议来支持传统的 runC 容器或者阿里云沙箱容器。容器仓库、OSS 对象存储、NAS、以及 Dragonfly 的超级节点和 peer 节点都可以作为 nydus 的镜像数据源。同时，nydus 还可以配置一个本地缓存，从而避免每次启动都从远端数据源拉取数据。

基于这个设计架构，nydus 分别在 build, ship, run 和兼容性方面提供下面这些优化：

3. 为什么选择基于文件的设计

在设计之初，Nydus 选择了基于文件的设计而不是基于块的设计，为什么这样做呢？

主要的原因是，我们想在镜像加速的基础上做基于容器特点的附加能力，这一切都建立在能够获取到镜像中的文件元数据；而基于块的设计只使用 disk LBA，天然的无法获取其上层（即文件系统）中的信息。

有了文件元数据之后，我们轻松地实现了以下几个增值功能：

• 镜像优化建议：在 build container 环节，提示用户有哪些文件是根本没有访问过的，可以考虑借此来优化镜像。
• 预读：在 run container 环节预加载，猜到用户要读文件，那就预先在读操作发生之前送过去，从而优化访问速度。
• 安全审计：在 run container 环节，如果一个容器访问镜像内容的模式和其他容器产生了明显差异，那么，这有可能是一个安全性风险。
• 变更风险发现：在 run container 环节，如果一个镜像升级之后，发现它访问内容的模式和之前发生了明显差异，那么，要么是程序自己有意变了，要么就可能是引入 bug 了，这时可以考虑提醒开发者这个变化。

总结

OCI image 分层镜像机制虽然极大地方便了开发，但在大规模集群运行时，也有颇多不足，对此，OCI 镜像社区也在寻求着如何利用镜像内容可感知性，让它更加快速、节省资源，也更加安全。阿里云在这个基础上本着为客户带来价值的原则，提出了公有云上对镜像的稳定性、预读等需求，并为阿里云沙箱容器研发出了相应的的镜像加速方案，实现 "build-ship-run" 整个镜像链路上的统一优化，让用户不光听着热闹，也能用着开心，切实得到云原生基础设施发展的红利。

作者：Liu,Bo

原文链接 

本文为阿里云原创内容，未经允许不得转载