引言

在 2021 年四月左右，我有幸在 sealer 启动初期了解到其相关工作，并且不久后就作为初始的几位开发同学之一，加入到了 sealer 的开发工作中。

本文，我将回顾个人参与 sealer 开源项目的机缘巧合，参与过程中的挑战，以及从中获取的所悟所感，写下一段文字进行分享，希望对开源新人有所帮助，能够激励想参与开源工作但还未踏出第一步的同学。

个人简介

各位读者好，本文是我发布到阿里云的第一篇文章，所以我先简单进行下自我介绍。

我是鲍江南，是 sealer[1] 的 maintainer。本科毕业于中南大学图灵班。现就读于浙江大学，是 SEL 实验室的一名硕士研究生。目前主要研究方向是混部集群调度。

GitHub: https://github.com/justadogistaken

旅途的开始

刚开始研究生生活的我，别人看来可能是踌躇满志、蓄势待发，但当时的我有种莫名的焦虑与迷茫。读研时，我的实验室是浙江大学的 SEL 实验，主要的研究领域是云计算，因此在云计算工业界，我们有众多的师兄师姐们。当时我来到了一家高新科技云计算公司“谐云科技”担任云原生研发实习生，谐云科技与阿里云有众多前沿云原生合作项目，核心团队成员来自于浙大 SEL 实验室。在机缘巧合之下，我进入了谐云&阿里云云原生项目组，认识了在阿里云云原生团队的实验室师兄-孙宏亮，又通过他，认识了 sealer 的发起人-方海涛。他们都有很丰富的开源经历。在闲聊时，得知宏亮师兄曾经是 Docker 的 maintainer 时，我视宏亮师兄为标杆，作为我努力的方向，这应该是多数人确立目标的方法吧。其中有一段对话令我印象深刻，师兄问过我“今年（2021）最想做到的事是什么？”，我的回答是“在开源方面留下一些痕迹（其实在当时，我自己并未想清楚做开源是为什么）“。现在想来，可能就是”焦虑“+”个人规划不清晰”产生的“病急乱投医”的简单想法。但不管如何，当时也给自己定下了初步的目标，我就抱着 “Make it happen” 的态度全心地投入了。

大概在 2021 年 4 月的时候，我加入了 sealer 开源团队，与几位同学着力于开发 sealer（当初叫集群镜像）的核心能力。

责任与挑战

sealer 是一款由阿里云开源的云原生工具，旨在帮助分布式软件进行更好的封装、分发与运行。如今，由于其设计理念的新颖，行业用户基数的增长，sealer 已经捐给 CNCF 基金会，成为一个 CNCF的 sandbox 项目，朝着更广阔的行业标准迈进。

软件诞生之初，往往是混沌伴随着希望。大目标的背后，需要 sealer 团队解决太多的技术问题，如用户接口、镜像格式、分发模式、运行效率，软件架构等等。最初的 sealer 开发分工中，我主要负责的部分是镜像模块，包含集群镜像缓存、集群依赖容器镜像缓存、集群镜像共享等能力。

集群镜像缓存：如何通过集群镜像层的复用，大幅提供镜像构建效率。如 docker build，每次 build 会首先查找之前本地缓存的镜像 build 内容，复用 build cache，减少硬盘占用与提升镜像构建效率。

集群依赖容器镜像缓存：如何将集群依赖的所有容器镜像，在用户无感知的情况下进行缓存。早期， sealer build 构建集群镜像时，需要真实拉起集群，待所有负载正常启动后，再打包集群镜像。其中，很重要的一个部分是缓存所有该集群依赖的容器镜像，使其可打包。

集群镜像共享：任何人都可以如同使用 docker 工具使用 sealer，push/pull/save/load 等方式共享集群镜像。

第一个技术挑战

在 sealer 的众多挑战中，我印象比较深刻的是集群依赖容器镜像缓存与私有仓库的容器镜像代理；记得是海涛哥找到我，说想让我负责 sealer 的一个核心功能，即 “sealer 如何支持在构建过程中，在用户无需提供额外信息，用户无感知的情况下，缓存所有在构建过程中拉取的所有容器镜像”。下面先简单介绍下相关背景。

• 为何 sealer 需要缓存集群依赖的所有容器镜像？

docker 容器镜像会打包一个应用所需的文件系统/配置信息等，借助虚拟化技术，使得 docker run 可以在任何环境下直接运行，即使在与外网隔离的情况下（应用本身无访问外网的逻辑）。sealer 致力于定义集群交付的标准，同样也需要解决外网隔离镜像拉取的问题，尤其是专有云交付场景，这是刚需。而这些应用容器镜像就是 sealer 集群镜像所需文件系统的一部分。解决这个问题有很多方法，比如最简单的方法是：让用户填写，然后统一拉取后，进行打包；但是海涛哥与我都认为这样不够 user-friendly 与优雅，使用 sealer 的用户应该都是“懒人”，烦于做这些琐碎的事情。那么就让我们为用户做了这些繁琐的事情吧。

• 为何 sealer 要解决私有仓库的容器镜像代理？

docker 社区中有一个2015年 open 的 issue[2]，该 issue 是请求在 docker daemon 配置中，支持私有镜像仓库的镜像代理，但至今社区都未解决该问题，该问题直观描述如图 1 所示：

图 1 原生 docker 的镜像代理逻辑

sealer 在镜像构建阶段，会将该集群需要的所有容器镜像缓存到本地 registry 中，随后集群启动后，让 cri 统一从registry 中拉取容器镜像。但是由于 docker 不支持私有仓库的镜像代理配置，导致拉取“example.hub/library/centos (example.hub为除了 dockerhub 以外的任一镜像仓库地址)”时，无法通过 docker daemon 配置 mirror 地址拉取，而是会直接到 “example.hub” 拉取。

但这不是我们期望的，因为我们在构建阶段缓存的容器镜像就是为当前启动阶段准备的，并且在专有云交付场景下，集群网络是与外界隔离的。对于这个问题，我们最初的可选解决思路是使用 K8s 的 webhook 功能，在pod 创建前在所有镜像前缀替换/加上本地 registry 的地址，不过在跟海涛哥讨论后，我们还是认为这样对用户填写的应用 YAML 有所侵入，我们坚持要把这件事做得更加优雅。

为了解决集群依赖容器镜像缓存/私有仓库的容器镜像代理两个问题，我开始了对docker[3] / registry[4] 源码的学习与了解；很快在 docker 源码中定位到 mirror 的配置部分，另外也从官方文档中了解到 registry 本身支持镜像缓存(pull through cache)的能力，如代码块1所示。但是 registry 仅支持单个 remoteurl 的配置，而用户的镜像会来源于多个远程镜像仓库，所以 registry 的原生配置也无法直接使用。

proxy:
  remoteurl: https://registry-1.docker.io
  username: [username]
  password: [password]

代码块 1 registry pull through cache 配置项

既然社区不支持，且 docker 对私有仓库的镜像代理的推进缓慢，我就直接基于社区的现存能力进行增强，并且改动不影响 docker 其他逻辑，仅做一些增量的配置项，使其实现我们需要的功能。

最后我们提供的 docker 与 registry 可支持的能力如图 2 所示。

主要特性是：

• docker 支持任意镜像仓库的镜像代理。
• registry 支持多远程镜像仓库的缓存，并且可以不用任何用户配置，当然用户也可以选择自行配置。

图 2 sealer 增强的 docker/registry 能力示意图

成就感与责任

模糊印象中，在我们将 sealer 开源后的两至三个月，sealer 就迎来了第一个在生产环境落地的用户——政采云。

我的成长经历过程中有几个让我感到十分喜悦的事件，如大四到北京抖音实习——初入大公司的新鲜感，成功推免浙大硕士等；比较近的就是我们的开源工具有了第一个愿意在生产环境落地的客户，这说明我们做的工作得到了别人的认可，而其中很大一部分工作，是我投入心血思考做出来的，让我特有成就感。

不过，随着外界对 sealer 纷至沓来的关注度，我所需要承担的责任也越来越大。以前写软件，往往只关心功能，能运行即可；现在做 sealer 的开源，需要关心的技术多太多，比如：如何优雅的评判与实现开源用户的需求；如何设计好的架构，支撑 sealer 可持续发展；如何分配精力完成 sealer 的软件质量等等。而提升这方面最直接的方式就是向优秀的项目学习，那段时间应该是我学习效率最高的一段时间，大量地阅读 docker/registry 的源码；从 docker 学来的其中一个部分是代码功能模块化；在最初的 sealer 开发阶段，总共只有几个开发者，为了更快地迭代，大家对底层依赖的文件，元数据信息都是自己写一个工具类，但是每个人负责的模块有所区别，依赖的元数据/文件在持续迭代过程中极有可能发生变化，这就存在较大隐患。

因为偷师了一段时间的 docker 代码，我决定从某个版本开始，将所有镜像相关的操作全部收敛到镜像模块，提供接口给别的模块，在下层依赖文件等操作，又继续抽象出一层文件系统模块；通过此次部分模块的重构，我们的代码比之前更加整洁，且降低了其他同学误操作底层文件问题的风险。

政采云使用 sealer 落地实践的过程中，帮我们发现了许多的问题，还记得那段时间频繁地与现在 sealer 的另一位 maintainer 摩羯沟通问题，解决问题。印象很深刻的是，当时去武汉华科大找女朋友，出于对 sealer 第一个客户的负责，在华中科技大学的咖啡厅/图书馆/校史室里一一解决摩羯在社区提出的 issue。

收获与思考

自信：我相信多数人在遇到挫折与困难时，都会告诉自己“我曾经做成了什么”，让自己坚持下去吧。

开放与沟通：在做 sealer 的过程中，其实有很多设计都是参考于 docker，但仍然还是会有疑惑；那段时间，我会频繁地与社区同学沟通，指的不单是 sealer 社区，是整个开源社区；当初在镜像压缩时遇到一些问题，思考许久没有结论，随后写了一封邮件问了 tar-split 的作者 vbatts，顺利解决了疑惑。我认为沟通是工作最重要的能力之一，充分沟通往往能解决很多问题，避免大量无用功。

去开源崇拜：在前文“旅途的开始”，我提到了我对 2021 年的期望是在开源留下痕迹，但是其实我当时并不清晰，为什么是在开源留下痕迹。可能是为了所谓的 reputation。在我较为完整地参与完一个开源项目之后，发现迷信开源贡献，收获所谓的 reputation 其实毫无意义。一定要做自己认可，有价值的事情，其他的并不重要。

不断学习：文中提及的主要挑战私有仓库的容器镜像代理，当时解决了这个问题让我颇有成就感，过程中也学到了很多东西。不过现在回过头看还是存在一些不可忽略的缺陷，比如必须使用 sealer 专供的 docker，这其实是一个比较重的行为，虽然我们把这个组件作为 sealer 的 rootFS 好像也合理，但这样的话我们就需要提供大部分版本的 docker，并及时 track 上游社区版本变化。所以现在来审视当时的解决方案，其实并算不上优雅。最近在逛社区的时候，看到一个名为 intel/cri-resource-manager[5] 的工具，我猜测该工具出现的背景是 docker/K8s 社区接入 rdt[6] 等技术过于缓慢，所以 intel 开发了一个插件，垫在 kubelet 与 cri 之间，以无侵入的方式为上层 Kubernetes 提供一些容器运行时维度的前沿特性。在学习该项目整体架构后，就想到 sealer 的私有仓库的容器镜像代理也许也可以以无侵入的方法解决。

未来规划

性能提升：持续优化，提高交付效率与稳定性，确保 sealer 能够先在集群交付这个点上做到极致。

架构优化：sealer 目前各子模块较为耦合，新人入手门槛高，难以发展开发者生态，后续我们将致力于抽象各功能模块，让社区参与人员能够更专注在子领域。如 runtime 模块，支持 k0s/k3s 等。

扩大生态：引导社区参与到集群镜像的构建当中，丰富 sealer 的应用生态。

吸收更多开发者：社区需要吸收更多的开发者，壮大社区；同时需要更加简单的 quick start，降低开发门槛。

多社区合作：sealer 社区正在与更多开源社区建立合作，如 openyurt[7]，sealos[8]。以促成多方共赢的局面。

参考链接：

[1] sealer：

https://github.com/sealerio/sealer

[2] Enable engine to mirror private registry：

https://github.com/moby/moby/issues/18818

[3] moby：

https://github.com/moby/moby

[4] distribution：

https://github.com/distribution/distribution

[5] cri-resource-manager：

https://github.com/intel/cri-resource-manager.git

[6] Intel Resource Director Technology：

https://www.intel.com/content/www/us/en/architecture-and-technology/resource-director-technology.html

[7] openyurt：

https://github.com/openyurtio/openyurt

[8] sealos：

https://github.com/labring/sealos

原文链接：http://click.aliyun.com/m/1000347967/

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

    

使用无须实名的阿里云国际版，添加 微信：ksuyun  备注：快速云！