maintainer？的心路历程

很多朋友对于maintainer和的心路历程不太懂，今天就由小编来为大家分享，希望可以帮助到大家，下面一起来看看吧！

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

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

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

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

GitHub:https://github.com/justadogistaken

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

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

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

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

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

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

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

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

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

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

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

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

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

proxy:\nremoteurl:https://registry-1.docker.io\nusername:[username]\npassword:[password]

代码块1registrypullthroughcache配置项

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

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

图2sealer增强的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的应用生态。

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

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

https://github.com/sealerio/sealer

[2]Enableenginetomirrorprivateregistry：

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

https://github.com/distribution/distribution

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

[6]IntelResourceDirectorTechnology：

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

https://github.com/openyurtio/openyurt

https://github.com/labring/sealos

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

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

关于本次maintainer和的心路历程的问题分享到这里就结束了，如果解决了您的问题，我们非常高兴。