systemd-nspawn与archlinux ci

2019-07-29 10:49:35

       TL,DR; 你想要部署单一的应用,docker;你想要一个完整的(能跑底裤的…)容器,systemd-nspawn。想要个ci,TeamCity。

       近日开始在aur上维护软件包,也搭建了自己的personal repo,软件包的持续构建成为了一大难题。我个人之前一直在使用openSUSE的obs,但由于obs的限制(没有网络连接),与它难看的界面(现在好像换新版了?),最终还是放弃了用obs打arch包的想法。故而我开始寻找其他的ci平台。开始时我尝试了jenkins与gitlab ci,但两者都存在一个很大的问题(其实是feature),configuration as code,对于自己的项目而言,在代码中混入一些ci的配置文件无伤大雅,但aur的仓库中塞个Jenkinsfile,总感觉有些怪怪的,相对而言,我更想要的是一个“detached ci”,一种非侵入式的解决方案。最终,我发现了TeamCity(果然还是喷气脑子最懂开发者想要什么),虽然free license有一定的限制,但个人也够用。

       有了合适的ci,接下来遇到的问题就是构建环境。开始时,我选择了docker。docker作为流行的容器运行时,在各大平台上都有支援,也有效消除了host system的差异,但docker的存在本身,强调的是应用而非系统,正如官方所推荐的:每一个docker容器里只应运行一个进程,换言之,没打算让你跑底裤…..为什么构建软件包一定要跑底裤呢?其实是不必要的,我为了省事,直接使用了由devtools提供的extra-x86_64-build用于构建,而这一构建脚本会在每次构建时建立新的chroot环境,docker容器中无法chroot的问题使用privileged选项解决了(虽然不安全….),但构建时仍出现了其他的底裤相关问题,导致构建无法完成。由于构建服务器是白嫖的Azure,kvm等虚拟化方案自是不加入考量,容器的解决方案又是大同小异,唯独systemd-nspawn格外特别。

       systemd-nspawn - Spawn a command or OS in a light-weight container — man pages中如是写到。相比于docker对于应用的关注,nspawn更加偏向系统,一个b选项即可启动又一个systemd实例(蛤!双层底裤!)唯一的问题在于没有现成的image,而这也用pacstrap简单解决。最像虚拟机的容器,最优雅的解决方案,如果要我用一句话概括systemd-nspawn的话我大概会这样说。

       总而言之,如果你想试试一个全新的发行版(比如arch (笑)),不妨给systemd-nspawn一个机会,如果想要搭建自己的archlinux ci,它也会是不错的选择。(当然vps2arch也很赞!)