MongoDB 打包系统工作原理从 Evergreen 触发到 S3 上传与第三方包管理器发布【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongoMongoDB 的打包系统是一条从持续集成调度到最终发行产物的自动化流水线Evergreen 触发打包任务后依次完成 SBOM 获取、Bazel 发行包构建、本地 deb/rpm 打包、S3 上传、包测试并在发布版本时通过 Curator 将包投递到第三方包管理器。本文以 docs/packaging.md 的官方时序图为主线结合 buildscripts/packager.py、buildscripts/packager_enterprise.py、etc/repo_config.yaml 等仓库源码逐环节拆解这条流水线的参与者、数据流与实现细节帮助读者理解 MongoDB 官方 .deb / .rpm 包是如何从源码仓库一路变成 apt / yum / zypper 仓库中可安装的产物。一、整体架构七个参与者的协作时序官方文档用一张 Mermaid 时序图完整描述了打包系统的端到端流程。参与方共有七个Evergreen持续集成调度、Obtain SBOM from SilkSBOM 获取脚本、SilkSBOM 服务、Bazel构建系统、Packager打包程序、S3对象存储与 Curator仓库发布工具。sequenceDiagram participant e as Evergreen participant osfs as Obtain SBOM from Silk participant silk as Silk participant bazel as Bazel participant p as Packager participant s3 as S3 participant curator as Curator e - e: Trigger package task e - osfs: Invoke script osfs - silk: Query for SBOM silk - osfs: Return SBOM osfs - e: Return SBOM e - bazel: Invoke build (including Bazel) bazel - bazel: Build distribution tarball (including SBOM) bazel - e: Return distribution tarball e - p: Invoke packager p - p: Build local package p - s3: Upload package s3 - p: Return success p - p: Test package p - curator: Upload package to 3P package managers (on release only) curator - p: Return success p - e: Return success这条时序可以归纳为五个阶段与仓库中的实际脚本一一对应任务触发与 SBOM 获取Evergreen 触发打包任务调用 SBOM 获取脚本向 Silk 查询软件物料清单SBOM。发行版 tarball 构建Evergreen 调用 Bazel 构建包含 SBOM 的发行版 tarballdistribution tarball。本地打包Evergreen 调用 Packager在打包机上生成 deb/rpm 包。上传与自测Packager 将包上传至 S3并在本地对包进行安装/可运行性测试。发布到第三方包管理器仅在正式发布release时Packager 通过 Curator 将包投递到第三方3P包管理器。其中「Obtain SBOM from Silk」在仓库中对应 evergreen/functions/upload_sbom_via_silkbomb.py 与 evergreen/write_silkbomb_env.sh 等脚本Curator 发布环节对应 evergreen/packages_publish.sh。下面逐一深入每个环节。二、任务触发与 SBOM 获取把物料清单带进构建流水线的起点是 Evergreen 触发打包任务。MongoDB 的持续集成编排逻辑集中在 etc/evergreen.yml 及 evergreen/functions 目录下的脚本中。SBOMSoftware Bill of Materials软件物料清单是本次打包流程的一个重要产物它被要求在构建发行版 tarball 时一并打入。仓库中与 SBOM 相关的实现包括evergreen/functions/upload_sbom_via_silkbomb.py通过 Silkbomb 工具上传 SBOMevergreen/functions/security_reporting_scripts/augment_sbom.sh 与 select_licenses.sh对 SBOM 进行许可信息扩充与筛选evergreen/write_silkbomb_env.sh、evergreen/write_endor_credentials.sh为 Silkbomb 写入所需的凭据环境。时序图中「osfs - silk: Query for SBOM / silk - osfs: Return SBOM」表示获取脚本向 Silk 服务查询并取回该构建对应的 SBOM。Silk 是 SBOM 的存储与查询服务MongoDB 用它统一管理各构建产物的物料清单随后这份 SBOM 会被纳入 Bazel 构建的 tarball随包分发满足供应链可追溯性要求。三、Bazel 构建发行版 tarballSBOM 随包分发拿到 SBOM 后Evergreen 调用 Bazel 构建发行版 tarballdistribution tarball。这一步产出的是「静态链接可执行文件的发行包」它是后续 deb/rpm 打包的直接输入。Bazel 侧的打包规则集中在 bazel 目录其中 bazel/mongo_src_rules.bzl 等文件定义了源码目标的构建规则。这一阶段的关键点在于构建发行版 tarball 时会把上一步获取的 SBOM 一起打入因此最终每个 Linux 软件包内都携带了对应版本的物料清单这与时序图中「bazel - bazel: Build distribution tarball (including SBOM)」完全对应。从 buildscripts/packager.py 的注释可以确认该 tarball 的形态与用途This program makes Debian and RPM repositories for MongoDB, by downloading our tarballs of statically linked executables and insinuating them into Linux packages.即 Packager 以下载到的静态链接可执行文件 tarball 为原料将其「嵌入」Linux 包中。tarball 命名由 packager.py 中的tarfile()函数定义def tarfile(build_os, arch, spec): Return the location where we store the downloaded tarball for this package. return dl/mongodb-linux-%s-%s-%s.tar.gz % (spec.version(), build_os, arch)命名模式为mongodb-linux-version-build_os-arch.tar.gz例如mongodb-linux-8.0.0-rhel93-x86_64.tar.gz。四、Packager把 tarball 变成 deb/rpm时序图的核心环节是「p - p: Build local package」对应仓库根目录下的打包程序 buildscripts/packager.py社区版与 buildscripts/packager_enterprise.py企业版。4.1 运行环境与前置条件从 packager.py 的模块注释可见Packager 必须在Debian 系操作系统上运行因为 Debian 系提供了制作 RPM 的工具而 RPM 系系统不提供 Debian 打包工具。新主机上的前置条件为apt-get install dpkg-dev rpm debhelper fakeroot ia32-libs createrepo git-core # 并把发行版 gnupg 签名密钥放入 ~root/.gnupg4.2 命令行参数main()通过 argparse 解析以下参数packager.py参数说明-s, --server-version要打包的服务器版本如2.7.8-rc0必填-m, --metadata-gitspec用于 spec/control/init/manpage 等元数据文件的 git 修订号默认使用对应版本的 release tagrversion-r, --release-numberRPM release 号基数整数-d, --distros目标发行版可多次追加可选值由「发行版 × 架构」组合生成-a, --arches目标架构可多次追加-p, --prefix工作目录缺省时随机创建临时目录-t, --tarball本地 tarball 路径必填且必须真实存在-c, --crypt_spec使用 crypt spec 构建指定包一个关键约束是-t指定本地 tarball 时只能同时指定一个 distro/arch 组合否则程序报错「Can only specify local tarball with one distro/arch combination」。4.3 支持的架构与发行版packager.py 定义了社区版支持的架构与发行版# The MongoDB names for the architectures we support. ARCH_CHOICES [x86_64, arm64, aarch64, s390x] # Made up names for the flavors of distribution we package for. DISTROS [suse, debian, redhat, ubuntu, amazon, amazon2, amazon2023]企业版packager_enterprise.py在此基础上增加了ppc64le架构。Distro.build_os()方法进一步展开各发行版对应的 build_os 标签packager.py例如redhat/fedora/centos 系rhel10、rhel93、rhel90、rhel80、rhel70、rhel62等ubuntu 系ubuntu1204ubuntu2404debian 系debian81debian13suse 系suse11、suse12、suse15、suse16amazon 系amazon、amazon2、amazon2023。4.4 打包主流程main()packager.py对「发行版 × 架构」做笛卡尔积遍历对每个(distro, build_os, arch)组合执行放置 tarball按tarfile()命名规则把输入的 tarball 复制到工作目录shutil.copyfile供后续解包。make_package()packager.py按setupdir()生成 setup 目录形如dst/x86_64/debian/wheezy/mongodb-org-unstable/把仓库根目录的debian/与rpm/两个打包元数据目录整体复制进 setup 目录解包二进制 tarball并把bin、LICENSE-Community.txt、README、THIRD-PARTY-NOTICES、MPL-2等文件移到 setup 目录根部根据发行版类型分发到make_deb()或make_rpm()。make_repo()packager.py把生成的包归档进该发行版偏好的仓库目录布局并生成仓库索引。4.5 Debian 包制作make_debmake_deb()packager.py的核心逻辑服务文件选择Debian 系删除init.d按发行版选择 systemd 的mongod.service新版本或 upstart 的mongod.upstartubuntu1204/1404/1410 等老版本并把服务文件软链为与包名匹配的形式mongodb-org-server.mongod.service。元数据生成调用write_debian_changelog()从 git 中按metadata_gitspec取出debian/changelog并改写版本号从仓库复制debian/mongodb-org.control→debian/control、debian/mongodb-org.rules→debian/rules复制*.postinst脚本写入空的debian/substvars与debian/source/format内容为1.0。调用 dpkg-buildpackagesysassert([dpkg-buildpackage, -uc, -us, -a distro_arch])-uc/-us表示不签名 Changes 与源码包-a指定目标架构。归档把生成的.deb复制到distro.repodir()返回的仓库目录。write_debian_changelog()packager.py还展示了打包程序与 git 的交互它会暂存未提交的改动做一次临时 commit再从git archive gitspec debian/changelog中提取官方 changelog改写包名前缀与版本号后落盘最后git reset --mixed还原仓库状态。4.6 RPM 包制作make_rpmmake_rpm()packager.py的核心逻辑spec 文件选择根据发行版与 OS 版本切换不同 specSUSE 10/11 使用init.d-mongod.suse与mongodb-org-init.specRHEL 5/6 与 amazon 使用mongodb-org-init.spec其余新发行版默认使用 systemd 的mongodb-org.spec。构建 SOURCES把 setup 目录打成mongodb-org-pversion.tar.gz放入rpmbuild/SOURCES。调用 rpmbuildrpmbuild -ba --target arch并注入宏_topdir构建根目录dist .release_dist如.el9、.amzn2023release_dist()见 packager.pydynamic_version与dynamic_release版本与 release 号必要时显式给出pathfix宏路径与--buildrootRPM 4.4 忽略 spec 内 BuildRoot。归档把rpmbuild/RPMS/arch/下的.rpm复制到仓库目录。4.7 仓库目录布局repodirDistro.repodir()packager.py决定了包在发行版偏好仓库布局中的落点典型路径如下repo/apt/ubuntu/dists/precise/mongodb-org/2.5/multiverse/binary-amd64 repo/apt/debian/dists/wheezy/mongodb-org/2.5/main/binary-amd64 repo/yum/redhat/6/mongodb-org/2.5/x86_64 repo/zypper/suse/11/mongodb-org/2.5/x86_64其中2.5是版本分支spec.branch()预发布版本RC、nightly会进入专门的testing目录。Debian 系的组件component为multiverseubuntu或maindebian。4.8 架构名映射由于 apt/yum 对同一 CPU 架构的命名不同Distro.archname()packager.py负责转换Debian 系ppc64le → ppc64el、x86_64 → amd64RPM 系x86_64 → x86_64、i386 → i686等。4.9 版本分类与命名规则Spec类packager.py负责解析版本串并决定包的后缀、pre-release 与仓库归类is_nightly()版本以-结尾或形如-gshais_patch()形如\d-\d-gsha-patch-shais_rc()形如(-rc|-alpha)\d$is_pre_release()RC 或 nightly。get_suffix()packager.py决定稳定/不稳定后缀5.0 及以上版本以 minor 是否为 0或处于 8.2/8.3 这类特殊 LTS 序列判断输出-org/-org-unstable企业版对应-enterprise/-enterprise-unstablepackager_enterprise.py。crypt 包则使用-enterprise-crypt-v1/-enterprise-unstable-crypt-v1packager_enterprise.py。RPM 的 release 后缀prelease()packager.py按构建类型区分RC →0.N.rcXnightly →0.N.latestpatch →0.N.patch.id正式版 →N。Debian 版本号则通过pversion()处理把-替换为~以满足 Debian 的版本规则。4.10 仓库索引生成make_repo()进一步调用make_deb_repo()packager.py用dpkg-scanpackages生成Packages用gzip -9c生成Packages.gz再用apt-ftparchive release .生成Release文件写入 Origin/Label/Suite/Codename/Components 头其中 Architectures 固定为amd64 arm64 s390xmake_rpm_repo()packager.py直接调用createrepo .。move_repos_into_place()packager.py则负责把新生成的仓库目录通过「带日期后缀的新目录 符号链接切换」的方式原子替换为当前仓库旧仓库保留为.old后缀以便回退。五、S3 上传与包测试时序图中「p - s3: Upload package / p - p: Test package」表明包在本地构建完成后上传到 S3 的固定路径s3://mciuploads/project/build_variant/revision/artifacts/build_id-packages.tgz该 URL 模式可见于 evergreen/packages_publish.sh在打包机上对包执行安装与运行测试验证包内容正确、可正常启动再向 Evergreen 回报成功。这一步保证了只有通过自测的包才会进入后续发布链路。六、发布环节Curator 投递第三方包管理器时序图最后一段「p - curator: Upload package to 3P package managers (on release only)」明确指出只有正式发布release时才执行第三方包管理器投递。对应实现是 evergreen/packages_publish.sh其关键步骤为Atlas 版repo_edition atlas直接跳过发布从 S3 拉取packages.tgz用podman run--env-host以UPLOAD_LOCK_IMAGE加锁上传避免并发发布冲突下载对应版本的curator-dist-rhel70-version.tar.gz并解压调用 curator 提交仓库./curator repo submit \ --service ${barque_url} \ --config ./etc/repo_config.yaml \ --distro ${packager_distro} \ --edition ${repo_edition} \ --version ${version} \ --arch ${packager_arch} \ --packages s3://mciuploads/.../${build_id}-packages.tgzCurator 的仓库行为由 etc/repo_config.yaml 驱动该配置包含三部分services定义notary_url用于包签名校验服务notary-servicetemplates定义 deb 仓库的Release文件头模板区分org与enterprise以及仓库索引页 HTML 模板repos逐项声明目标仓库例如- name: rhel70 type: rpm edition: org bucket: repo.mongodb.org repos: - yum/redhat/7/mongodb-org - yum/redhat/7Server/mongodb-org即每个仓库条目包含name发布目标名、typerpm/apt 等、editionorg 社区版 / enterprise 企业版、bucket发布到哪个 S3 bucket如repo.mongodb.org与repos仓库目录列表。Curator 依据这份配置把 S3 上已测试通过的包与仓库元数据投递到各发行版的官方软件源用户即可通过apt install mongodb-org、yum install mongodb-org、zypper install mongodb-org等常规包管理命令安装。七、企业版与社区版的差异对比 buildscripts/packager.py 与 buildscripts/packager_enterprise.py 可以看出两者的关系企业版通过继承packager.Spec与packager.Distro实现差异化主要区别集中在后缀不同-enterprise/-enterprise-unstablecrypt 包为-enterprise-crypt-v1/-enterprise-unstable-crypt-v1架构多了ppc64le仓库目录使用mongodb-enterprise而非mongodb-org见EnterpriseDistro.repodir()的示例路径解包时移动的许可证文件为LICENSE-Enterprise.txtpackager_enterprise.py。打包主流程、Debian/RPM 制作与仓库生成逻辑则完全复用社区版的make_deb/make_rpm/make_repo。八、小结MongoDB 打包系统本质上是「Evergreen 调度 Silk 提供 SBOM Bazel 出 tarball Packager 转 deb/rpm S3 中转 Curator 发布」的分层流水线。理解这条链路的关键在于记住三个「两分法」阶段分两段构建产物与测试在 Evergreen/Packager 本地完成投递第三方包管理器仅在 release 时通过 Curator 触发包型分两类.debdpkg-buildpackage与.rpmrpmbuild且打包机必须运行在 Debian 系系统上仓库分两路正式版进入按主版本号命名的目录RC/nightly 等预发布版本进入testing目录同时社区版mongodb-org与企业版mongodb-enterprise使用各自独立的仓库路径。对于希望深入研究的读者建议按以下路径顺藤摸瓜docs/packaging.md官方流程总览→ buildscripts/packager.py社区版打包实现→ buildscripts/packager_enterprise.py企业版差异→ evergreen/packages_publish.shCurator 发布入口→ etc/repo_config.yaml仓库发布配置→ debian 与 rpm包元数据、control/rules/spec 与 init 脚本模板。【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考