PROJECT / 工程实践

统一构建缓存与镜像体系

让缓存离开单个 daemon，在不同构建节点之间复用。

项目目标

构建节点变化时，如果缓存只能留在原 daemon，本地的热缓存很难转化为稳定的交付速度。本项目把 BuildKit registry cache 纳入镜像与 CI 链路，验证缓存从一个 daemon 导出后，另一个 daemon 能直接导入并复用，为跨节点构建提供可回读的证据。

组件与架构

组件包括 GitLab CI、BuildKit 0.30.0、CCR registry cache 与 cache mount。工具链版本由 versions.env 单点锁定。registry cache 负责跨 daemon 的缓存传递；页面不会将 cache mount 与 registry 层缓存描述成完全相同的机制。

统一构建缓存与镜像体系：脱敏逻辑图GitLab CI → BuildKit daemon A → CCR registry cache → BuildKit daemon B。仅表达功能与流程关系，不是私有部署图。脱敏逻辑图 · 功能与流程GitLab CIBuildKit daemon ACCR registry cacheBuildKit daemon B职责关系示意 · 不含内部地址与私有部署细节历史成果与验证边界见下文
脱敏逻辑图：仅展示已记录的功能关系，不代表客户私有部署或当前运行状态。

关键流程

验证从空节点开始执行构建并 export 缓存，再由另一 daemon import，逐层观察 CACHED 结果。随后检查 test、prod 的 deploy job，确认缓存复用能进入完整交付链路，而非仅在同一节点反复构建时生效。

工程取舍

远程缓存需要显式的发布与消费路径，工具链变化也可能改变可复用结果。采用版本单点锁定便于追踪变化；验收则选择跨 daemon 场景，减少把单机残留缓存误判为远程复用成功的可能。

成果与证据口径

2026-08-25 的记录显示跨 daemon 全层 CACHED 验证通过并上线 prod；当时 test / prod deploy job 为 80s / 110s，目标不超过 300s，单组件单 tag 缓存约 381 MiB。这些是历史验收样本，不能外推为所有项目、所有提交的恒定耗时。