Nichi Yorozuya

Arch CI Project

       Arch一直没有很好的自动化构建系统呢。虽然cn源有Lilac(勤奋工作的妹子呢),但是主要构建工作还是人工进行的,三只肥猫猫拼一桌的来着。想比之下,Fedora有Copr,openSUSE有OBS,都承担了大量自动化工作,极大降低了维护成本。我也曾经尝试过使用OBS构建Arch软件包,但是由于OBS的构建环境没有互联网连接,而大量Arch包的构建均依赖网络,只能说是失败的尝试。而Lilac,更加适合的是Archcn社区这种中心化的打包环境,不太方便self-host,(也不符合我对于一个cloud native system的期待呢)故而我开始了Arch CI Project的开发。

       与其说这是一个新的想法,不如说之前我也有做过相关方面的开发工作:众所周知,devtools只能在Arch上面跑,虽然可以用nspawn等套娃,在非Arch发行版上的构建始终是痛苦的体验,故而我之前的主要方向是在docker中重现devtools的chroot环境。但值得称为“CI”,只是build这一步显然是不够的。要说还有什么missing part的话,就是job和database的生成了。job的生成可以重用Lilac/nvchecker的代码,而database的生成则是件有意思的事。

       Arch的repo database似乎并无specification,毕竟它也简单到了无需spec的程度,通过对repo-add的一些分析我发现了以下几点:每个包的操作是独立的,同个包的不同版本理论上可以共存在同一个数据库中,但是pacman会懵,包的签名数据也完整存在于数据库中(.sig文件其实并非必须,pacman -U时除外)。由此我在build与database generation之间加了一个stage: metadata generation,生成对应包在数据库中的项,这样一来,database generation实际就变成了database aggregation,只是将多个目录打成tar而已。

       狐了这么多话,那我到底狐了啥呢? a set of images, a set of controllers,配合nats作为组件间通信和minio作为持久化存储,得到了一个能用的CI系统。但是在开发过程中我也意识到了许多现实问题,不管是scalability,security还是robustness,重复造轮子的代价也正在于此,也因此,我放缓了Arch CI的开发,(其实只是咕咕咕),决定看看Jenkins X,(这个不是Java写的。

       下面的内容与标题无关:
       我也有一直在折腾overlay network,之前的话无脑上weave,最近benchmark下来直连性能非常不错,转发一团糟。官方文档中说直连下是Open vSwitch Datapath配上VXLAN,而转发则是私有的UDP封包。看了一圈,我发现了BGP EVPN的魔法,用BGP分发VTEP配置,非常科学(效果拔群。

January 23, 2020