Hermes Agent容器镜像安全避坑：3个习惯锁死基础镜像
【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent
某天生产环境的 Hermes Agent 容器拉了个新镜像，基础镜像里 SQLite 带一个已知损坏 bug，重启一次数据库就悄悄坏了。
复盘下来，原因大多是同样三件事：基础镜像没锁版本、镜像里的代码目录可写、上线后没人扫漏洞。下面跟着 Hermes Agent 项目 Dockerfile 的真实做法，把选基础镜像、构建加固、上线后维护三个环节过一遍。
选什么基础镜像：够用就好，别图省事 🧐
版本标签写死，别信"仓库给什么算什么"
项目里写的是FROM debian:13.4，连没有补丁版本号的镜像都直接锁摘要：
FROM debian:13.4 FROM node:26-bookworm-slim@sha256:9e6f93…latest是个滚动指针，今天拉和明天拉可能不是同一个镜像。想"常新"的话，建议写个小任务定期查上游，然后开 PR 手动升版本，别把标签直接写进 Dockerfile。
按负载选镜像，别挑最大的
项目的做法是"精简打底 + 搬运"：用 slim 版 Debian 当底座，只把官方镜像里需要的uv、node二进制拷进来。如果你有 GPU 推理需求，再考虑 CUDA 类基础镜像；没有就别硬塞。攻击面越小，后面要养的东西越少。
组件带已知 bug，就锁一个自编译补丁版
Debian 13 自带的 SQLite 有个 WAL 重置 bug，发行版又不肯回移补丁。项目单独开个构建阶段编译钉死版本的 libsqlite，先校验源码包 sha256，再用自检脚本验证补丁真的生效。核心组件踩坑时，这比等发行版修更靠谱。
要点：小而专的基础镜像，版本和摘要都锁死。
构建时怎么加固：Dockerfile 里越短越好 🛡️
Dockerfile 里最该加的三行
RUN useradd -u 10000 -m -d /opt/data hermes COPY --chmod=a+rX,go-w . . ENV HERMES_DISABLE_LAZY_INSTALLS=1非 root 用户跑；COPY 时用--chmod顺手把代码目录变只读（省掉事后全仓库遍历改权限）；禁止运行时懒安装，免得某个插件乱装包把 agent 自己的 venv 改坏。
数据进 volume，代码目录保持不可变
VOLUME只声明数据目录；运行时真需要补装包时，走数据卷下的可写目录。这个目录只能往导入路径里"加"东西，不可能遮蔽核心模块，代码目录的只读保证因此不失效。
下载的东西全部做校验
SQLite 源码包、进程管理器 tarball，全部先sha256sum -c通过才解压；下载用curl --retry而不是ADD，CDN 抖一下不至于毁掉一次 45 分钟的构建。供应链风险往往不是"被人投毒"，而是"拉了一个你不知道的文件"。
要点：权限锁死，代码目录只读，数据分开放。
上线后怎么养：别让镜像自生自灭 🔄
上线之后，你要养的是跑在上面的实例和版本。
让 CI 每周扫一次你的锁文件
项目里有个工作流（.github/workflows/osv-scanner.yml）干两件事：每次 PR 跑一遍，加一个每周 cron 扫 main，拿uv.lock这类锁文件去比对漏洞库。注意它是只检测、不改 pin——升不升、什么时候升，人来定。这种"只提醒不动手"的接法，对稳定性伤害最小。
基础镜像更新后别忘重跑测试
项目的docker.yml会在 amd64 和 arm64 两种架构上分别构建镜像，测试通过才允许发布，谁改了基础镜像 tag 都会自动触发一遍。没有多架构矩阵也没关系，建议每次基础镜像更新后至少跑一遍冒烟测试。
把构建 commit 烤进镜像
项目会把构建时的 commit SHA 写进镜像，生产出问题一条命令就能说出"我现在到底跑的是哪个版本"，而不是靠猜。
要点：每周扫漏洞，更新必测试，版本可追溯。
发布前把这份自查清单过一遍：
- 所有
FROM都写了具体版本标签，没有latest - 运行时用户非 root，代码目录只读
- 依赖走锁文件加固定版本，下载文件带校验
- 每周漏洞扫描，只提醒、不自动改 pin
- 镜像烤了构建 commit，出问题能追到版本
【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
