11、Docker容器化部署：NVIDIA容器工具包安装、拉取JetPack Docker镜像、容器内GPU加速验证

说到Docker，我刚开始接触Jetson平台时，其实挺抗拒的。总觉得多了一层虚拟化，性能肯定有损耗。直到有一次，我在一个项目里需要同时维护三套不同版本的JetPack环境——那叫一个头疼。后来我老老实实用了Docker，嗯，真香。

说白了，Docker容器化部署就是给你的Jetson设备装一个「轻量级虚拟机」。但它不像传统虚拟机那样模拟整个操作系统，而是直接共享宿主机的内核。所以性能损耗极小，几乎可以忽略不计。

核心思路：在Jetson上通过NVIDIA容器工具包（nvidia-docker2），让Docker容器能够直接访问GPU、CUDA、cuDNN和TensorRT等硬件加速资源。

11.1 为什么要在Jetson上用Docker？

我个人习惯，在开始动手之前，先搞清楚「为什么要这么做」。你想想看，Jetson设备通常资源有限，SD卡或eMMC存储空间就那么几十GB。如果每次换项目都要重新刷机、装驱动、配环境，那时间成本太高了。

Docker能解决三个核心痛点：

  • 环境隔离：不同项目依赖不同版本的CUDA、cuDNN、TensorRT，互不干扰
  • 快速部署：镜像打包后，换一台设备直接拉取运行，不用重复配置
  • 版本回退：新版本翻车了？没关系，切回旧镜像就行

我在项目中遇到过最典型的情况：客户要求用JetPack 4.6，但我的新项目需要JetPack 5.0的新特性。以前我得准备两张SD卡来回换，现在一个docker run就搞定了。

11.2 NVIDIA容器工具包安装

要在Jetson上使用Docker调用GPU，必须先安装NVIDIA容器工具包。这个工具包的作用，就是让Docker容器能「看到」宿主机上的NVIDIA驱动和CUDA库。

11.2.1 安装Docker Engine

JetPack系统默认可能没装Docker，或者装的是旧版本。我们先确认一下：

# 检查Docker是否已安装
docker --version

# 如果没装，用apt安装
sudo apt update
sudo apt install -y docker.io

# 启动Docker服务并设置开机自启
sudo systemctl enable docker
sudo systemctl start docker

# 将当前用户加入docker组（避免每次sudo）
sudo usermod -aG docker $USER
# 退出终端重新登录，或者执行 newgrp docker 生效

小提示：加入docker组后，记得重新登录或执行newgrp docker。我曾经忘了这一步，结果一直报权限错误，排查了半天才发现是组权限没刷新。

11.2.2 安装nvidia-docker2

接下来安装NVIDIA容器运行时。这是关键步骤：

# 添加NVIDIA容器工具包仓库
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -
curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list

# 更新并安装
sudo apt update
sudo apt install -y nvidia-docker2

# 重启Docker服务
sudo systemctl restart docker

安装完成后，验证一下是否生效：

# 运行一个测试容器，检查nvidia-smi是否可用
docker run --rm --runtime=nvidia nvidia/cuda:11.4-runtime nvidia-smi

如果能看到GPU信息输出，说明安装成功。如果报错，大概率是仓库源的问题。我建议直接用Jetson官方源，别折腾第三方源。

注意：Jetson平台是ARM架构（aarch64），不要拉取x86_64的CUDA镜像。一定要用nvidia/cuda:11.4-runtime-ubuntu20.04这种带ARM标签的版本，或者直接用NVIDIA官方为Jetson定制的镜像。

11.3 拉取JetPack Docker镜像

NVIDIA官方为Jetson提供了专门的Docker镜像，这些镜像已经预装了JetPack的核心组件：CUDA、cuDNN、TensorRT、OpenCV等。我们不需要自己从头搭建。

11.3.1 官方镜像仓库

镜像托管在NVIDIA NGC（NVIDIA GPU Cloud）上。拉取方式如下：

# 登录NGC（可选，公开镜像不需要登录）
docker login nvcr.io

# 拉取JetPack 5.0.2的L4T（Linux for Tegra）基础镜像
docker pull nvcr.io/nvidia/l4t-base:r35.1.0

# 拉取带CUDA和TensorRT的完整镜像
docker pull nvcr.io/nvidia/l4t-ml:r35.1.0-py3

常用的镜像标签对照表：

镜像名称 标签示例 包含内容 适用场景
l4t-base r35.1.0 基础Ubuntu + L4T驱动 自定义环境搭建
l4t-ml r35.1.0-py3 CUDA + cuDNN + TensorRT + OpenCV + Python3 机器学习/深度学习
l4t-pytorch r35.1.0-pth1.13-py3 l4t-ml + PyTorch 1.13 PyTorch项目
l4t-tensorflow r35.1.0-tf2.11-py3 l4t-ml + TensorFlow 2.11 TensorFlow项目

我的建议：如果只是做推理部署，用l4t-ml就够了。它包含了大部分常用库，体积适中。如果要做训练，再考虑l4t-pytorch或l4t-tensorflow。别一上来就拉最大的镜像，下载慢不说，很多库你可能根本用不上。

11.3.2 国内加速拉取

如果你在国内，直接从NGC拉取镜像可能会很慢。我一般用两种方法加速：

  • 方法一：配置Docker镜像加速器（如阿里云、中科大源）
  • 方法二：先在一台有梯子的电脑上拉取，然后docker save导出，再docker load导入到Jetson
# 配置Docker镜像加速（以阿里云为例）
sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json <<-'EOF'
{
  "registry-mirrors": ["https://你的加速地址.mirror.aliyuncs.com"]
}
EOF
sudo systemctl daemon-reload
sudo systemctl restart docker

11.4 容器内GPU加速验证

镜像拉取完成后，我们来验证一下容器内是否能正常使用GPU加速。这一步很关键，别等到跑模型时才发现GPU没生效。

11.4.1 启动容器并挂载资源

# 启动l4t-ml容器，挂载GPU和共享内存
docker run --runtime=nvidia -it --rm \
  --shm-size=8g \
  --volume /tmp/argus_socket:/tmp/argus_socket \
  --volume /etc/enctune.conf:/etc/enctune.conf \
  nvcr.io/nvidia/l4t-ml:r35.1.0-py3 \
  /bin/bash

参数说明：

  • --runtime=nvidia：指定使用NVIDIA容器运行时
  • --shm-size=8g：增加共享内存大小，PyTorch多进程训练时需要
  • --volume：挂载摄像头和编码器相关设备文件

11.4.2 验证CUDA可用性

进入容器后，执行以下命令：

# 检查CUDA版本
nvcc --version

# 检查nvidia-smi（容器内可能没有这个命令，但可以安装）
apt update && apt install -y nvidia-smi
nvidia-smi

# 或者直接写一个Python脚本来验证
python3 -c "import torch; print('CUDA available:', torch.cuda.is_available()); print('Device count:', torch.cuda.device_count())"

如果输出显示CUDA available: True，说明GPU加速已经生效。

常见坑：有时候torch.cuda.is_available()返回False，但nvidia-smi能正常显示GPU。这通常是因为PyTorch版本和CUDA版本不匹配。我遇到过好几次，解决方案是重新安装对应JetPack版本的PyTorch wheel包。

11.4.3 运行TensorRT推理测试

为了更全面地验证，我习惯跑一个TensorRT的推理示例：

# 进入容器后，运行TensorRT自带的示例
cd /usr/src/tensorrt/samples/sampleMNIST
make
./sampleMNIST

# 或者用Python API测试
python3 -c "
import tensorrt as trt
print('TensorRT version:', trt.__version__)
# 创建一个简单的builder
builder = trt.Builder(trt.Logger(trt.Logger.WARNING))
network = builder.create_network()
print('TensorRT network created successfully')
"

如果能看到TensorRT版本号和网络创建成功的消息，说明整个加速链路都通了。

11.5 知识体系总览

下面这张图总结了Docker容器化部署的核心流程和组件关系：

Docker容器化部署知识体系 宿主机（Jetson硬件 + L4T驱动 + Docker Engine） 包含：GPU驱动 | CUDA Runtime | cuDNN | TensorRT | 摄像头/编码器设备 nvidia-docker2 容器运行时 作用：将宿主机GPU资源映射到容器内部 Docker容器（JetPack镜像） CUDA / cuDNN TensorRT OpenCV / VPI PyTorch/TF 容器内应用直接调用GPU加速，性能接近裸机 验证：nvidia-smi / torch.cuda / TensorRT示例

11.6 实用技巧与避坑指南

最后分享几个我在实际项目中积累的经验：

  • 镜像不要贪大：l4t-ml镜像大概3-4GB，l4t-pytorch可能到6GB以上。Jetson的存储空间很宝贵，按需拉取。
  • 容器内时间同步：有时候容器内的时间会和宿主机不一致，导致证书验证失败。启动时加上-v /etc/localtime:/etc/localtime:ro可以解决。
  • 持久化数据：容器销毁后数据就没了。记得用-v挂载宿主机目录来保存模型、日志等数据。
  • 多容器通信：如果同时跑多个容器（比如一个做推理，一个做数据预处理），用docker network create创建自定义网络，让容器之间通过容器名通信。

曾经踩过的坑：有一次我拉取了x86架构的CUDA镜像，在Jetson上运行直接报exec format error。折腾了半天才发现是架构不匹配。记住，Jetson是ARM架构，镜像标签里一定要带arm64或aarch64标识。

好了，Docker容器化部署这部分就讲到这里。你按照上面的步骤操作，应该能顺利在Jetson上跑起带GPU加速的容器。如果遇到问题，多看看docker logs的输出，大部分错误信息都能指引你找到方向。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →