2、环境准备：安装Docker、配置边缘设备（树莓派/Jetson/ESP32）、搭建开发环境与验证Docker运行

TinyML 模型的部署链路与云端推理有本质差异：边缘设备资源受限、架构多样（ARMv7/ARM64/Xtensa）、运行环境碎片化。Docker 的价值在于将模型运行时、依赖库、系统配置与硬件抽象层打包为不可变镜像，从而在树莓派、Jetson 甚至 ESP32 的异构环境中提供一致的部署体验。本章将围绕“安装 Docker → 配置边缘设备 → 搭建开发环境 → 验证运行”四个环节展开，帮助你在动手部署第一个 TinyML 容器前，建立一套可复现、可排障的工程基线。

上图展示了从宿主机准备到验证运行的完整链路。注意 ESP32 并不支持 Docker，其部署路径是通过 Docker 构建交叉编译工具链，再将固件通过串口或 OTA 刷入设备。因此，本章将 Docker 环境与设备烧录环境分开讨论，避免概念混淆。

2.1 核心原理：为什么边缘部署需要 Docker 与设备分级

TinyML 模型通常以 TensorFlow Lite、PyTorch Mobile 或 ONNX Runtime 格式存在，这些运行时依赖特定版本的底层库（如 libc、libgomp、OpenBLAS）。在边缘设备上，直接使用 pip install 或源码编译极易出现依赖冲突，且不同设备的编译工具链差异巨大。Docker 通过以下机制解决该问题：

• 镜像不可变性：将 Python 解释器、TFLite 运行时、模型文件、推理脚本打包为只读镜像层，确保开发环境与生产环境完全一致。
• 多架构支持：使用 docker buildx 构建 ARMv7、ARM64、AMD64 多平台镜像，在 x86 开发机上交叉构建，在边缘设备上拉取对应架构的镜像。
• 资源隔离：通过 cgroups 限制容器 CPU、内存使用，避免推理进程抢占系统资源导致设备卡死。

然而，并非所有边缘设备都适合 Docker。根据设备能力，我们将部署模式分为三类：

2.2 操作流程：从零安装 Docker 到验证运行

以下操作以树莓派 4B（64位 Raspberry Pi OS）和 Jetson Nano（JetPack 5.0）为例，ESP32 的配置将在 2.3 节单独说明。

步骤一：宿主机基础配置

# 树莓派 / Jetson 通用操作
sudo apt update && sudo apt upgrade -y
# 启用 64 位内核（树莓派需在 /boot/config.txt 中设置 arm_64bit=1）
# 安装必要工具
sudo apt install -y curl ca-certificates gnupg lsb-release

步骤二：安装 Docker 引擎

# 使用官方脚本安装（适用于树莓派和 Jetson）
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

# 将当前用户加入 docker 组，避免每次使用 sudo
sudo usermod -aG docker $USER
newgrp docker

# 验证安装
docker --version
docker compose version

步骤三：配置镜像加速与存储驱动

国内网络环境下，建议配置镜像加速器。同时，Jetson 设备需要额外安装 NVIDIA 容器运行时：

# 配置 Docker 镜像加速（/etc/docker/daemon.json）
sudo mkdir -p /etc/docker
sudo tee /etc/docker/daemon.json <<'EOF'
{
  "registry-mirrors": ["https://docker.m.daocloud.io"],
  "runtimes": {
    "nvidia": {
      "path": "nvidia-container-runtime",
      "runtimeArgs": []
    }
  }
}
EOF

# Jetson 额外安装 nvidia-container-toolkit
sudo apt install -y nvidia-container-toolkit
sudo systemctl restart docker

步骤四：验证 Docker 运行

# 运行官方测试容器
docker run hello-world

# 预期输出包含 "Hello from Docker!" 且退出码为 0
# 检查容器状态
docker ps -a | grep hello-world

2.3 案例拆解：Jetson Nano 部署 TFLite 推理容器

本案例目标是在 Jetson Nano 上运行一个 TensorFlow Lite 图像分类容器，验证 GPU 加速是否生效。实验环境为 JetPack 5.0.2，Docker 20.10.14，nvidia-container-toolkit 1.12。

初始现象：直接运行 docker run --rm -it tensorflow/tensorflow:latest 后，容器内执行 python -c "import tensorflow as tf; print(tf.test.is_gpu_available())" 返回 False，说明容器未使用 GPU。

分析过程：Jetson 的 GPU 架构为 Maxwell/Volta，与 x86 的 CUDA 库不兼容。官方 TensorFlow 镜像基于 x86 构建，无法调用 Jetson 的 GPU。必须使用 NVIDIA L4T（Linux for Tegra）基础镜像，并安装 JetPack 自带的 TensorFlow 版本。

实际操作：

# 1. 拉取 L4T 基础镜像（约 1.2GB）
docker pull nvcr.io/nvidia/l4t-base:r35.1.0

# 2. 编写 Dockerfile
FROM nvcr.io/nvidia/l4t-base:r35.1.0
RUN apt update && apt install -y python3-pip
RUN pip3 install --extra-index-url https://developer.download.nvidia.com/compute/redist/jp/v50 tensorflow==2.11.0+nv22.11
COPY classify.py /app/classify.py
CMD ["python3", "/app/classify.py"]

# 3. 构建并运行
docker build -t jetson-tflite .
docker run --rm --gpus all jetson-tflite

结果对比：加入 --gpus all 后，容器内 TensorFlow 成功识别 GPU（tf.test.is_gpu_available() 返回 True），推理速度从 CPU 的 850ms/帧提升至 GPU 的 120ms/帧。

风险与代价：L4T 镜像体积较大，且必须匹配 JetPack 版本（r35.1.0 对应 JetPack 5.0）。若版本不匹配，会出现 CUDA 库缺失或内核模块加载失败。建议在 Dockerfile 中固定基础镜像的 tag，避免漂移。

2.4 常见误区与总结复盘

在环境准备阶段，学员常犯以下错误，导致后续部署失败：

• 误区一：在 32 位系统上安装 Docker。树莓派旧版系统为 ARMv7，无法运行 ARM64 镜像。务必使用 64 位系统，并检查 uname -m 输出为 aarch64。
• 误区二：忽略 Docker 用户组权限。直接使用 sudo docker 会导致文件权限混乱，且无法在 CI/CD 中复用。应始终将用户加入 docker 组。
• 误区三：ESP32 强行套用 Docker。ESP32 的部署应使用 espressif/idf Docker 镜像进行编译，但烧录必须通过串口或 JTAG，不能将固件打包为容器。
• 误区四：Jetson 使用通用 CUDA 镜像。必须使用 nvcr.io/nvidia/l4t-* 系列镜像，并安装 JetPack 对应的 TensorFlow/PyTorch 版本。