LWN：可信树Merkle tere在build系统中的应用！

关注了就能看到更多这么棒的文章哦～

Merkle trees and build systems

May 28, 2020 This article was contributed by David Röthlisberger 原文来自：https:/lwn.net/Articles/821367译者：LinuxEverything

传统的build工具，比如make这种，它的语法里面的编译目标（target）以及依赖内容（dependency）都是一个个文件。想想一下，如果你需要拿整个代码树（也就是一个目录里的全部子目录和文件）作为依赖条件，那可就惨了。就像你要编译某个目标文件的时候如果要先指定一个"build root"目录用来编译这个目标所需要的toolchain。反过来也一样，如果有一条规则需要生成build root目录的话，那么整个目录才是它的build target。在一个build系统中优先使用Merkle tress的话就可以提供非常好的扩展性，也带有许多优化机会。本文中我将介绍一下如何在OSTree, Ninja和Python中利用这个条件。

OSTree

OSTree很像Git，只是它存储的是整个文件系统映像，比如说一个完整的Linux系统映像。比起Git来，OSTree会保存它所管理的文件的更多的metadata，比如文件属主，完整的权限位（Git只会记录某个文件的可执行bit），扩展属性位（extended attributes, 即xattrs）。它也跟Git一样不会存储时间戳。OSTree用在Project Atomic/CoreOS的Flatpak、rpm-ostree中，GNOME Continuous也在用，OSTree最开始就是在这里开发出来的。

我本人所在的公司过去4年一直在一些使用Linux的设备上利用OSTree来build和发布软件升级。OSTree也提供了deploy工具，用来分发映像文件到不同的机器上去，可以采用原子操作方式来自动部署或回退映像，也能管理/etc下面的改动，等等。不过本文里面我只会专注于利用OSTree的data model。

OSTree和Git一样，存储文件使用的是一个“Content Addressable Store”，也就是说你只要你知道某个文件内容的校验值，就可以查找到这个文件并读出内容。OSTree利用的是SHA-256，我下面所说的"SHA"和校验值其实都是一回事。这个存储仓库就是文件系统中的一个目录（比如"ostree/"），OSTree所管理的每个文件（类似Git里的blob的概念）都是放在ostree/objects/下面以一个个文件的形式，文件名就是此文件内容的SHA值。这里我的说法只是个简化版的描述，因为文件属主、权限、xattrs也都被包含在校验和的计算中了。

每个目录（tree）会体现为一个文件，此文件的内容是它的子目录和文件的列表，以及它们的SHA值。这个文件的名字也是跟其他blob一样，是其中内容的SHA值。这样一来，整个目录树（包含所有子目录及其中内容和其中所有文件的内容）就可以用一个简单的SHA值来代表了。这个数据结构就称为Merkle tree。

每个目录树也可以有多个版本，就像Git里的commit或者branch的概念，或者干脆就是完全不同的目录树。不过其中公共的文件在OSTree仓库中只会保存一份（上图中file2.txt和d/file3.txt是相同内容，所以它在ostree/objects/下面只有一份）。OSTree也和git一样有commit和checkout操作。

OSTree的"refs"（reference的简称）也跟Git refs类似，是OSTree用来实现branchhe tag的工具。每个ref都是在OSTree仓库中的一个metadata文件，文件名你可以随意取，比如是branch或者tag的名字，而内容就是一个SHA值，指向某个目录树。其实这里并没有直接指向目标，因为这个SHA实际上是一个指向了这个目录的commit的SHA值，不过本文中我就不再提commit这个概念了，因为跟本文主旨无关。

OSTree + Ninja

Ninja是一个类似Make的build system，我3年前在LWN介绍过Ninja。Ninja和Make有个区别是它不支持通配符（wildcards）和循环（loop），因此你需要写一个“configure”脚本来生成Ninja文件（明确列出每个build target）。在本人公司内部的build系统是一个3000行的Python文件，还有几十个YAML文件来指明各个模块的打包指令。运行时Python脚本会生成9万行的Ninja文件。

Ninja里的buld target和input跟Make一样，也是只能是文件。OSTree的refs其实也都是文件。这样如果build系统里面在各个build步骤中都生成一个不同的ref，并把这个ref作为build rule的target就可以了。举例来说，生成的Ninja rule里面可以有一个target是“build/ostree/refs/heads/xyz”这个文件，其中的build/ostree就是"build"输出目录中的OSTree仓库，而xyz就是ref的名字。

下面是build system里面一个实际的例子，可以为Linux设备生成rootfs：

rootfs = ostree_combine([
    l4t_kernel(),
    bionic_userspace(),
    package("a"),
    package("b"),
    container("c"),
])
phony("rootfs", rootfs)
default(rootfs, ...)

l4t_kernel()，bionic_userspace()，package()，container()都是Python函数，用来创建一个OSTree目录树（也许是下载并解开一个tar文件，或者运行一个别的makefile，这里的细节我们就不讨论了），接下来创建一个OSTree的ref来指向这个目录树，把ref（内部生成的一个Python string，例如“build/ostree/refs/heads/package/a”）返回回去。

ostree_combine()这个Python函数会接受若干个OSTree ref（每个都指向一个目录树）并把他们合并成唯一的一个目录树，再创建一个ref来指向它，并把ref返回（这里比如说名为"build/ostree/refs/heads/ostree_combine/c85e333f577b"）。

不过其实上面都是骗你们的～，这些函数并没有做我上面说的这些事情，其实它们真正在做的事情就是写出一条Ninja rule，在后面调用ninja来处理这些rule的时候才会做我刚才说的这些步骤。

调用ninja来做增量编译的时候，假如其中某个input refs变动了（因为每个ref都是指向了一个目录树的SHA，如果其中任何一个文件变化了，那么ref的内容就会变动），Ninja就知道rootfs这个target需要重新生成了，因此它会调用ostree_combine rule。

关键是你都不需要在build脚本里面明确写出那些ref文件的名字。真正到处传递的其实就是一些普通的Python变量，其他函数会利用这些变量，并作为自己的Ninja rule中的依赖项。

上面的例子里，我们还创建了一个Ninja phony rule，用来建立一个最终target name，这样在调用ninja命令的时候就很方便了，并且会把它加入Ninja的default target list中。

Benefits

我们能把整个目录树作为build的dependency或者target，也意味着我们可以把这个机制利用在一些粗粒度的dependency上（比如我们需要把一个第三方package加入rootfs），也能用在一些细粒度的dependency上（逐个指明文件）。有个明显的好处，就是toolchain和build环境可以明确指定并管理起来了：要编译某个target的时候，可以把"build root" rootfs指定为dependency依赖项，chroot到其中来执行编译命令（有些文档里面管这种做法叫做“hermetic builds”）。这个build rotofs本身可以是由其他rule来生成的。

大家可能没有意识到，其实这种方案里面最大的好处，就是能把build过程中的中间输出内容当做变量来传递了。上面的Python代码的例子中，package("a")返回的target name就会被传递到其他rule中，即ostree_combine()。这意味着你不需要为每个中间生成产物都指定一个名字，而是可以自动生成了。这种方式可以让你的build script很清晰，可读性更强。上面这个例子脚本并不是特意设计出来做演示的，它其实跟production build script里面看起来非常类似。只要能把build规则轻松指定出来，今后我们就可以找机会来缓存（cache）或者并行化（parallelize）编译过程。

可以再举一个针对性更强的例子：生成ldconfig cache的规则只要依赖几个目录的内容就好，例如/lib和/usrlib。同样，mandb cache也只一来/usr/share/man目录的内容。

传统的做法会让这些操作都串行起来依次执行。单是如果build系统能定义成依赖前一项的编译target的一个子目录树，那么就可以分离出多个rule来把这些操作并行起来，最后再把结果合并成一个最终的rootfs tree。这个例子中，尽管最终的rootfs SHA会改变，但是/usr/share/man子目录可能并没有变化，这样就不需要重新执行mandb了。上图中红色箭头会更改数据（也就是文件的内容），而绿色箭头会更改OSTree metadata。

更新一下，本段是后来新增的 你可以这么想象一下它的应用场景。如果你有个cloud build系统，可以把各个独立的build步骤都分发到远程的build server上去。那么要执行mandb规则的编译，远端的server不需要把整个rootfs都下载好，而是只需要下载/usr/share/man目录就好。这个步骤的输出内容在最后合并到整个rootfs的时候，只需要改动一下Merkle tree的metadata即可。

OSTree工具可以提供许多优势，你只需要把最终的build产物给export（也就是commit）到OSTree仓库中，就能享受到这些优势。你都不需要把OSTree完整集成到你的编译过程的各个中间步骤中去。这些优势是：

• 改动可见：我的公司中的continuous integration (CI)系统会对每次pull操作都调用一下ostree diff，这样开发人员可以明确看到生成的rootfs中有哪些文件被改动过了。这样我们就可以非常确定我们在增量编译的时候确实正确生成了我们要的文件。

• 快速增量部署：OSTree提供了一些工具来把某个目录整个部署到远端的设备上。这个功能可以用在更新现场设备中的文件的情况下（比如OTA软件升级）。但是这种生产环境中的软件更新流程在交互式开发过程中也非常快，一次增量编译、部署、重启，可以在1分钟内完成。

Implementation details

我们的Python脚本有许多函数来获取file, tar包，Git snapshot，apt包等，可以把它们加入OSTree。每个目录树其实只是一个文件而已，refs的存储代价非常低。

还有许多其他函数是用来操作目录树的，比如上面例子中的ostree_combine()，还有ostree_ln()，ostree_mkdir()，ostree_mv()。这些操作都很快速，因为只是对OSTree metadata进行更改而已。不需要进行ostree checkout来改动目录内容。这里ref可以指向任意的tree，不一定是基于你最终生成的影响文件中的"/"目录的。

在进行编译等动作是，还有个ostree_mod()，会调用某个命令来修改这个目录树。它会先check out这个目录树（可能也需要chroot进去），然后执行某个特定的命令，就可以生成并输出一个新的目录树。例子如下：

ostree_mod(
    input_tree=ostree_combine([build_root, src]),
    command="make -C /src install DESTDIR=/dest",
    chroot=True,
    capture_output_subdir="/dest")

这个步骤中使用了fakeroot和bubblewrap生成沙盒来执行这些命令，这样就不会修改到input tree之外的文件了。Bubblewrap是Red Hat的Project Atomic里面发展出来的一个工具，其他很多地方的Flatpak里面会用到，用来供非特权用户来创建自己的secure sandbox。这里bubblewrap并不是用在security角度的，而是用来确保进行一个正确的hermetic build的便利方式。我们的fakeroot打了许多额外patch让build命令能看到OSTree保存的文件权限信息，这样我们就能以非特权用户的权限来build，同时又能修改那些root用户的文件。

OSTree使用了"bare" repository format，这意味着checkout的时候实际上值需要在本仓库中针对文件创建hard-link就够了。这个动作完成的非常快，因为每个调用了ostree_mod()的build rule都需要进行一次ostree checkout和ostree commit操作。我们也使用了OverlayFS来确保在做hard-link的时候不会不小心改动了OSTree仓库的内容。bubblewrap需要使用这个patch来支持OverlayFS，可惜这个patch可能无法合入bubblewrap项目官方代码里，因为它需要一些额外的capability，跟bubblewrap项目的安全目标是冲突的。还有一些OSTree patch，其中一些已经合入upstream了，有些还没有。

apt2ostree

apt2ostree工具是从我们的build系统中提取出来的。它会根据一个.deb包的列表来编译生成Debian/Ubuntu的rootfs，跟debootstrap和multistrap很像。跟那些工具不同的是它生成的输出内容是一个OSTree tree，而不是普通的目录。这个工具非常快，可以并行化执行，也支持增量执行。它还在某个"lockfile“中记录了package版本信息，确保今后可以重新复现这个build结果。

apt2ostree根据这个.deb包的列表来逐个下载这些deb包，然后解开放置到它自己独立的OSTree tree中，接下来再把这些OSTree目录都合并成为一个统一的目录（这一步等同于debootstrap的stage 1的工作）。接下来，它会check out这个目录，在chroot之后执行dpkg --continue -a（也就是stage 2），把最终结果commit到OSTree中。

apt2ostree会对这些package进行dependency检查（使用aptly工具），然后生成一个包含了所有package的list的"lockfile"，其中记录了每个package的版本信息和SHA值。这个lockfile就可以提交到Git中了。依据这个lockfile来做的后续build都是跟这次build的功能完全一致的。

apt2ostree的stage 1很快，原因是它对那些package进行的下载和解包只需要进行一次就好。如果这个package用在多个映像文件中，就不需要重复进行这个解压缩动作了。这也节省了磁盘空间，因为这些package都被提交到OSTree里面去了，所以多个build image都可以公用公共部分。下载和解压缩是逐个package进行一个独立的Ninja rule，这样也就可以支持并行处理了（可以在下载一个package的同时在编译另一个image，或者在一个大规模的build system中加快其他的build task，这都归功于Ninja），也能更好的支持增量编译（因为如果package版本没变的话就不需要重复进行工作了）。最终合并内容的动作也很快，因为它只需要修改OSTree的metadata即可。

apt2ostree目前只有唯一的一个用户，也就是我们公司的编译系统。参见GitHub上apt2ostree仓库的README文件来了解更多信息。我并不需要更多人来使用它，但是它确实是一个能展示本文中提到的技巧的好例子，并且是完整可用的。

Conclusions and acknowledgment

我们认为OSTree和Ninja可以完美配合在一起工作，这一切都要归功于这个伟大的设定：用ref（OSTree metadata目录中的一个文件）来作为Ninja rule的target或者dependency，这样就可以跟踪整个目录的变动了。不过我认为更重要的是这个把目录树来当做build system中的主要单位的这个好主意。在生产系统中，我们也看到OSTree和Ninja配合的非常好，尤其是我们这个特定的应用场景更加如是，也就是为嵌入式Linux设备编译生成container image和rootfs的系统集成商的角度。

大多数主意都是来自我的同事William Manley，我们build system的主要的实现工作也是他做的，我仅仅是把它写了下来而已。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注LWN深度文章以及开源社区的各种新近言论～