欢迎大家来到IT世界,在知识的湖畔探索吧!

简介： 常言道，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.

欢迎大家来到IT世界,在知识的湖畔探索吧!

3）容器的工作流程

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

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

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

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

1. 容器镜像使用者

1）问题一：启动容器慢

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

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

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

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

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

2. 镜像提供者侧

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

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

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

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

对容器镜像的思考和讨论

1. 业界的尝试

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

1）CernVM-FS

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

2）Slacker

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

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 镜像规范的缺陷

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

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

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

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

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

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

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

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

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

在明确以上在技术发展过程中产生的需求之后，我们为阿里云沙箱容器设计了新的镜像格式 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，天然的无法获取其上层（即文件系统）中的信息。

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

总结

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

作者：Liu,Bo

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