3. Docker基础回顾

在正式进入 Jetson 平台的 Docker 部署之前，有必要先厘清 Docker 的四大核心概念——镜像、容器、仓库、Dockerfile，并理解它们在嵌入式设备（尤其是 Jetson 系列）上与传统服务器环境的显著差异。很多初学者在 Jetson 上遇到权限错误、CUDA 不可用、容器重启后配置丢失等问题，根源往往不是 Docker 命令不熟，而是对“镜像与容器的分层关系”“仓库与镜像标签的对应逻辑”以及“设备文件挂载与特权模式”缺乏系统性认知。本节将从概念原理出发，结合 Jetson 的实际硬件约束，帮助你建立一套适用于嵌入式场景的 Docker 心智模型。

3.1 镜像与容器：分层存储与运行时实例

核心原理：Docker 镜像是一个只读的、分层的文件系统模板。每一层对应 Dockerfile 中的一条指令（如 RUN apt-get install、COPY 等），层与层之间通过联合文件系统（OverlayFS2 或 AUFS）叠加。容器则是镜像的一个可写运行实例——当 docker run 启动时，Docker 在镜像层之上添加一个可写层（容器层），所有文件修改、删除、新增都发生在这个薄薄的可写层中。这意味着：多个容器可以共享同一个底层镜像，各自拥有独立的可写层，互不干扰。

判断方法：使用 docker image history <镜像名> 可以查看镜像的分层构建历史；使用 docker diff <容器名> 可以查看容器可写层相对于镜像层的文件变更。如果容器被删除，可写层随之销毁，所有未提交的修改永久丢失。

3.2 仓库与标签：镜像分发与版本管理

核心原理：Docker 仓库（Registry）用于存储和分发镜像。镜像的完整名称格式为 [仓库地址/]命名空间/镜像名:标签。例如 nvcr.io/nvidia/l4t-base:r36.2.0 中，nvcr.io 是 NVIDIA 的私有仓库地址，nvidia 是命名空间，l4t-base 是镜像名，r36.2.0 是标签。标签不是版本号本身，而是一个可变指针——同一个镜像 ID 可以对应多个标签，也可以被重新打标签。

操作流程：

1. 拉取镜像：docker pull nvcr.io/nvidia/l4t-base:r36.2.0
2. 查看本地镜像：docker images（注意 REPOSITORY 和 TAG 列）
3. 打标签：docker tag nvcr.io/nvidia/l4t-base:r36.2.0 my-jetson-app:latest
4. 推送私有仓库：docker push myregistry.local:5000/my-jetson-app:latest

场景	推荐仓库	说明
Jetson 基础镜像	nvcr.io（NVIDIA NGC）	官方维护，包含 L4T 和 CUDA
团队内部共享	私有 Harbor / Registry	避免公网带宽瓶颈，支持镜像签名
边缘离线部署	本地 tar 文件	docker save 导出，docker load 导入

3.3 Dockerfile：从基础镜像到应用镜像的构建脚本

核心原理：Dockerfile 是一个文本文件，包含一系列指令，Docker 按顺序逐条执行并生成镜像层。关键指令包括：FROM（指定基础镜像）、RUN（执行命令并提交新层）、COPY/ADD（复制文件）、ENV（设置环境变量）、WORKDIR（切换工作目录）、CMD/ENTRYPOINT（定义容器启动命令）。每条 RUN、COPY 都会产生一个新的镜像层，因此合理的层合并能显著减小镜像体积。

Jetson 专用 Dockerfile 示例：

# 使用 NVIDIA L4T 基础镜像（arm64）
FROM nvcr.io/nvidia/l4t-base:r36.2.0

# 设置环境变量，避免交互式安装
ENV DEBIAN_FRONTEND=noninteractive

# 安装系统依赖（合并 RUN 减少层数）
RUN apt-get update && apt-get install -y \
    python3-pip \
    libgomp1 \
    libgl1 \
    && rm -rf /var/lib/apt/lists/*

# 复制应用代码
WORKDIR /app
COPY ./src /app/src

# 安装 Python 依赖
RUN pip3 install --no-cache-dir -r /app/requirements.txt

# 声明挂载点（可选）
VOLUME ["/data"]

# 容器启动命令
CMD ["python3", "/app/src/main.py"]

构建与验证流程：

• 构建：docker build -t my-jetson-app:v1.0 .
• 查看层信息：docker history my-jetson-app:v1.0
• 运行测试：docker run --rm my-jetson-app:v1.0 python3 -c "import torch; print(torch.cuda.is_available())"

3.4 Docker 在嵌入式设备上的特殊性

核心原理：嵌入式设备（如 Jetson）与云端服务器的 Docker 运行环境存在本质差异。云端容器通常只关注 CPU/内存隔离，而 Jetson 容器必须处理 GPU 计算、硬件编解码器、摄像头、GPIO 等外设的访问权限。Docker 默认的隔离机制（Namespace 和 Cgroups）会屏蔽宿主机设备文件，因此需要显式地将设备节点映射进容器。

关键差异对比表：

维度	云端服务器	Jetson 嵌入式设备
CPU 架构	x86_64 为主	arm64（aarch64）
GPU 访问	通常不需要或使用虚拟化	必须通过 nvidia-container-runtime
设备文件	极少需要映射	/dev/nvhost-*、/dev/video*、/dev/ttyTHS*
电源管理	不关心	容器内需考虑功耗限制（nvpmodel）
存储	大容量 SSD	eMMC/SD 卡，空间有限，需精简镜像
内核模块	宿主机独立	容器共享宿主机内核，不能加载自定义模块

设备权限配置方法：

1. 使用 --privileged 模式：最简单但最不安全，容器获得宿主机所有设备访问权。适合开发调试，不建议生产环境。
2. 使用 --device 参数：精确映射单个设备，如 --device /dev/video0:/dev/video0。
3. 使用 --group-add 添加设备组：例如 --group-add video 让容器内进程可以访问摄像头设备组。
4. 结合 nvidia-container-runtime：在 docker run 时添加 --runtime nvidia --gpus all，自动注入 GPU 设备与驱动库。

3.5 案例拆解：Jetson 上部署 CSI 摄像头推理容器

背景与约束：某机器人项目需要在 Jetson Orin Nano 上运行实时目标检测，使用 CSI 摄像头（IMX219）采集图像，通过 TensorRT 加速推理。宿主机已安装 JetPack 5.1.2（L4T r35.4.1），摄像头在宿主机上工作正常（gst-launch-1.0 nvarguscamerasrc ! ... 可预览）。目标是将推理服务容器化，并确保容器内能访问摄像头和 GPU。

初始现象：直接使用 docker run --rm -it nvcr.io/nvidia/l4t-base:r35.4.1 进入容器后，执行 ls /dev/video* 发现设备不存在；尝试运行 CUDA 程序报错 CUDA_ERROR_NO_DEVICE。

分析判断过程：

• 摄像头设备未映射：容器默认看不到宿主机 /dev/video0 和 /dev/video1（IMX219 通常占用两个节点）。
• GPU 不可用：缺少 nvidia-container-runtime 的注入，容器内没有 /dev/nvidia0 和 /dev/nvidiactl。
• L4T 基础镜像本身不包含摄像头驱动库（如 libnvbuf_utils.so），需要额外挂载或安装。

实际操作步骤：

# 1. 构建自定义镜像，安装必要的库
FROM nvcr.io/nvidia/l4t-base:r35.4.1
RUN apt-get update && apt-get install -y \
    libgstreamer1.0-0 \
    gstreamer1.0-plugins-base \
    gstreamer1.0-plugins-good \
    libnvbuf-utils1 \
    && rm -rf /var/lib/apt/lists/*

# 2. 运行容器，映射设备并启用 GPU
docker run -it --rm \
  --runtime nvidia \
  --gpus all \
  --device /dev/video0:/dev/video0 \
  --device /dev/video1:/dev/video1 \
  --device /dev/nvhost-ctrl:/dev/nvhost-ctrl \
  --device /dev/nvhost-ctrl-gpu:/dev/nvhost-ctrl-gpu \
  --device /dev/nvhost-prof-gpu:/dev/nvhost-prof-gpu \
  --device /dev/nvmap:/dev/nvmap \
  --device /dev/nvhost-gpu:/dev/nvhost-gpu \
  --device /dev/nvhost-as-gpu:/dev/nvhost-as-gpu \
  --group-add video \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  -e DISPLAY=$DISPLAY \
  my-jetson-camera:latest \
  /bin/bash

结果对比：映射设备后，容器内 ls /dev/video* 能看到 video0 和 video1；运行 gst-launch-1.0 nvarguscamerasrc ! fakesink 可以正常采集；TensorRT 推理程序成功调用 GPU，帧率从宿主机直跑的 28 FPS 略微下降到 25 FPS（容器开销约 10%）。

风险与代价：手动映射 /dev/nvhost-* 设备节点繁琐且容易遗漏。若 JetPack 版本升级，设备节点名称可能变化。更稳妥的方案是使用 --privileged 配合 --runtime nvidia，但需接受安全风险。

复盘经验：在 Jetson 上调试 Docker 容器时，建议先运行 docker run --rm --privileged --runtime nvidia --gpus all nvcr.io/nvidia/l4t-base:r35.4.1 ls /dev 查看所有设备节点，再逐步收紧权限。同时，将设备映射参数写入 docker-compose.yml 或 Makefile，避免每次输入冗长命令。

3.6 常见误区与总结复盘

误区一：认为 Docker 容器内可以加载内核模块。实际上容器与宿主机共享内核，modprobe 在容器内无效，必须在宿主机加载驱动。

误区二：忽略镜像架构标签。在 Jetson 上拉取镜像时，应优先选择带有 arm64、l4t、jetpack 标签的镜像，避免使用通用 latest 标签。

误区三：容器内数据持久化方案不当。Jetson 的 eMMC 存储寿命有限，频繁写入容器可写层会加速闪存磨损。应使用 -v 挂载宿主机目录或 Docker Volume 存储日志和模型文件。

误区四：忽视 --shm-size 参数。Jetson 默认共享内存为 64MB，多进程推理或 PyTorch DataLoader 容易耗尽共享内存，建议设置 --shm-size=1g。