科研计算对结果可复现性的要求极高，但研究者在不同机器、不同时间运行的同一套数值计算代码，常因底层库版本、编译器优化选项或系统依赖差异而产生偏离。Docker 作为一种轻量级容器化技术，能够将实验所需的操作系统环境、科学计算库、自编译二进制文件以及代码本身打包为不可变的镜像，从而在任意支持 Docker 的节点上还原完全一致的运行上下文。这种方式正逐步成为计算化学、天体物理模拟和基因组学分析等领域的标准实践。
为什么科研计算需要容器而不是虚拟环境
Python 的 virtualenv 或 conda 环境只能隔离语言级依赖，无法固定系统级的 BLAS 实现、CUDA 驱动对接方式或 glibc 版本。一篇关于蛋白质折叠自由能计算的论文，若使用了针对特定 CPU 指令集编译的 GROMACS，仅靠 Python 包管理完全无法保证他人复现。Docker 镜像则把整个用户空间快照，包括 /lib、/usr/bin 下的二进制全部固化，消除了“在我机器上能跑”的隐患。
另一个常被忽视的问题是长期存档。课题结题五年后，原服务器操作系统已升级，旧版 MPI 库找不到预编译包。若当初导出过 Docker 镜像并推送到机构镜像仓库，研究者仍可用 docker run 启动当初的 Ubuntu 18.04 加 OpenMPI 3.1 环境，而不必重新解决依赖地狱。相比虚拟机镜像动辄数十 GB，Docker 分层存储让基础科学镜像控制在几 GB，更适合通过学术网络传输。
对于使用 GPU 的深度学习训练或分子动力学模拟，Docker 配合 NVIDIA Container Toolkit 能把宿主机的驱动接口以挂载方式暴露给容器，容器内无需安装完整驱动，仅声明需要的计算能力即可。这比每个用户自己编译适配驱动的方案明显减少了集群管理员的工作量与冲突概率。
构建适合科研的 Dockerfile 与多阶段编译
科研代码往往包含 C++、Fortran 或 Rust 写的核心计算模块，直接写进最终镜像会携带大量编译器和头文件，臃肿且暴露不必要攻击面。多阶段构建让编译在临时阶段完成，只把可执行文件拷贝到精简运行阶段。下面示例展示一个带 Fortran 编译链的气象模拟程序打包方式。
# 第一阶段：编译环境
FROM ubuntu:20.04 AS builder
RUN apt-get update && apt-get install -y gfortran make
&& rm -rf /var/lib/apt/lists/*
COPY src/ /app/src/
WORKDIR /app
RUN make && cp simulate /usr/local/bin/simulate
# 第二阶段：运行环境
FROM ubuntu:20.04
RUN apt-get update && apt-get install -y libgfortran5
&& rm -rf /var/lib/apt/lists/*
COPY --from=builder /usr/local/bin/simulate /usr/local/bin/simulate
ENTRYPOINT ["simulate"]
上述 Dockerfile 中，第一阶段安装了 gfortran 与 make，完成编译后将产物 simulate 复制进第二阶段仅含运行库的镜像。最终镜像不包含编译器，体积从约 400MB 降至 90MB 左右，也更利于在批处理队列中快速分发。
科研镜像还应固定基础镜像 digest 而非仅用标签，例如 ubuntu@sha256:xxxx，避免上游重推相同标签导致隐性变更。同时在构建时通过 --build-arg 传入代码提交哈希并写入 /etc/version，方便事后追溯镜像对应的源代码状态。这种细节在联合发表论文时，能让评审直接核对计算环境。
数据挂载与 docker-compose 参数扫描编排
科研数据常达几百 GB，不应 COPY 进镜像，而应使用卷或绑定挂载。下面的 docker-compose.yml 定义了一个参数扫描服务，把宿主机的 ./dataset 挂到容器 /data，并把输出写回 ./output。
version: "3.8"
services:
scan:
image: registry.ipipp.com/climate-model:1.2
volumes:
- ./dataset:/data:ro
- ./output:/output
environment:
- TEMP_START=280
- TEMP_END=320
command: python run_sweep.py --out /output
在超算或实验室工作站，可以用 shell 循环启动多个 docker run 实例，每个传入不同 -e SEED= 值实现并行蒙特卡洛。由于容器彼此文件系统隔离，不会像直接跑多进程那样互相覆盖临时文件。若集群禁止 root，可改用 Singularity 将 Docker 镜像转成 .sif 文件，其默认用户映射方式更符合 HPC 安全规范，但镜像构建逻辑基本一致。
需要注意，挂载大目录时务必对输入设 :ro 只读，防止计算脚本 bug 误删原始观测数据。输出目录建议按容器 ID 或参数建立子目录，避免多次运行结果混杂。配合 docker stats 可实时监控每个扫描任务的内存与 CPU 占用，及时杀掉内存泄漏的实验分支，比裸跑脚本更易管理资源。
与 Singularity 的取舍及免 root 运行配置
很多高校集群基于 PBS 或 Slurm，且禁止用户拥有 root 权限，原生 Docker 守护进程无法启动。Singularity 直接把容器当成可执行文件，不需要常驻 daemon，更适合这类环境。但它对多阶段构建支持弱，通常先从 Docker 构建再转换：singularity build model.sif docker://registry.ipipp.com/model:1.2。
若必须在有 root 的科研云主机用 Docker，又想限制容器能力，可在 docker run 加 --cap-drop=ALL --security-opt=no-new-privileges，并指定非 root 用户 -u 1000:1000。这样即使计算代码存在漏洞，也难以提权破坏宿主。对于需要 InfiniBand 高速网络的 MPI 任务，还应加 --network=host 与 --ipc=host 减少通信开销，这些在撰写实验手册时应明确记录，才能保证合作者复现时不漏掉关键网络参数。
总体来看，Docker 在可控的科研计算云或组内服务器上能极大降低环境配置成本，而在严格管制的超算中心则可借由 Singularity 兼容层享受同一套镜像红利。关键不在于工具本身，而是把环境定义代码化、版本化，并随论文补充材料公开，才能真正落实可复现科学。