深入 Skia 的 Bazel RBE 构建自建容器镜像、Hermetic 工具链与平台定义全解【免费下载链接】skiaSkia is a complete 2D graphic library for drawing Text, Geometries, and Images. See documentation for contribution instructions.项目地址: https://gitcode.com/gh_mirrors/ski/skia导读Skia 使用 Bazel 作为构建系统并将大规模构建任务分发到远程构建执行Remote Build ExecutionRBE集群上。本文以 bazel/rbe/README.md 为骨架结合仓库内真实的 Makefile、Dockerfile、平台定义 与 buildrc 配置系统讲解 Skia 的 RBE 配置思路为什么自建精简镜像、为什么编译必须走 hermetic 工具链、如何可复现地创建与更新 RBE 镜像以及如何定义和使用自己的 Bazel RBE 平台。读完本文你将能理解并复现 Skia 这套“镜像只提供运行时环境、工具链完全自带”的远程构建方案。RBE 配置目录的结构与“生成物”边界bazel/rbe/目录是 Skia 所有 RBE 相关配置的集中地其结构为路径角色bazel/rbe/README.mdRBE 配置说明文档bazel/rbe/Makefile镜像构建 / 推送 / 配置生成入口bazel/rbe/gce_linux_container/DockerfileLinux RBE 容器镜像定义bazel/rbe/gce_linux/由工具生成的 RBE 配置勿手改文档明确指出gce_linux这个子目录是生成的由make generate_linux_config命令产生底层调用 rbe_configs_gen 工具。生成内容包括 cc/C 工具链定义如 cc_toolchain_config.bzl、cc_wrapper.sh、java/ 以及 config/BUILD 中定义的工具链与平台。这里有一个非常容易混淆、却极其关键的区别README 用了整段强调这些生成文件描述的是 RBE Docker 镜像内部的 C 和 Java 工具链这些工具链是运行 Bazel 所必需的但并不是我们用来编译 Skia 代码的工具链。也就是说RBE worker 上的容器里确实装了 clang 和 JDK但那只是让 Bazel 本身能跑起来Bazel 需要一个默认 C 编译器和一个 Java 运行时真正编译 Skia 用的是另一套工具链——hermetic 工具链。这个“两层工具链”的设计是理解 Skia RBE 方案的总钥匙。设计核心Hermetic 工具链取代容器内工具链Skia 采用的自建 RBE 镜像是一个“bare-bones”极简镜像镜像内只装满足 Bazel 运行的最小依赖。真正的编译工作交给 hermetic 工具链其定义位于 toolchain/ 目录即 README 中所说的//toolchain。这套设计的收益在 README 中被明确列出构建可复现、跨机器一致无论构建发生在开发者本地还是 RBE worker 上只要工具链相同结果就一致无需联网只要 hermetic 工具链被缓存过一次之后的构建就不需要访问互联网工具链演进成本低当需要修改工具链的某个小细节时无需重新构建、重新上传 RBE Docker 镜像。镜像内容不变变化的只是随构建分发的工具链。从源码结构可以印证这一机制。在 toolchain/BUILD.bazel 中clang_linux_x64_toolchain的exec_compatible_with声明了platforms//os:linux与platforms//cpu:x86_64它可以在任意 Linux x64 机器上运行包括 RBE worker而target_compatible_with额外带上了//bazel/platform:use_hermetic_toolchain这个自定义约束。注释对此解释得很清楚加这个约束是为了“显式告诉 Bazel 使用这套工具链而不是使用用户机器或 RBE worker 上的默认工具链”从而把“stock 工具链”与“hermetic 工具链”区分开并通过指定 target platform 强制选中后者。对 RBE 镜像的唯一要求足够的运行时库既然编译由 hermetic 工具链负责那容器镜像还需要什么README 给出了答案只要求镜像具备足以运行工具链的运行时库。具体到 Linux 平台镜像至少需要glibc 2.32——这是当前工具链中 Linux 二进制的硬性最低要求。README 特意强调这一要求与任何想在本地用 Bazel 构建 Skia 的开发者所面临的要求完全相同。换句话说镜像不需要任何开发头文件、编译器或链接器只需要一个能让工具链二进制跑起来的 glibc 环境。这一原则也解释了为什么 Dockerfile 里安装的都是“运行时类”依赖而非构建依赖详见下文。获取 rbe_configs_genrbe_configs_gen是 Bazel 官方工具链项目 bazel-toolchains 提供的一个命令行工具用于根据容器镜像生成 Bazel 的 RBE 配置即gce_linux/目录下的那些文件。README 的建议是从 bazel-toolchains 项目的v5.1.1release 页面下载预编译好的二进制并把它放进你的PATH。仓库内的 Makefile 注释中则提到 v5.1.2 版本并在generate_linux_config目标中展示了它的完整用法generate_linux_config: rbe_configs_gen \ --bazel_version5.3.2 \ --toolchain_containergcr.io/skia-public/rbe_linuxsha256:82e8a4c7d06c8f47bbc08ee899c4c03069af0f7f4d8c0d958a50a23d814405e6 \ --output_src_root../.. \ --output_config_pathbazel/rbe/gce_linux \ --exec_oslinux \ --target_oslinux各参数的含义参数值作用--bazel_version5.3.2生成与该 Bazel 版本兼容的配置--toolchain_containergcr.io/skia-public/rbe_linuxsha256:...指定生成配置所依据的容器镜像含 sha256 摘要保证确定性--output_src_root../..输出根目录仓库根--output_config_pathbazel/rbe/gce_linux生成的配置落盘位置--exec_os/--target_oslinux/linux执行端与目标端的操作系统创建 / 更新 RBE 镜像一套可复现的 7 步流程动机SLSA Level 1 与可复现性README 指出为了达到SLSA level 1Skia 希望有一种“脚本化”的方式构建镜像并能精确说明镜像里到底有什么产物。为此仓库对两件事做了硬性固定基础镜像的精确 sha256FROM debiansha256:b46fc4e6813f6cbd9f3f6322c72ab974cc0e75a72ca02730a8861e98999875c7叠加安装的每个软件包的精确版本如clang1:11.0-51nmu5、openjdk-11-jdk-headless11.0.1810-1~deb11u1等。这样做的效果是任何人在任何时候重新构建镜像都“极有可能”得到一模一样的镜像。完整 7 步流程README 给出了详尽的更新流程每一步都有明确的目的临时移除版本限定符修改对应的 Dockerfile如 gce_linux_container/Dockerfile去掉版本与 hash 限定符同时在 Makefile 中递增相应的VERSION变量当前 Linux 镜像版本为LINUX_VERSIONv3。修改内容添加新软件包或做任何需要的变更。本地构建并验证执行make build_linux_container在本地构建镜像可以用类似docker run -it gcr.io/skia-public/rbe_linux:v3 /bin/bash的命令进入镜像验证其工作正常。记录实际使用的版本与基础镜像 hash写回 Dockerfile基础镜像 hash用docker pull debian:bookworm-slim是最简便的方式——pull 后会显示该镜像的 sha256也确保拿到的是最新版软件包版本从 apt 安装日志中查找例如日志形如Get:89 http://deb.debian.org/debian bookworm/main amd64 clang amd64 1:14.0-55.2b1 [9976 B]即可得知实际装上的精确版本号。重建并推送执行make push_linux_container重新构建镜像并推送到 GCS供 RBE worker 拉取同时记录这个新容器的 sha256——它将在下一步被写进配置。更新生成步骤并重新生成配置修改 Makefile 中对应的 generate 步骤如generate_linux_config使其--toolchain_container指向新镜像的 sha256然后运行该步骤重新生成gce_linux/配置。更新 RBE platform修改 bazel/platform/BUILD.bazel 中的 RBE 平台定义使其exec_properties里的container-image指向新的container_image见下一节。为什么用 Make 而不是 Bazel rules这是一个值得注意的工程决策。README 给出了两点理由引导问题如果用 Bazel rules 来构建容器那么在 Bazel 尚未就绪的情况下比如全新环境、构建系统自举阶段就无法构建这个“用来跑 Bazel”的容器形成死锁简单够用Make 足以把这几步串成脚本满足 SLSA 的可复现与可审计要求。当前 Dockerfile 的实际内容解读仓库当前的 Dockerfile 是理解“极简镜像”理念的最佳样例其关键内容与用途如下FROM debiansha256:b46fc4e6813f6cbd9f3f6322c72ab974cc0e75a72ca02730a8861e98999875c7 RUN apt-get update \ apt-get install -y \ clang1:11.0-51nmu5 \ openjdk-11-jdk-headless11.0.1810-1~deb11u1 \ fonts-dejavu-extra2.37-2 \ fonts-noto-core20201225-1 \ fonts-noto-cjk1:20201206-cjkrepack1-1 \ fonts-noto-color-emoji0~20200916-1 \ zip3.0-12 ENV JAVA_HOME/usr/lib/jvm/java-11-openjdk-amd64/Dockerfile 头部注释逐条说明了每个包的用途恰好印证了 README 的“运行时库”论clang、openjdkBazel 需要一个默认 C 编译器和一个 Java 运行时才能运行但它们不会被用来编译 Skia 代码编译走 hermetic 工具链fonts-dejavu-extra默认的 fonts-dejavu-core 缺少斜体字体装上额外字体集以覆盖更多字体场景fonts-noto-*为大量测试字体的 GMgolden master测试提供字体覆盖zipBazel 需要在//bazel-testlogs下生成一个 ZIP 文件来收纳 undeclared test outputs例如用于回收 GM 测试产出的图片。此外还有两条值得记录的注释基础镜像方面作者原本希望使用debian:bookworm但因 Docker 20.10.9 的一个已知问题涉及 Ubuntu 21.10 / Fedora 35 在该 Docker 版本上无法工作回退到了bullseyeDockerfile 还特别要求“每个软件包单独占一行”以便在按 README 的流程“批量移除固定版本号”时能用多光标编辑快速操作。自定义 Bazel RBE 平台不用生成物自己定义虽然 rbe_configs_gen 生成的配置里确实包含一个可用的平台//bazel/rbe/gce_linux/config:platform见 gce_linux/config/BUILD但 Skia并不使用它。理由在 README 中写得很直白生成的平台无法方便地自定义一旦更新镜像重新生成配置自定义改动有被覆盖丢失的风险。因此 Skia 在 bazel/platform/即 README 中所说的//bazel/platform中自行定义了平台把 RBE 实例所需的exec_properties放在这里。以最核心的 linux_x64_hermetic 为例platform( name linux_x64_hermetic, constraint_values [ platforms//os:linux, platforms//cpu:x86_64, :cgo_off, :use_hermetic_toolchain, ], exec_properties { container-image: docker://gcr.io/skia-public/rbe_linuxsha256:82e8a4c7d06c8f47bbc08ee899c4c03069af0f7f4d8c0d958a50a23d814405e6, OSFamily: Linux, Pool: gce_linux, }, )constraint_values如何选中 hermetic 工具链平台上的两个自定义约束是理解机制的关键use_hermetic_toolchain由 bazel/platform/BUILD.bazel 中定义的constraint_setting(name skia_hermetic_toolchain)与constraint_value(name use_hermetic_toolchain)提供。由于 toolchain/BUILD.bazel 中各 hermetic 工具链的target_compatible_with同样声明了该约束Bazel 在解析工具链时会自动匹配到 hermetic 工具链而非系统默认工具链cgo_off别名指向rules_go//go/toolchain:cgo_off用于禁用 Go 构建中的 cgo从而避免在编译 Go 二进制时调用 C 编译器。BUILD 文件中的大段注释说明这是为了规避一个在 Linux/macOS 上构建 Go 相关 C/C 代码时工具链执行目录结构异常的问题——通过禁用 cgo 一劳永逸地绕开它。exec_properties如何把任务送到正确的 workerexec_properties是平台注释中重点解释的部分bazel/platform/BUILD.bazel#L17-L33我们指定 exec_properties 是因为存在一个与该平台匹配的 RBE 实例。exec_properties 中携带的信息会沿 Remote Execution APIREAPI传给 dispatcherdispatcher 再借助这些信息通过 Remote Worker APIRWAPI把请求定向到合适的机器/worker。具体到三个键键值含义container-imagedocker://gcr.io/skia-public/rbe_linuxsha256:...worker 上应使用的容器镜像含摘要锁定OSFamilyLinux操作系统族Poolgce_linux选择使用哪个 worker 池gce_linux注释还强调了一个容易忽略的细节这些属性在本地构建时会被忽略但必须指定——原因在于 Bazel 的 action cache 会把exec_properties和执行平台纳入 action key 的考量注释中引用了 Bazel 源码 ActionKeyCacher 的实现。只有让本地 Linux 构建与 RBE Linux 构建携带相同的 exec_properties才能让 action cache 认为两者的产物等价从而实现缓存共享。前提是 hermetic 工具链“确实 hermetic”否则本地与远程产物无法被认为一致。平台全景bazel/platform/BUILD.bazel 中除linux_x64_hermetic外还定义了mac_x64_hermetic、mac_arm64_hermetic、windows_x64_hermetic对应的本地/远程执行平台macOS 与 Windows 平台没有额外的 exec_properties说明它们主要用于本地构建或尚未接入 RBEhost_with_hermetic_toolchain继承local_config_platform//:host的宿主平台变体供本地非 RBE构建使用android_arm32、android_arm64、iosAndroidarmeabi-v7a / arm64-v8a与 iOSarm64 真机的目标平台。在 buildrc 中组合使用 RBE有了平台定义Skia 在 bazel/buildrc 中通过组合式 config 把它们接到日常构建命令上。buildrc 中先定义了“目标平台 编译模式”的基准配置例如build:for_linux_x64_debug --platforms//bazel/platform:linux_x64_hermetic \ --compilation_modedbg \ --cc_output_directory_taglinux_x64_debug随后通过叠加linux_rbe配置得到 RBE 版本build:for_linux_x64_debug_with_rbe --configfor_linux_x64_debug --configlinux_rbe build:for_linux_x64_release_with_rbe --configfor_linux_x64_release --configlinux_rbe build:for_linux_x64_fastbuild_with_rbe --configfor_linux_x64_fastbuild --configlinux_rbeAndroid 交叉编译同样有对应的for_android_arm32/arm64_*_with_rbe以及简写别名android_rbe、android_arm32_rbe等。另外还有一组面向测试的配置build:use_linux_rbe_pool --configlinux_rbe --remote_download_minimal build:cpu_only_debug_rbe --configcpu_only_debug --configuse_linux_rbe_pool build:cpu_only_release_rbe --configcpu_only_release --configuse_linux_rbe_pool--remote_download_minimal意味着远程执行后只下载必要产物从而大幅降低 RBE 构建的带宽与磁盘开销。实际用法示例bazel build //some:target --configfor_linux_x64_fastbuild_with_rbe这一模式在仓库的其他位置也有体现例如 bazel/Makefile 中的generate_gni_rbe目标即使用bazelisk build //bazel/exporter_tool --configlinux_rbe --jobs100在 RBE 上并行生成 GN 配置以 100 个并行 job 压满远程集群。更多资料与指标README 末尾提到两份参考资料一份是更详细的 RBE 配置说明文档另一份是 Skia 内部的 RBE 指标页面用于观测远程构建的排队、执行与缓存命中情况。这两份内容均为 Skia 内部资源不随本仓库分发读者可在 Skia 团队内部文档系统中查阅。如果你需要了解 RBE 运行时的健康状态指标页面是最直接的入口。总结Skia 的 Bazel RBE 方案可以提炼为一句话用极简镜像装下“能让 Bazel 跑起来的运行时”用 hermetic 工具链装下“能编译 Skia 的一切”。围绕这个核心仓库做了三件事一是用 Make 固定 sha256/软件包版本的方式可复现地构建、推送容器镜像满足 SLSA level 1二是用 rbe_configs_gen 生成描述镜像内工具链的配置但只用它作为 Bazel 运行的基础绝不参与 Skia 代码编译三是在//bazel/platform自行定义带 exec_properties 的平台并在 bazel/buildrc 中以--config..._with_rbe的形式一键切换本地/远程构建。这套设计让“工具链小改”与“镜像发布”彻底解耦也保证了本地构建与 RBE 构建在 action cache 层面的一致性——对任何希望大规模使用 Bazel RBE 的 C 项目而言都是极具参考价值的工程范本。【免费下载链接】skiaSkia is a complete 2D graphic library for drawing Text, Geometries, and Images. See documentation for contribution instructions.项目地址: https://gitcode.com/gh_mirrors/ski/skia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考