The journey of a sealer maintainer

Introduction: The author of this article will review the coincidences of personal participation in the sealer open source project, the challenges in the process of participation, and the insights gained from it, and write a paragraph to share, hoping to help new open source people and inspire them to participate in open source work Students who have not yet taken the first step.

author:

Bao Jiangnan

introduction

Around April 2021, I was fortunate to learn about sealer's related work at the beginning of its launch, and soon after, I joined the development of sealer as one of the initial development students.

In this article, I will review the coincidences of personal participation in the sealer open source project, the challenges in the process of participation, and the insights gained from it. I will write a paragraph to share, hoping to help new open source people and inspire people who want to participate in open source work. Students who have not yet taken the first step.

Personal profile

Hello readers, this article is the first article I published to Alibaba Cloud, so I will briefly introduce myself first.

I am Bao Jiangnan, the maintainer of sealer[1]. Graduated from the Turing class of Central South University. He is currently studying at Zhejiang University and is a master student in the SEL laboratory. At present, the main research direction is co-located cluster scheduling.

GitHub: github.com/justadogist…

the beginning of the journey

When I first started my postgraduate life, others might seem smug and ready to go, but at that time I was inexplicably anxious and confused. When I was a graduate student, my laboratory was the SEL experiment of Zhejiang University, and the main research field was cloud computing. Therefore, in the cloud computing industry, we have many brothers and sisters. At that time, I came to a high-tech cloud computing company "Harmony Cloud Technology" as a cloud native R&D intern. Harmony Cloud Technology and Alibaba Cloud have many cutting-edge cloud native cooperation projects, and the core team members are from the SEL laboratory of Zhejiang University. By coincidence, I joined the Harmony Cloud & Alibaba Cloud Cloud Native Project Team, and met the lab brother Sun Hongliang, who was in the Alibaba Cloud Cloud Native Team. Through him, I met the founder of sealer, Fang Haitao. They all have a lot of open source experience. While chatting, when I learned that Senior Brother Hongliang used to be the maintainer of Docker, I regarded Senior Brother Hongliang as a benchmark, and as the direction of my efforts, this should be the way most people set their goals. One of the conversations left a deep impression on me. My brother asked me, "What do you want to do most this year (2021)?" My answer was "Leave some traces on open source (actually, at the time, I didn't know what I wanted to do?" Figure out why you are doing open source)”. Now that I think about it, it may be the simple idea of "going to the doctor in a hurry" caused by "anxiety" + "unclear personal planning". But no matter what, I also set a preliminary goal for myself at that time, and I devoted myself wholeheartedly with the attitude of "Make it happen".

Around April 2021, I joined the sealer open source team and focused on developing the core capabilities of sealer (originally called cluster mirroring) with several classmates.

Responsibilities and Challenges

sealer is a cloud-native tool open sourced by Alibaba Cloud, which aims to help distributed software to better encapsulate, distribute and run. Today, due to its novel design concept and the growth of the industry user base, sealer has been donated to the CNCF Foundation and has become a CNCF sandbox project, moving towards a broader industry standard.

At the beginning of software, there is often chaos accompanied by hope. Behind the big goal, the sealer team needs to solve too many technical problems, such as user interface, image format, distribution mode, operating efficiency, software architecture and so on. In the initial division of sealer development, I was mainly responsible for the image module, including cluster image cache, cluster-dependent container image cache, cluster image sharing and other capabilities.

集群镜像缓存：如何通过集群镜像层的复用，大幅提供镜像构建效率。如 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 的私有仓库的容器镜像代理也许也可以以无侵入的方法解决。