作者： 鲍江南
引言
在 2021 年四月左右，我有幸在 sealer 启动初期理解到其相干工作，并且不久后就作为初始的几位开发同学之一，退出到了 sealer 的开发工作中。
本文，我将回顾集体参加 sealer 开源我的项目的机缘巧合，参加过程中的挑战，以及从中获取的所悟所感，写下一段文字进行分享，心愿对开源新人有所帮忙，可能激励想参加开源工作但还未踏出第一步的同学。
个人简介
各位读者好，本文是我公布到阿里云的第一篇文章，所以我先简略进行下自我介绍。
我是鲍江南，是 sealer [ 1] 的 maintainer。本科毕业于中南大学图灵班。现就读于浙江大学，是 SEL 实验室的一名硕士研究生。目前次要钻研方向是混部集群调度。
GitHub: https://github.com/justadogis…
旅途的开始
刚开始研究生生存的我，他人看来可能是踌躇满志、蓄势待发，但过后的我有种莫名的焦虑与迷茫。读研时，我的实验室是浙江大学的 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: 此处含有隐藏内容，需要正确输入密码后可见！
代码块 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/s…
[2] Enable engine to mirror private registry：
https://github.com/moby/moby/…
[3] moby：
https://github.com/moby/moby
[4] distribution：
https://github.com/distributi…
[5] cri-resource-manager：
https://github.com/intel/cri-…
[6] Intel Resource Director Technology：
https://www.intel.com/content…
[7] openyurt：
https://github.com/openyurtio…
[8] sealos：
https://github.com/labring/se…
点击“此处”，立刻理解 sealer 我的项目！