news 2026/8/28 11:33:45

Hermes Agent 容器镜像瘦身:多阶段构建+分层缓存,源码提交省 4-5 分钟

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
Hermes Agent 容器镜像瘦身:多阶段构建+分层缓存,源码提交省 4-5 分钟

Hermes Agent 容器镜像瘦身:多阶段构建+分层缓存,源码提交省 4-5 分钟

【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent

场景:Hermes Agent 容器镜像冷构建 15-45 分钟,源码提交重复付费

上一个纯源码提交(只改了 agent/ 下两行代码)触发了 Hermes Agent 公开容器镜像的全量重建:uv 依赖安装、Playwright 下载 Chromium、npm install、权限全量扫描,全流程 15-45 分钟(视架构与网络)。跑一遍就知道时间花在哪:其中约 4-5 分钟的依赖安装明明已经缓存过,却照样整层重跑。

问题拆成两半:镜像本身重(基础镜像 + Node 26 + ffmpeg + Chromium + 全量 Python 依赖),以及构建链路对"没变的依赖"每次提交重复付费。本文拆解项目 Dockerfile 里的真实优化策略,分三层递进:镜像层瘦身、构建链路加速、运行时收敛。适用环境是 docker buildx 多架构(amd64/arm64)构建,下文数字全部来自 Dockerfile 注释与实测记录。

结论先行:地板体积靠基础镜像解决,重复付费靠构建链路解决,最终产物稳定性靠运行时收敛解决。三者是递进关系,不能互相替代。

镜像层瘦身:多阶段构建只拷产物,不拷工具链

拆出 SQLite、uv、Node 三个构建阶段

Dockerfile 没用 python:3.11 一站式基础镜像,而是拆出三个构建阶段,运行时阶段只拷产物:

  • sqlite_build:源码编译固定版本 SQLite 3.53.4——Debian 13 自带 SQLite 3.46.1 存在上游 WAL reset 损坏 bug,trixie 没有可用的发行版 backport,只能自编译;
  • uv_source:固定 uv 0.11.6 + Python 3.13 的镜像,只拷 uv/uvx 两个二进制;
  • node_source:Node 26 从上游 node:26-bookworm-slim 取(trixie 自带 nodejs 是 20.x,2026 年 4 月已 EOL),bookworm 基座让二进制链接 glibc 2.36,在 trixie(glibc 2.41)上干净运行。

编译器、ca-certificates、源码 tar 包全部留在构建阶段,不进最终镜像。

运行时基座 debian:13.4 + --no-install-recommends 收口

ffmpeg、ripgrep、openssh-client、docker-cli、python3-venv、libolm-dev 等系统包,一个 APT 层装完,同一层内rm -rf /var/lib/apt/lists/*清缓存。一层装、一次清,不产生散落的 apt 层。

这一层做完,镜像里只剩"运行需要的",没有"构建用的"。

构建链路加速:按变更频率重排依赖安装顺序

镜像层瘦身解决地板体积,构建链路加速解决反复付费的问题。层缓存像快递分拣:变动少的包裹放底层货架,上面随便动。Dockerfile 构建链路的关键,就是按"输入多久变一次"重排安装步骤。

manifest-first:锁文件不变,依赖层不重建

旧写法先COPY . .uv sync,任何源码变更都让依赖层失效,纯源码提交要重做 4-5 分钟的依赖工作。现在先只拷pyproject.toml+uv.lock,再uv sync --frozen --no-install-project,依赖层只在锁文件本身变化时重建。项目本体在源码拷入后用uv pip install --no-deps -e .链进 venv,是一次无解析的快速 egg-link。

npm 侧同样结构:根package.json+package-lock.json+ web/ui-tui 的 manifest 先行,npm install --prefer-offline+ Playwright Chromium 安装 +npm cache clean --force合成一层。Playwright 浏览器装进/opt/hermes/.playwright,刻意避开/opt/data卷挂载点,否则构建期安装会被卷覆盖掉。

extras 白名单:torch、wandb 这类重型 git 依赖不进发布镜像

刻意不用--all-extras:那会拉进[rl](atroposlib + tinker + torch + wandb,全是 git 依赖)、[yc-bench][termux-all],没有一个属于公开镜像。必须烤进去的 extra 则显式白名单:anthropic/bedrock/azure-identity(provider 包,容器化环境运行时无 PyPI 访问权限)、hindsight(其 client 懒安装会随容器重建丢失,历史上造成ModuleNotFoundError)、matrix(python-olm 需要源码编译)。

COPY --link --chmod 一步替代 chmod -R 全量扫描

COPY . .后原本要单独跑一遍chmod -R a+rX,go-w,遍历 venv + node_modules + 源码约 3 万个文件,amd64 花 21 秒,arm64 花 222 秒。现在同样的权限在COPY --chmod时一次烙进去,--link再把这一层与父层解耦,缓存更稳。

链路排完,最常见的"纯源码提交"场景基本不再为依赖层付费。

运行时参数收敛:封死 venv,可变状态赶进数据卷

前两层压的是"带什么走",运行时层管"放哪里"。公开镜像把/opt/hermes封成 root 属主、只读,所有可写状态进/opt/data卷。

封 venv + 懒装重定向到数据卷

HERMES_DISABLE_LAZY_INSTALLS=1默认封掉懒安装;opt-in 后端(Firecrawl、Exa 等)的 SDK 留在 lazy_deps,安装目标重定向到HERMES_LAZY_INSTALL_TARGET=/opt/data/lazy-packages。该目录追加在 sys.path 末尾,只能新增模块、不能遮蔽或降级核心模块,封禁保证仍然成立。这一步避开两个历史事故:hindsight-client 懒安装随容器重建丢失引发ModuleNotFoundError,photon sidecar 在只读层上懒执行npm ci撞上EROFS

s6-overlay 接管 PID 1,取代 tini

s6-overlay 3.2.3 成为 PID 1:非阻塞回收 SIGCHLD 僵尸进程,监督主进程、dashboard 与按 profile 动态注册的 gateway。三个 tarball 用curl --retry 3下载并逐包 sha256 校验——ADD不可重试,一次 CDN 抖动就能毁掉整场 15-45 分钟的构建。

运行时收敛做完,镜像变成"只读产物 + 可写数据卷",不再是半成品构建环境。

关键操作演示:优化前 vs 优化后

四段均从 Dockerfile 精简而来。

① 多阶段构建:构建工具链留在构建阶段

# 优化前:单阶段全能,编译器和运行时同住一个镜像 FROM python:3.11 RUN apt-get install -y build-essential && pip install uv COPY . . # 源码变更使之后所有层失效 # 优化后:构建阶段只留产物,运行时只拷二进制 FROM debian:13.4 AS sqlite_build # SQLite 3.53.4 源码编译,修 WAL bug FROM ghcr.io/astral-sh/uv:0.11.6-python3.13-trixie AS uv_source FROM node:26-bookworm-slim AS node_source FROM debian:13.4 # 运行时基座 COPY --from=uv_source /usr/local/bin/uv /usr/local/bin/uv COPY --from=node_source /usr/local/bin/node /usr/local/bin/

② manifest-first:依赖层只认锁文件

# 优化前:先全量拷贝,源码变更 = 依赖全装一遍(4-5 分钟) COPY . . RUN uv sync --extra all # 优化后:先拷锁文件,依赖层只在锁文件变化时重建 COPY pyproject.toml uv.lock ./ RUN uv sync --frozen --no-install-project \ --extra all --extra messaging --extra otlp

③ 权限一步到位:省掉 222 秒的 chmod 全量扫描

# 优化前:chmod -R 遍历约 3 万文件,arm64 要 222 秒 COPY . . RUN chmod -R a+rX,go-w /opt/hermes # 优化后:--link 解耦缓存,--chmod 在拷贝时烙入只读权限 COPY --link --chmod=a+rX,go-w . .

④ 运行时收敛:封 venv,懒装落数据卷

# /opt/hermes 只读且属镜像,懒装目标改指可写卷 ENV HERMES_DISABLE_LAZY_INSTALLS=1 ENV HERMES_LAZY_INSTALL_TARGET=/opt/data/lazy-packages # 该目录追加在 sys.path 末尾:只能新增模块, # 不能遮蔽或降级核心模块,封禁保证不被破坏

收益验证:一张表判断哪些策略值得做

📌 数据均为 Dockerfile 注释中的实测记录。

优化策略量化收益适用判断
多阶段构建只拷产物编译器与源码 tar 不进最终镜像;自编译 SQLite 3.53.4 绕开发行版无 backport有编译阶段 / 需钉系统库版本的镜像
manifest-first 依赖层纯源码提交省 4-5 分钟依赖安装有 uv.lock / package-lock.json 的锁文件驱动项目
extras 白名单[rl] 的 torch/wandb 等重型 git 依赖排除在镜像外功能集合固定的公开镜像
COPY --link --chmod每次构建省 21s(amd64)/ 222s(arm64)权限扫描文件量大的 monorepo、多架构 CI
封 venv + 懒装重定向运行时不再出现 EROFS / ModuleNotFoundError只读代码镜像 + 绑定挂载数据卷

小型单架构服务只做第一行就够,一个下午的事;monorepo + 多架构 CI 五行全做,其中 manifest-first 和 COPY --chmod 是性价比最高的两步。反过来,如果你的容器里真的需要运行时pip install/npm install,就不要做运行时封禁——先想清楚懒装重定向到哪,再封,否则只是把 EROFS 事故再演一遍。

【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/8/28 11:32:21

基于PaddleDetection的足球比赛多目标跟踪系统实战指南

简介:多目标跟踪是计算机视觉领域的核心技术,旨在对视频中的多个目标进行持续检测、识别与轨迹关联。其核心原理通常采用“检测-跟踪”范式,即先利用深度学习模型(如YOLO、Faster R-CNN)进行目标定位,再通过…

作者头像 李华
网站建设 2026/8/28 11:30:09

Hermes Agent 完整上手:从 clone 到配好安全开发环境

Hermes Agent 完整上手:从 clone 到配好安全开发环境 【免费下载链接】hermes-agent The agent that grows with you 项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent AI 代理能自己跑命令、改文件,这件事本身没问题;…

作者头像 李华
网站建设 2026/8/28 11:20:04

Zig Io.Threaded:把多线程并发写日志的锁藏进I/O接口

如果你写过一段多线程日志服务,大概率见过这种场景:两个线程同时往标准输出写一行日志,结果两行内容黏在一起,或者后半行跑到另一行前面,甚至输出顺序完全不可预测。你会下意识地想到“加锁”,但加锁本身又…

作者头像 李华
网站建设 2026/8/28 11:18:45

3 步让编程面试准备内容做进搜索结果前 10

3 步让编程面试准备内容做进搜索结果前 10 【免费下载链接】tech-interview-handbook Curated coding interview preparation materials for busy software engineers 项目地址: https://gitcode.com/GitHub_Trending/te/tech-interview-handbook Tech Interview Handbo…

作者头像 李华
网站建设 2026/8/28 11:17:35

推理大模型测试时扩展:推理模式与可复现评估指南

最近几周在折腾推理大模型的测试时扩展(Test-Time Scaling),一个很直观的感受是:模型本身的能力只是起点,推理阶段的“算力分配方式”对最终效果的影响比想象中更大。同一个模型,采用不同的推理模式&#x…

作者头像 李华
网站建设 2026/8/28 11:17:03

COM-HPC 1.2 Mini:PCIe 5.0与USB4加持的嵌入式边缘计算新方案

COM-HPC 1.2 “Mini”这个新尺寸出来之后,我身边不少做嵌入式硬件选型的朋友都在讨论。这几年工业计算平台的核心矛盾其实很清晰——算力需求往上冲,I/O带宽却卡在PCIe 3.0/4.0时代,机器视觉、边缘AI推理、高速数据采集这些场景,跑…

作者头像 李华