人工智能AI Agent代码智能体自主智能体MCP ClientsCLI【免费下载链接】atomcodeClaude Code 的开源替代方案。连接任意大模型编辑代码运行命令自动验证 — 全自动执行。用 Rust 构建极致性能。 An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get Started项目地址https://gitcode.com/atomgit_atomcode/atomcode点击查看免费下载本篇技术指南以 atomcode 仓库中crates/atomcode-review/rules/dockerfile.md的语言评审清单为核心系统讲解 AtomCode 只读代码评审 agent 在审查包含 Dockerfile 的变更批次时会重点检查的三类问题安全root 运行、密钥烘焙、未固定镜像标签、正确性与镜像体积缓存失效顺序、apt 清理、层合并、运行时shell 形式 CMD/ENTRYPOINT 的信号吞噬、EXPOSE/healthcheck/WORKDIR。读完本文你将掌握 Dockerfile 评审的完整检查框架了解这些规则如何被注入到评审任务的系统提示中并能对照仓库内真实 Dockerfile 实例自查镜像构建配置。一、规则从何而来Dockerfile 评审规则在 AtomCode 中的运作机制crates/atomcode-review是 AtomCode 的只读代码评审特化层L2它把中立内核atomcode-kernel与能力层atomcode-capabilities组装成一个只读评审 agent。与评审语言规则相关的关键机制位于 rules.rs规则文档编译期内置crates/atomcode-review/rules/*.md是语言规则的单一事实来源通过include_str!编译进二进制见 rules.rs 中的RULE_DOCS表。dockerfile.md即其中的(dockerfile, include_str!(../rules/dockerfile.md))条目。文件名匹配评审 agent 从 diff 的 b/path行解析变更文件集合然后用MATCHERS有序表做首匹配。Dockerfile 相关规则覆盖三类文件名形态见 rules.rsdockerfile无扩展名如Dockerfiledockerfile.*如Dockerfile.dev、Dockerfile.prod*.dockerfile如service.dockerfile 匹配时对小写化的文件名做通配匹配因此大小写变体也能命中。作用域隔离注入render_rules_sectionrules.rs把匹配到的规则按文件分组渲染为## Targeted review focus for this batch小节每组用### Applies to: 文件列表标明作用域同一规则文档只渲染一次——保证混合语言批次中 Go 规则不会污染 Dockerfile 评审、SQL 规则不会污染 Go 文件。拼装进评审任务在code_review工具的执行路径中review_tool.rs评审任务由「带行号的 diff 语言规则小节 影响面计划 diff 原文」拼接而成Review the following changes. Report each issue via the report_finding tool ... {rules} ← render_rules_section 的输出含 dockerfile 规则 {impact_plan} ← render_review_impact_plan 的确定性影响面计划 DIFF {annotated} ← 带行号标注的 diffCLI 入口atomcode review同样会注入规则小节并在 stderr 打印可观测信息[rules] injected for N changed file(s) (M chars)或[rules] no language rules matched the changed files见 review.rs。理解了注入机制后下面逐条拆解dockerfile.md的具体检查清单。二、安全检查容器根基处的三个高危点原文档的#### security小节包含三类必须优先处理的安全问题1. 以 root 运行缺少USERRunning as root (missingUSER)容器默认以 root 身份运行进程。一旦应用被攻破攻击者获得的就是容器内最高权限叠加容器逃逸面风险进一步放大。评审规则要求在镜像中显式声明USER指令切换到非特权用户。仓库实证AtomCode 自己的 daemon 镜像严格遵守了这条规则。看 Dockerfile-DaemonRUN useradd -r -s /bin/bash atomcode创建系统用户atomcode后daemon 二进制安装在/usr/local/bin/atomcode-daemon最终以该非 root 用户为运行主体。反例则是COPY dist/...与RUN mv ...阶段的构建期 root 操作——这些属于构建时必要的特权步骤但运行时进程绝不继承 root。评审清单关注的是最终镜像的默认运行用户是否仍是 root。2. 密钥烘焙进镜像层ARG/ENV携带凭据、COPY密钥文件secrets baked into layers (ARG/ENVwith credentials,COPYof secret files)Docker 镜像由多层构成每一层都是可被docker history检视的不可变文件系统快照。以下三种做法会把机密永久固化进镜像ENV API_KEYsk-xxx或ENV AWS_SECRET_ACCESS_KEY...环境变量写入镜像配置元数据任何人拉取镜像即可docker inspect读出ARG TOKEN...且该值被RUN阶段使用中间层会留下明文COPY .aws/credentials /root/或COPY id_rsa /root/.ssh/密钥文件直接成为镜像层内容。正确替代方案构建密钥优先用 BuildKit 的RUN --mounttypesecret密钥只挂载在构建瞬间、不进层运行期凭据通过-e/--env-file注入或使用容器编排的 Secret 机制ENV只存放非敏感配置并配合docker inspect自查。仓库实证AtomCode 的 compose 部署方案正体现了这一原则——见 docker-compose.ymlAPI Key 通过environment的${ANTHROPIC_API_KEY:-}/${OPENAI_API_KEY:-}变量注入或写入宿主机config.toml见 config-example.toml而不是烘焙进镜像config.toml以只读方式挂载./config.toml:/root/.atomcode/config.toml:ro避免容器意外改写。3. 不可信的镜像与脚本源latest/ unpinned base image tags;curl ... | shof unverified scripts;ADDof remote URLs (preferCOPY)三类源不可信问题未固定 tagFROM debian:latest或FROM node:20不带 digest/精确补丁版本意味着每次重建的基座都可能在漂移——上游删 tag、换内容、修复漏洞后镜像语义悄然改变构建不可复现。评审规则倾向固定到具体版本debian:bookworm-slim乃至 digest 级锁定。curl ... | sh管道执行从互联网拉取脚本直接交给 shell中间没有任何完整性校验脚本内容随时可能被替换。评审要求先下载、验签/比对哈希、再执行或使用官方渠道。ADD拉取远程 URLADD除了解压本地 tar 还支持远程 URL 抓取行为隐晦、缺乏校验且引入网络依赖。评审规则明确优先COPYCOPY只做本地文件复制语义单一、可预测。仓库实证TUI 镜像的依赖安装全部走apt-get官方源Dockerfile-TUI基础镜像固定为debian:bookworm-slimDockerfile-Daemon没有curl | sh、没有ADD远程 URL——与规则清单完全一致。唯一的外部下载是COPY dist/...本地构建产物属可信路径。4. 全量复制丢入无关/密钥文件缺少.dockerignoreCOPY . .pulling in unwanted/secret files (missing.dockerignore)COPY . .会把构建上下文context中一切文件都拷进镜像包括.git/目录仓库完整历史、可能含旧密钥本地开发文件.env、*.pem、id_rsa、.npmrc、credentials无关产物node_modules、target/、dist/、日志文件。评审规则要求在镜像根目录维护.dockerignore显式排除node_modules、.git、.env、构建产物等路径只让必要文件进入构建上下文。这同时减小 context 传输体积、加快构建。三、正确性与镜像体积层策略的两大核心问题原文档的#### correctness / size小节聚焦层的组织方式对构建正确性和最终体积的影响。1. 缓存失效顺序Cache invalidation order (COPYof source before dependency install)Docker 构建缓存按 Dockerfile 指令顺序逐层判定某层输入变化该层及其后所有层全部失效重建。最常见的失效陷阱是先COPY源代码、后安装依赖# 错误任何源码改动都会使下方 apt/pip/npm 依赖层全部失效每次都重装 COPY . . RUN apt-get update apt-get install -y ... RUN pip install -r requirements.txt# 正确先拷贝依赖清单变化频率低安装依赖再拷贝源码变化频率高 COPY requirements.txt . RUN pip install -r requirements.txt COPY . .评审规则关注的就是依赖安装是否被放在高变化率的源码COPY之后从而浪费构建缓存。仓库实证Dockerfile-Daemon 将apt-get install ca-certificates放在任何业务COPY之前且镜像基于固定的debian:bookworm-slim基座与系统包层长期稳定命中缓存业务二进制COPY dist/v*/atomcode-daemon-*-linux-*在最后阶段才复制配合 buildx 的TARGETARCH参数按平台挑选二进制Dockerfile-Daemon一次构建产出 amd64/arm64 双架构镜像。2. apt 安装未清理、层未合并apt-get installwithout cleaning lists /--no-install-recommendsMissing cleanup creating bloated layers; manyRUNlines where one chained layer is intended两条细则解决的都是镜像体积问题apt-get install不带--no-install-recommendsapt 默认拉取推荐包往往引入大量非必需依赖。加上该标志可显著缩小体积。不清理 apt 列表apt-get update产生的/var/lib/apt/lists/*索引文件会留在层里应通过rm -rf /var/lib/apt/lists/*清掉或使用apt-get clean。清理必须放在同一个 RUN 指令内否则清理动作本身只是新增一层之前层里的索引文件依然存在。关键原理删除文件并不能让文件从镜像中消失。Docker 层是叠加的下层中被删除的文件仍占据物理空间只有在下层从未写入过它体积才会真正减小。所以安装 → 清理必须链在同一个RUN中。多个RUN不合并每一条RUN生成一层。零散的RUN apt-get update、RUN apt-get install、RUN rm -rf ...分开写不仅增加层数拉取/存储开销还会让中间层的索引文件残留。应链式合并RUN apt-get update \ apt-get install -y --no-install-recommends \ ca-certificates \ git \ rm -rf /var/lib/apt/lists/*仓库实证两个 daemon Dockerfile 与 TUI Dockerfile 全部采用这种链式写法并带--no-install-recommends和rm -rf /var/lib/apt/lists/*见 Dockerfile-Daemon、Dockerfile-TUI与规则清单逐条对应。四、运行时信号处理、端口声明与工作目录原文档的#### runtime小节虽然只有一条列举但包含三个独立检查点。1. Shell 形式CMD/ENTRYPOINT吞噬信号用 exec / JSON 数组形式Shell-formCMD/ENTRYPOINTswallowing signals (use exec / JSON-array form)Dockerfile 中CMD/ENTRYPOINT有两种写法Shell 形式CMD atomcode-daemon等价于CMD [/bin/sh, -c, atomcode-daemon]。实际运行的进程是sh真正的守护进程变成sh的子进程。docker stop发送的SIGTERM会被sh接住而不转发给子进程导致容器无法优雅停机超时后被SIGKILL强杀——这正是评审规则说的信号被吞掉。Exec / JSON 数组形式CMD [atomcode-daemon]或ENTRYPOINT [atomcode-daemon]让容器 PID 1 直接是目标进程信号直达配合 PID 1 的 reaping 行为可正常处理SIGTERM/SIGINT实现优雅关闭。仓库实证三个 Dockerfile 全部使用 JSON 数组形式——Dockerfile-Daemon 的ENTRYPOINT [atomcode-daemon]、Dockerfile-TUI 的ENTRYPOINT [atomcode]信号可直达守护进程与 TUI 进程。2. 缺失EXPOSE/ healthcheckmissingEXPOSE/ healthcheck where relevantEXPOSE声明容器监听的端口不改变实际监听行为但传递意图、便于编排系统发现。daemon 监听 13456 端口Dockerfile-Daemon 中有EXPOSE 13456。healthcheck为常驻服务声明健康探针。compose 部署中docker-compose.yml用bash /dev/tcp探活GET /health——注意注释说明镜像基于 debian slim 没有 curl/wget所以用 bash 内建能力做 TCP 探活而基础镜像层面未在 Dockerfile 内写HEALTHCHECK指令属于相关场景下建议补充的可评审点。3. 未设置WORKDIRWORKDIRnot set缺少WORKDIR时容器默认工作目录是/后续RUN/CMD的相对路径都基于根目录易产生路径歧义与权限问题。评审规则要求显式设置WORKDIR。仓库实证Dockerfile-Daemon 先设WORKDIR /home/atomcode配合刚创建的非 root 用户最终又设WORKDIR /workspace作为挂载项目代码的固定目录compose 中./projects:/workspace即映射此处见 docker-compose.yml。五、实战自查清单按 diff 行号逐项核对综合以上规则评审 agent 面对 Dockerfile 变更时会按以下顺序检查每项均可锚定到具体 diff 行类别检查项判定要点仓库参考实例安全USER指令最终运行用户是否为 rootDockerfile-Daemon 创建atomcode用户安全密钥烘焙ARG/ENV/COPY是否带入凭据docker-compose.yml 运行期注入安全镜像/脚本源是否latest、curl \| sh、ADD远程 URL固定debian:bookworm-slim、全COPY安全.dockerignoreCOPY . .是否缺少排除规则—正确性/体积缓存顺序依赖安装是否在源码COPY之后Dockerfile-Daemon 先装系统包正确性/体积apt 清理是否--no-install-recommends 链式rm -rfDockerfile-TUI正确性/体积层合并多个RUN是否可链成一层同上链式写法运行时信号处理CMD/ENTRYPOINT是否 JSON 数组形式Dockerfile-Daemon运行时端口/探针常驻服务是否EXPOSE/healthcheckEXPOSE 13456 compose healthcheck运行时工作目录是否显式WORKDIRDockerfile-Daemon六、规则的定制与开关--rules-dir与--no-rulesDockerfile 评审规则不是写死的AtomCode 提供两条 CLI 定制通道定义见 review.rs--rules-dir dir用指定目录下的name.md覆盖同名内置规则如dir/dockerfile.md。load_rule_doc的优先级是--rules-dir/name.md存在且非空 → 覆盖内置否则回退到编译进二进制的默认文档见 rules.rs。这意味着你可以针对团队内部规范扩展 Dockerfile 检查项例如强制固定 digest、强制多阶段构建无需重新编译。对应测试rules_dir_overrides_builtin验证了这一覆盖行为rules.rs。--no-rules完全禁用内置语言规则注入用于需要干净提示词的 prompt A/B 实验见 review.rs 中if !args.no_rules分支。此外还有--append-system-prompt/--append-system-prompt-file可以追加团队级评审指令而不替换内置 reviewer 指令review.rs适合把Dockerfile 必须使用多阶段构建之类的仓库规范挂在内置规则之后。七、规则注入后的落地结构化 findings 输出规则小节进入评审任务后评审 agent 依据内置 reviewer personapersona.rs逐项调查 diff并通过report_finding工具输出结构化发现。每条 finding 携带file_path、line_start、line_end、priorityP0–P3、confidence0.0–1.0、suggestion等字段。对照本节规则典型的 Dockerfile findings 形态是P0/P1安全docker run进程以 root 运行无USERENV/COPY烘焙密钥从不可信 URLcurl ... | sh。P2正确性/体积依赖安装在源码COPY之后导致缓存失效apt-get install缺--no-install-recommends或未链式清理。P3运行时shell 形式CMD吞信号建议改 JSON 数组常驻服务缺 healthcheck 建议补充。这些 findings 在单评审路径下由report.findings()收集在depth: deep模式则按维度扇出多个只读评审者再合并去重见 review_tool.rs 的 fanout 路径最终呈现在atomcode review的评审报告中。结语dockerfile.md用三条简短清单覆盖了 Dockerfile 评审最核心的检查面安全层的用户与密钥与来源可信、体积层的缓存与层组织、运行时层的信号与声明完备性。在 AtomCode 中这份清单通过文件名匹配注入评审任务、按文件作用域隔离、可被--rules-dir热替换并最终沉淀为带行号、带优先级的结构化 findings。仓库内docker/目录下三个真实 Dockerfile 恰好是这套规则的正面样例——固定基础镜像、链式 apt 清理、JSON 数组 ENTRYPOINT、非 root 用户与显式 WORKDIR 一应俱全可作为团队镜像规范的对照范本。赞分享人工智能AI Agent代码智能体自主智能体MCP ClientsCLI【免费下载链接】atomcodeClaude Code 的开源替代方案。连接任意大模型编辑代码运行命令自动验证 — 全自动执行。用 Rust 构建极致性能。 An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get Started项目地址https://gitcode.com/atomgit_atomcode/atomcode点击查看免费下载相关推荐BuildKit Dockerfile 检查规则 JSONArgsRecommended 详解让 ENTRYPOINT/CMD 正确接收 OS 信号BuildKit Dockerfile 检查规则 JSONArgsRecommended 详解让 ENTRYPOINT/CMD 正确接收 OS 信号 本文基于构建工具云原生后端atomcode-review 语言规则引擎45 条内置评审规则的匹配、分组注入与 --rules-dir 运行时定制atomcode review 语言规则引擎45 条内置评审规则的匹配、分组注入与 rules dir 运行时定制 本文以 crates/atomcode r人工智能AI Agent代码智能体自主智能体MCP ClientsCLIDockerfile安全审计必备Hadolint规则DL3000-DL3061全解析Dockerfile安全审计必备Hadolint规则DL3000 DL3061全解析 Hadolint是一款基于Haskell开发的Dockerfile静态分开发工具代码质量创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考