gRPC 仓库 RBE 工具链配置详解Linux 与 Windows 远程构建环境的生成、重建与使用【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc导读本文围绕 gRPC 仓库中 third_party/toolchains/README.md 所描述的核心内容展开gRPC 项目如何在 Bazel 构建体系下为远程构建执行RBE, Remote Build Execution维护 Linux 与 Windows 两套自动生成的工具链配置。读完本文你将掌握这两套工具链目录rbe_ubuntu2004_bazel7与rbe_windows_vs2022_bazel7的构成与用途、如何用rbe_configs_gen工具重新生成它们、如何重建并推送 Windows RBE 的 Docker 基础镜像以及 gRPC 的bazelrc文件是如何通过third_party/toolchains/BUILD中定义的平台与工具链别名接入 RBE 的。一、背景gRPC 的 Bazel 构建与 RBE 工具链gRPC 是一个跨语言的 RPC 框架其核心以 C 实现同时覆盖 Python、Ruby、Objective-C、PHP、C# 等多种语言。为了保证大规模持续集成CI的构建效率与结果一致性gRPC 的测试与构建大量依赖 Bazel 的远程构建执行RBE能力构建动作并不在本机执行而是被分发到由 Google 基础设施托管的远程 worker 上按指定容器镜像中的工具链完成编译与测试。在 RBE 模式下Bazel 需要三样东西工具链toolchain描述编译、链接、归档等动作应使用哪个编译器、哪些标志位平台platform描述执行动作的机器环境OS、CPU、容器镜像等执行属性exec_properties描述远程 worker 如何运行容器是否特权、机器大小等。gRPC 仓库将这些配置集中维护在 third_party/toolchains 目录下并按操作系统分为两套Linux 一套、Windows 一套。所有配置文件均由官方工具rbe_configs_gen自动生成而不是手工编写——这是理解本目录结构的关键前提。二、Linux RBE 工具链rbe_ubuntu2004_bazel72.1 目录构成rbe_ubuntu2004_bazel7目录存放 Linux RBE 的自动生成工具链配置其中cc/C 工具链定义核心文件包括 cc/BUILDcc_toolchain_suite与cc_toolchain目标、cc/cc_toolchain_config.bzl编译器路径、编译/链接标志等详细配置、cc_wrapper.sh、builtin_include_directory_paths等config/平台与toolchain注册目标见 config/BUILDWORKSPACE、REPO.bazel使该目录可作为一个独立 Bazel 外部仓库被引用。从 cc/BUILD 的cc_toolchain_config定义可以看到该工具链的实测细节编译器为/usr/local/bin/clang-19目标系统为x86_64-unknown-linux-gnulibc 为glibc_2.19并带有一组与 gRPC 构建需求匹配的标志例如compile_flags-fstack-protector、-Wall、-Wthread-safety、-fno-omit-frame-pointer等cxx_flags-stdc14opt_compile_flags-O2、-DNDEBUG、-ffunction-sections、-fdata-sections等link_flags使用ld.lld链接器并启用-Wl,-z,relro,-z,now等加固选项unfiltered_compile_flags将__DATE__、__TIMESTAMP__、__TIME__宏替换为 redacted以提升构建可复现性。这些内容说明虽然配置文件由工具自动生成但它精确地承载了 gRPC 在 Linux 上编译所依赖的编译器与标志约定。2.2 如何重新生成 Linux 配置运行仓库根目录下的 generate_linux_rbe_configs.sh 即可重新生成 Linux 配置。脚本的关键步骤与参数如下构建rbe_configs_gen工具脚本先克隆 bazel-toolchains 仓库再通过golang:1.16容器执行go build得到rbe_configs_gen二进制确定 RBE 容器镜像Linux 的 RBE 动作运行在 gRPC 自维护的测试镜像之上镜像目录为tools/dockerfile/test/rbe_ubuntu2004具体 digest 从该目录的.current_version文件读取脚本中为LINUX_RBE_DOCKER_IMAGE$(cat ${LINUX_RBE_DOCKERFILE_DIR}.current_version)确定 Bazel 版本BAZEL_VERSION7.4.1。脚本注释特别说明应选用 bazel/supported_versions.txt 所列支持版本中最旧的一个这样生成的配置对其他受支持的 Bazel 版本兼容性最好执行生成调用rbe_configs_gen关键参数为rbe_configs_gen \ --bazel_version7.4.1 \ --toolchain_container${LINUX_RBE_DOCKER_IMAGE} \ --output_src_root${REPO_ROOT} \ --output_config_paththird_party/toolchains/rbe_ubuntu2004_bazel7 \ --exec_oslinux \ --target_oslinux \ --generate_java_configsfalse注意--generate_java_configsfalsegRPC 构建不需要 Java 工具链配置因此生成时显式关闭。生成前脚本会先删除旧的rbe_ubuntu2004_bazel7目录保证输出为全新生成的结果。三、Windows RBE 工具链rbe_windows_vs2022_bazel73.1 与 Linux 配置的关键差异Windows 工具链目录rbe_windows_vs2022_bazel7同样是rbe_configs_gen的产物但由于它描述的是 Windows 执行环境生成过程必须在 Windows 机器上完成rbe_configs_gen的 Windows 版本是针对 Windows 宿主编写的。从目录内容可以明显看到 Windows 特性cc/BUILD 中的cc_toolchain_suite为多种 CPU/编译器组合注册了工具链x64_windows|msvc-cl、x64_x86_windows|msvc-cl、x64_arm_windows|msvc-cl、x64_arm64_windows|msvc-cl、arm64_windows|msvc-cl、x64_windows|msys-gcc、x64_windows|mingw-gcc、x64_windows|clang-cl等提供多个builtin_include_directory_paths_*文件分别对应clangcl、mingw、msvc三种编译器风格提供vc_installation_error_*.bat、msys_gcc_installation_error.bat、clang_installation_error.bat、get_env.bat等辅助脚本用于在容器内探测环境并在缺少对应组件时给出清晰报错工具路径指向 Windows 风格路径例如c:/msys64/usr/bin/gcc、c:/msys64/usr/bin/ar等见 cc/BUILD。3.2 如何重新生成 Windows 配置README 给出的标准流程是在一个 Kokoro 调试用 Windows VM 中克隆 gRPC 仓库如何创建该 VM 见 Google 内部文档go/rbe-windows-user-guide在 VM 上运行 generate_windows_rbe_configs.sh 重新生成本地配置把生成好的配置拷贝回工作站例如通过gcloud compute scp命令。脚本自身的执行逻辑与 Linux 版本对称但有两个明显的 Windows 化差异工具获取方式直接wget下载官方发布版的预编译二进制rbe_configs_gen_windows_amd64.exev5.1.2而不是在容器里现场编译镜像与拉取WINDOWS_RBE_DOCKER_IMAGE指向us-docker.pkg.dev/grpc-testing/testing-images-public/rbe_windows2019sha256:cfef0ae3...按 digest 引用保证不可变脚本在生成前先执行docker pull拉取该镜像脚本注释提示在 Windows 上拉取镜像可能非常慢参数对应改为--exec_oswindows --target_oswindowsBAZEL_VERSION同样为 7.4.1输出到rbe_windows_vs2022_bazel7。3.3 关于 Bazel 版本的重要说明README 特别强调目录名中的bazel7表示生成该工具链配置时使用的 Bazel 版本但生成的配置并不绑定该版本——只要实际使用的 Bazel 版本兼容就可以搭配不同版本的 Bazel 使用。这也解释了生成脚本中“选择受支持版本中最旧的一个”的用意让一套配置尽量向后兼容更多 Bazel 版本。四、Windows RBE Docker 镜像rbe_windows20194.1 镜像与 DockerfileWindows RBE 动作运行在专用 Docker 镜像中其构建定义位于 third_party/toolchains/dockerfile/rbe_windows2019/Dockerfile。从 Dockerfile 可以看到该镜像的完整软件栈注意这是 Windows 容器基础镜像是mcr.microsoft.com/windows/servercore:ltsc2019网络修正设置 MTU 为 1460 并手工添加指向 169.254.169.254 的元数据服务器路由gRPC 的 RBE worker 依赖 GCE 元数据服务启用长路径注册表开启LongPathsEnabled编译工具链安装 Visual C Redistributable 与 Visual Studio 2022 Build Tools包含Microsoft.VisualStudio.Workload.VCTools、VC.Tools.x86.x64、Windows10SDK.20348组件并设置BAZEL_VCC:\VS\VCMSYS2 环境安装 msys2 及git、curl、zip、unzip并将C:\msys64\usr\bin加入 PATH设置BAZEL_SHC:\msys64\usr\bin\bash.exePython 3.10.4以静默方式安装并PrependPath1JDK 17安装 Azul Zulu JDK 17.0.2 并设置JAVA_HOME。Linux 侧则没有独立的 RBE 镜像目录——Linux 的 RBE 镜像就是 gRPC 日常维护的测试 Docker 镜像之一位于tools/dockerfile下具体为tools/dockerfile/test/rbe_ubuntu2004其版本由.current_version文件维护。这是 Linux 与 Windows 在镜像维护策略上的显著区别Linux 复用现有测试镜像Windows 则单独维护一个专用镜像。4.2 重建 Windows RBE 镜像的完整步骤README 给出了在 Kokoro 调试 Windows VM 上重建镜像并接入 RBE 的完整操作序列构建镜像docker build -t us-docker.pkg.dev/grpc-testing/testing-images-public/rbe_windows2019 third_party/toolchains/dockerfile/rbe_windows2019配置 GAR 认证推送镜像前先让 docker 能通过 Google Artifact Registry 认证gcloud auth configure-docker us-docker.pkg.dev推送镜像docker push us-docker.pkg.dev/grpc-testing/testing-images-public/rbe_windows2019更新生成脚本中的镜像 digest把 generate_windows_rbe_configs.sh 中WINDOWS_RBE_DOCKER_IMAGE变量指向的 SHA256 digest 更新为刚推送镜像的 digest。由于 Windows 环境通常会导致脚本带上 CRLF 行尾README 特别提示在执行前先用以下命令去掉\r字符sed -i s/\r$// third_party/toolchains/generate_windows_rbe_configs.sh重新生成 Windows 工具链按上一节的三步流程重新运行rbe_configs_gen使新的工具链配置引用新的镜像 digest。之所以要用 digest 而非 tag 引用镜像是为了保证每次构建/测试使用的环境完全可复现——镜像内容一旦变化digest 就变化配置与镜像的对应关系也随之更新。五、这些工具链在仓库中如何被使用5.1third_party/toolchains/BUILD中的别名与平台third_party/toolchains/BUILD 是接入 RBE 的枢纽它定义了两组公开目标目标作用rbe_linux_default_toolchain_suiteLinux 默认工具链套件别名指向rbe_ubuntu2004_bazel7/cc:toolchainrbe_linux_default_cc_toolchainLinux 默认 CC 工具链别名指向rbe_ubuntu2004_bazel7/config:cc-toolchainrbe_linux_default_platformLinux 默认执行平台parents继承自动生成的rbe_ubuntu2004_bazel7/config:platformrbe_windows_default_toolchain_suiteWindows 默认工具链套件别名指向rbe_windows_vs2022_bazel7/cc:toolchainrbe_windows_default_cc_toolchainWindows 默认 CC 工具链别名指向rbe_windows_vs2022_bazel7/config:cc-toolchainrbe_windows_default_platformWindows 默认执行平台parents继承自动生成的rbe_windows_vs2022_bazel7/config:platform平台定义中还通过create_rbe_exec_properties_dict设置了执行属性Linux 平台默认启用SYS_PTRACE能力与特权模式便于运行需要 ptrace 的测试并将标签os: ubuntu、machine_size: small附加到执行动作上——默认所有 RBE 动作在“小”型 worker 上运行个别目标可通过exec_properties覆盖为大型机器Windows 平台则标记os: windows_2019、machine_size: smallos_family Windows。自动生成的 config/BUILD 中的platform目标则承载了实际容器镜像引用例如 Linux 的container-image: docker://us-docker.pkg.dev/grpc-testing/testing-images-public/rbe_ubuntu2004sha256:b3eb1a17...Windows 对应的 digest 为rbe_windows2019sha256:cfef0ae3...见 rbe_windows_vs2022_bazel7/config/BUILD与生成脚本中引用的镜像完全一致。5.2bazelrc中的接线方式仓库的远程构建配置通过bazelrc文件把上述平台接入构建tools/remote_build/linux.bazelrc设置--crosstool_top//third_party/toolchains:rbe_linux_default_toolchain_suite、--extra_toolchains//third_party/toolchains:rbe_linux_default_cc_toolchain并将--extra_execution_platforms、--host_platform、--platforms统一指向rbe_linux_default_platformtools/remote_build/windows.bazelrc同样接线 Windows 的 toolchain suite / cc toolchain / platform并额外指定--shell_executableC:\\msys64\\usr\\bin\\bash.exe与--python_pathC:\\Program Files\\Python310\\python.exe与 RBE 容器内二进制位置保持一致还通过--dynamic_modeoff规避 Bazel 6.x 之后 Windows RBE 的已知问题。两处bazelrc还使用--test_tag_filtersLinux 用-no_linuxWindows 用-no_windows等过滤不适用的测试并统一将--jobs设为 100 以充分利用远程 worker 并发。这种“自动生成配置 仓库侧薄封装”的架构保证了工具链升级时只需重新运行生成脚本而不需要手工维护成百上千行的工具链定义。六、维护 RBE 工具链时的注意事项小结综合 README 与生成脚本维护 gRPC 的 RBE 工具链时有几点需要牢记不要手工编辑自动生成目录rbe_ubuntu2004_bazel7与rbe_windows_vs2022_bazel7均由rbe_configs_gen生成两个config/BUILD文件头部都明确标注 This file is auto-generated ... and should not be modified directly修改应通过更新镜像/参数后重新生成来完成生成平台必须与目标平台匹配Linux 配置在任意类 Unix 环境即可生成Windows 配置则必须在 Windows 机器如 Kokoro 调试 VM上生成镜像按 digest 引用Linux 与 Windows 的执行平台都以 SHA256 digest 锁定容器镜像Windows 侧重建镜像后必须同步更新 generate_windows_rbe_configs.sh 与 config/BUILD 中的 digestBazel 版本选择生成时使用的 Bazel 版本当前脚本中为 7.4.1会体现在目录名中但配置本身可以配合其他兼容的 Bazel 版本使用选择支持列表中最旧的版本生成兼容性最好Windows 脚本行尾问题Windows VM 上运行 bash 脚本前先执行sed -i s/\r$//去除 CR 字符否则脚本无法被 bash 正确解析。通过理解这套“自动生成 版本化提交 digest 锁定镜像”的维护模型开发者既可以复现 gRPC 的 RBE 构建环境也可以在自己的 Bazel 项目中借鉴同样的做法来管理远程构建工具链。【免费下载链接】grpcC based gRPC (C, Python, Ruby, Objective-C, PHP, C#)项目地址: https://gitcode.com/GitHub_Trending/gr/grpc创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
