机器学习项目的环境配置一直是团队协作和部署过程中最容易出问题的环节。Python包版本、CUDA工具包、cuDNN库、操作系统底层依赖，任何一个环节出现差异都可能让代码在本地正常运行、在服务器上却报错。Docker通过镜像把整个运行环境固化下来，无论是单机开发还是集群训练，只要使用同一个镜像，就能保证软件栈完全一致。接下来从基础镜像选择、Dockerfile编写、GPU支持和数据持久化几个方面，说明如何搭建一套可复用的机器学习容器环境。
选择合适的基础镜像
构建机器学习镜像的第一步是确定基础镜像。官方Python镜像体积较小，但不包含CUDA和深度学习框架，适合不依赖GPU的纯CPU任务。如果需要使用NVIDIA显卡，应优先考虑nvidia/cuda系列或PyTorch、TensorFlow官方提供的GPU镜像。这些镜像通常已经预装了对应版本的CUDA和cuDNN，省去了手动安装显卡驱动和底层库的麻烦。
例如PyTorch官方镜像pytorch/pytorch:latest已经包含指定版本的CUDA和cuDNN，不需要手动安装显卡驱动，只要宿主机安装了NVIDIA驱动和Container Toolkit即可。选择基础镜像时要注意版本标签，例如pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime表示对应的PyTorch版本、CUDA版本和cuDNN版本。团队内部如果要求统一环境，最好在镜像标签中显式指定版本号，避免使用latest这种浮动标签，否则未来拉取镜像时可能得到不同软件组合。
如果多个项目使用相同的基础环境，可以从一个基础镜像出发，再通过Dockerfile安装公共依赖，形成团队内部的基线镜像。这样既统一了底层库版本，也减少了每个项目重复构建的时间。
编写Dockerfile与依赖管理
Dockerfile用于描述镜像构建过程。下面是一个基于PyTorch基础镜像安装额外Python包的示例。
FROM pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime
WORKDIR /workspace
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt && \
pip install jupyterlab
CMD ["jupyter", "lab", "--ip=0.0.0.0", "--port=8888", "--allow-root"]
上面的Dockerfile中，WORKDIR设置容器内的工作目录，COPY把宿主机上的requirements.txt复制到镜像内，RUN执行pip安装。使用--no-cache-dir可以避免pip缓存占用镜像空间。CMD指令指定容器启动时默认运行的命令，这里启动JupyterLab并监听所有网络接口。注意RUN命令末尾的反斜杠用于换行，实际构建时通常会合并多个命令以减少镜像层数。
为了减小镜像体积，可以合并RUN命令，并在安装完成后清理apt缓存。如果依赖较多，建议使用requirements.txt或environment.yml进行版本锁定，避免构建时间过长。对于需要编译的包，例如一些C扩展模块，可以在构建阶段安装gcc等工具，最后再删除，这是多阶段构建的思路。不过机器学习镜像通常直接使用预编译的轮子，很少需要编译，除非使用特殊版本。
配置GPU支持
要让容器使用宿主机的NVIDIA GPU，需要在宿主机上安装NVIDIA Container Toolkit。以Ubuntu为例，配置软件源后执行安装命令。安装完成后，运行容器时添加--gpus all参数即可将全部GPU暴露给容器。也可以使用--gpus '"device=0,1"'指定显卡。验证方法是在容器内运行nvidia-smi命令。
distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | \ sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart docker
执行完上述命令后，Docker守护进程就能识别NVIDIA运行时。接下来用docker run启动一个带GPU的容器，命令如下。
docker run --rm --gpus all pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime nvidia-smi
如果使用docker-compose，可以在服务配置中添加gpus字段，格式如下。
version: "3.8"
services:
ml:
image: pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime
runtime: nvidia
environment:
- NVIDIA_VISIBLE_DEVICES=all
volumes:
- ./workspace:/workspace
ports:
- "8888:8888"
上述配置中的runtime: nvidia和environment字段告诉容器使用NVIDIA运行时并开放全部GPU。如果只需要特定显卡，可以将NVIDIA_VISIBLE_DEVICES设为逗号分隔的编号，例如0,1。配置好后使用docker-compose up即可启动带GPU的Jupyter服务。
数据持久化与目录挂载
容器默认的文件系统是临时的，容器删除后所有修改都会丢失。训练数据、代码和模型权重需要保存在宿主机或命名卷中。使用-v参数将宿主机目录挂载到容器内，例如将当前目录的data文件夹挂载到容器的/data。
docker run -it --rm --gpus all \ -v $(pwd)/data:/data \ -v $(pwd)/models:/models \ -v $(pwd)/notebooks:/workspace/notebooks \ pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime bash
如果挂载的是代码目录，建议在Dockerfile中使用WORKDIR指定工作目录，并在启动时挂载到相同路径，这样容器内相对路径不会出错。对于大型数据集，挂载可能会影响I/O性能，可以考虑使用Docker卷或直接放在镜像内，但镜像体积会膨胀。通常做法是把只读的数据集单独挂载，把需要频繁写入的模型目录和日志目录挂载到高速存储上。
除了使用-v参数，也可以使用docker volume create创建命名卷，这样数据由Docker管理，便于备份和迁移。在docker-compose中直接声明volumes即可，容器重建后数据不会丢失。
常见问题与优化建议
镜像体积过大是机器学习容器常见的问题。CUDA相关基础镜像通常超过5GB，再加上深度学习框架和依赖，很容易达到10GB以上。可以通过以下方式缓解：使用runtime标签的基础镜像而不是devel标签，其不包含编译工具，体积更小；合并RUN命令减少层数；清理apt缓存和pip缓存；使用多阶段构建将训练好的模型单独拷贝到精简镜像中。
权限问题也经常出现。容器默认以root用户运行，Jupyter等工具可能拒绝root启动，需要添加--allow-root参数，或者在Dockerfile中创建普通用户并切换。如果挂载的宿主机目录权限不匹配，可以在启动时使用--user参数指定UID，或者修改目录权限。对于多人共享同一台开发机的情况，建议为每个用户启动独立容器，避免文件属主混乱。
此外，为了快速启动开发环境，可以使用docker-compose定义服务，把Jupyter、TensorBoard等多个工具组合起来。对于团队协作，将镜像推送到私有仓库，并配合CI流水线自动构建，能进一步提高效率。如果训练任务需要长时间运行，可以使用docker run的--restart=unless-stopped参数让容器在退出后自动重启，或者将任务提交到Kubernetes集群进行调度。
