Docker镜像加固实战：为AI基准测试注入运行时层

原文：https://dev.to/humzakt/docker-image-hardening-for-ai-benchmarks-14c7（作者 @humzakt）

AI编程基准测试使用数十种编程语言评估代理：Rust、Go、JavaScript、Python、C++等。每个任务都在一个Docker镜像内运行，该镜像包含一个特定的代码仓库快照——即代理必须修改以通过测试的确切代码库。问题在于：许多这样的镜像从未设计为承载代理运行时。它们可能缺少Python、拥有损坏的Git历史记录，或者未包含代理执行所需的依赖项。当代理进入一个损坏的容器时，它会无休止地探索，耗尽整个调用预算却毫无进展。本文将描述我们如何加固镜像流水线以防止这种情况发生。

问题：损坏的容器，浪费的算力

基准测试任务镜像来自多种来源。有些是为单一语言精心策划的。另一些是从公共仓库自动生成的。共同点在于：它们都专注于任务——要编辑的代码、要运行的测试——而不是将在其中运行的代理。代理运行时基于Python，它需要Git进行版本控制、一个可用的Shell以及一个可预测的环境。一个纯Rust镜像没有Python。一个精简的Alpine镜像可能缺少Git或具有非标准的目录结构。一个从浅克隆构建的镜像可能包含损坏的.git目录，导致git status和git diff命令失效。

在一次生产评估中，我们观察到代理在部分任务上持续运行数小时。日志显示反复出现启动运行时失败的尝试，或者代理在基础设置步骤上循环。根本原因：损坏的容器。代理启动后，检测到异常，尝试修复，失败，然后重试。由于每个任务都有固定的调用预算，每次重试都会消耗预算。等到我们注意到时，相当一部分算力已经花费在了注定不会成功的任务上。

注入运行时层

我们的方法是：通过编程方式为每个任务镜像附加一个运行时层。该层安装带有Python 3.11的Miniconda、代理运行时以及所有共享依赖项。挑战在于，任务镜像涵盖了数十种基础发行版和语言。该层必须是自包含的，并且不能假设特定的基础环境。我们编写了一个构建脚本，该脚本：

发现所有任务镜像（从清单或注册表扫描中获取）
为每个镜像生成一个Dockerfile，该文件以原始镜像为基础（FROM），并附加运行时层
构建并标记新镜像

注入函数很直接。它读取基础镜像名称，编写一个多阶段的Dockerfile来添加运行时，并触发构建：

def inject_runtime_layer(base_image: str, output_tag: str, runtime_path: str) -> bool:
    """Append Python runtime + agent layer to a task image."""
    dockerfile = f"""
FROM {base_image}
USER root
RUN apt-get update -qq && apt-get install -y -qq git curl && rm -rf /var/lib/apt/lists/*
COPY --from=runtime-builder /opt/conda /opt/conda
ENV PATH="/opt/conda/bin:$PATH"
RUN pip install --no-cache-dir -r /agent/requirements.txt
COPY agent/ /agent/
WORKDIR /workspace
"""
    with open("/tmp/Dockerfile.inject", "w") as f:
        f.write(dockerfile)
    result = subprocess.run(
        ["docker", "build", "-t", output_tag, "-f", "/tmp/Dockerfile.inject", "."],
        capture_output=True, text=True, timeout=600
    )
    return result.returncode == 0

runtime-builder阶段（未显示）负责安装Miniconda并预安装代理依赖项。从该阶段复制/opt/conda可以让最终镜像更小，并避免与基础镜像中已有的Python安装冲突。我们在每次评估前对每个任务镜像运行此流程。构建失败的镜像会被记录并排除。

预检验证

注入确保了运行时环境的存在，但无法保证容器本身可用。基础镜像可能存在 .git 目录损坏、文件系统只读或工作目录非标准等问题。我们在运行任何昂贵的评估之前，增加了一个预检验证器：

def validate_image(image: str, repo_path: str = "/workspace") -> tuple[bool, str]:
    """检查镜像是否已准备好供智能体执行。"""
    def run_in_container(cmd: str) -> tuple[bool, str]:
        r = subprocess.run(
            ["docker", "run", "--rm", image, "sh", "-c", cmd],
            capture_output=True, text=True, timeout=30
        )
        return r.returncode == 0, (r.stderr or r.stdout or "").strip()

    checks = [
        ("image_exists", lambda: (subprocess.run(["docker", "inspect", image], capture_output=True).returncode == 0, "")),
        ("git_repo", lambda: run_in_container(f"test -d {repo_path}/.git && git -C {repo_path} status")),
        ("python_available", lambda: run_in_container("python3 --version")),
        ("agent_start", lambda: run_in_container("python3 -c 'import agent; print(\"ok\")'")),
    ]
    for name, check in checks:
        ok, msg = check()
        if not ok:
            return False, f"{name}: {msg}"
    return True, ""

每项检查都在一个临时容器中运行。image_exists 验证镜像是否可拉取。git_repo 确保在预期路径存在一个有效的 Git 仓库。python_available 确认 Python 3 位于 PATH 中。agent_start 导入智能体模块以捕获缺失的依赖或导入错误。如果任何检查失败，我们会记录任务 ID 和原因，然后跳过该任务。该任务永远不会启动智能体。

预检验证作为独立作业在主评估之前运行。我们从失败任务中生成跳过列表，并将其传递给运行器。效果立竿见影：我们停止在那些结构上就不可能完成的任务上浪费调用预算。

跳过列表与完成状态检测

某些镜像会反复验证失败。每次运行都重新构建它们是浪费的。我们维护了一个持久化的跳过列表——一个记录已知镜像损坏的任务 ID 的文件或数据库表。运行器在调度任务前会查阅此列表。如果任务在跳过列表上，则不会运行。我们还会检测已完成的任务。每个任务会产生一个轨迹文件（智能体采取的动作序列）和一个预测文件（最终答案）。如果一个任务的这两个文件都存在，我们在重运行时也会跳过它：

#!/bin/bash
# 在评估运行器中
SKIP_LIST="config/known_broken_images.txt"
OUTPUT_DIR="results/run_001"

run_task() {
    local task_id=$1
    local image=$2

    # 跳过已知损坏的任务
    if grep -q "^${task_id}$" "$SKIP_LIST" 2>/dev/null; then
        echo "SKIP (broken): $task_id"
        return 0
    fi

    # 跳过已完成的任务
    if [[ -f "$OUTPUT_DIR/${task_id}/trajectory.json" && -f "$OUTPUT_DIR/${task_id}/prediction.json" ]]; then
        echo "SKIP (done): $task_id"
        return 0
    fi

    # 运行验证，然后执行智能体
    if ! validate_image "$image"; then
        echo "$task_id" >> "$SKIP_LIST"
        echo "SKIP (validation failed): $task_id"
        return 0
    fi

    docker run --rm -v "$OUTPUT_DIR:/out" "$image" agent_run "$task_id"
}

随着我们遇到新的故障，跳过列表会不断增长。完成状态检测使我们能够恢复中断的运行，而无需重做已完成的任务。两者结合，减少了冗余工作，并防止有问题的任务到达智能体。

事件与修复

在一次生产评估中，我们注意到一个子集任务消耗了不成比例的计算资源。智能体会运行数小时，达到调用限制后退出，而没有产生有效的轨迹。初步分诊指向任务运行缓慢或问题难度大。更深入的检查揭示了真正的模式：相同的任务 ID 在失败日志中反复出现，且失败发生得很早——通常在智能体最初几个动作内。这些容器从一开始就是坏的。

我们在流程中增加了预检验证。下一次运行对所有镜像进行了预验证。大约 12% 的任务未通过验证。我们将这些任务加入跳过列表，并重新运行评估。浪费的计算量急剧下降。智能体不再在不可能的任务上空转。评估在远少于之前的时间内完成，并且我们确信剩余的失败是真正的智能体能力局限，而非基础设施问题。

经验总结

先验证，再运行。 昂贵的运行时操作应由廉价的预检查来守护。针对每个镜像的 30 秒验证，相比数小时的智能体执行时间而言微不足道。尽早失败，提前跳过。

让运行时注入层自包含。 任务镜像千差万别。我们注入的运行时层不能预设特定的 Ubuntu 版本、Python 版本或任何特定工具链。它必须自带所需的一切依赖。这虽然会增大镜像体积，但能从根本上消除一大类环境类 Bug。

持久化跳过列表。 损坏的镜像往往会持续保持损坏状态，直到有人修复上游源。将失败记录存储在跳过列表中，可以避免每次运行都重复验证和重复失败。当镜像被重新构建或修复后，应更新此列表。

完成检测以实现幂等重试。 评估任务常会中断。可能是网络故障、节点被抢占、或是人为取消。如果运行器能检测到已完成的任务并跳过它们，重试的成本就会变得很低。轨迹文件和预测文件就是天然的完成信号。

为 AI 基准测试进行 Docker 镜像加固，是一份不那么光鲜的工作。没人会写篇博客来炫耀自己如何修复损坏的 .git 目录。但这正是区分一个能顺利完成的评估，与一个在注定失败的任务上白白浪费预算的评估的关键。这里的工程决策——注入运行时层、优先进行验证、智能跳过——适用于任何需要大规模运行不受信任或异构容器的系统。

原文：https://dev.to/humzakt/docker-image-hardening-for-ai-benchmarks-14c7（作者 @humzakt）