4、Docker核心概念：镜像、容器、Dockerfile、卷、网络、注册表，以及边缘设备上的资源限制

在TinyML模型的边缘部署场景中，Docker的价值在于将复杂的运行时环境（Python解释器、TensorFlow Lite Micro、OpenCV、传感器驱动库等）与模型权重一起打包成标准化的交付物。然而，边缘设备（如树莓派、Jetson Nano、ESP32网关）与云端服务器存在本质差异：CPU架构多样（ARMv7/ARMv8/x86_64）、内存可能仅有512MB~4GB、存储多为eMMC或SD卡且寿命有限、网络带宽不稳定。因此，理解Docker的六大核心概念，并掌握如何在资源受限环境下正确使用它们，是构建可靠边缘推理服务的前提。本章将逐一拆解这些概念，并重点讨论资源限制的配置策略。

上图展示了Docker三大阶段（构建、运行、分发）与六大核心概念的关系。构建阶段从Dockerfile生成镜像，运行阶段由镜像启动容器并关联卷、网络和资源限制，分发阶段通过注册表实现镜像的跨设备迁移。在边缘场景中，这三个阶段往往分布在不同的机器上：开发者在x86工作站上编写Dockerfile，通过buildx交叉构建ARM镜像，推送到私有注册表，最后在边缘设备上拉取并运行。下面逐一深入每个概念。

4.1 镜像与容器：只读模板与可写实例

核心原理：镜像是静态的、分层的只读文件系统，包含操作系统基础库、运行时、依赖包和模型文件。容器是镜像的运行实例，在镜像层之上增加一个可写层（Writable Layer），所有文件修改、进程写入都发生在这个薄层中。当容器删除时，可写层随之消失，镜像本身不受影响。这种设计使得同一镜像可以启动多个相互隔离的容器，且镜像可以被缓存和复用。

判断方法：使用 docker image ls 查看本地镜像列表，docker ps -a 查看所有容器（包括已停止的）。镜像名称由 仓库名:标签 组成，例如 tinyML-arm64:v1.2。若标签为 latest，通常表示最近构建的版本，但在生产环境应使用具体版本号。

案例拆解：假设你有一个树莓派4B（4GB RAM），需要部署一个TensorFlow Lite图像分类服务。你构建了一个镜像 img-classifier:rpi，大小约800MB。启动容器后，模型文件（约50MB）被加载到内存中，Python进程占用约300MB。此时若再启动第二个容器实例，内存将增加约350MB（共享镜像层，但进程独立）。如果设备内存不足，系统会触发OOM Killer，导致容器被强制终止。因此，在边缘设备上通常只运行一个容器实例，或者使用 --memory 参数限制每个容器的内存上限。

4.2 Dockerfile：从源码到镜像的构建脚本

核心原理：Dockerfile是一个文本文件，包含一系列指令，Docker引擎按顺序执行这些指令并生成镜像层。每条指令对应一个层，层被缓存以便加速后续构建。常用指令包括：FROM（基础镜像）、COPY（复制文件）、RUN（执行命令）、ENV（环境变量）、EXPOSE（声明端口）、CMD（默认启动命令）。

操作流程：编写Dockerfile后，使用 docker build -t 镜像名:标签 . 构建。构建上下文（即 . 指定的目录）会被发送到Docker守护进程，因此应使用 .dockerignore 文件排除不需要的文件（如数据集、日志、.git目录），以减小上下文体积。

# 示例：TinyML推理服务Dockerfile
FROM arm64v8/python:3.9-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple
COPY model.tflite .
COPY inference.py .
ENV MODEL_PATH=/app/model.tflite
EXPOSE 8080
CMD ["python", "inference.py"]

案例拆解：在Jetson Nano上部署YOLOv5s模型时，基础镜像应选择 nvcr.io/nvidia/l4t-base:r32.7.1，因为该镜像包含JetPack的CUDA库。若使用通用 python:3.9 镜像，则无法调用GPU加速。构建时需注意：pip install torch 在ARM上可能没有预编译包，需要从源码编译，耗时较长。此时应利用Docker层缓存——将 requirements.txt 单独复制并安装，避免每次修改代码都重新编译依赖。

4.3 卷与网络：数据持久化与通信桥梁

核心原理：卷（Volume）是Docker管理的持久化存储，独立于容器生命周期。网络（Network）定义了容器之间、容器与宿主机之间的通信规则。Docker提供多种网络驱动：bridge（默认，容器间通过虚拟网桥通信）、host（容器直接使用宿主机网络栈，性能最佳）、none（无网络）。

判断方法：使用 docker volume ls 查看卷列表，docker network ls 查看网络列表。在边缘设备上，若只有一个容器，通常使用 host 网络模式以避免NAT转换开销；若有多个容器需要协作（如推理服务+MQTT网关），则使用 bridge 网络并指定容器名作为主机名。

案例拆解：一个工业质检系统需要将推理结果写入SQLite数据库。若数据库文件存放在容器可写层，容器重建后数据丢失。正确做法是创建卷 sqlite-data 并挂载到 /data 目录：

docker volume create sqlite-data
docker run -d --name inference \
  -v sqlite-data:/data \
  --network host \
  my-inference:latest

同时，若推理服务需要访问宿主机上的USB摄像头（如 /dev/video0），需使用 --device /dev/video0 参数。对于串口设备（如 /dev/ttyUSB0），同样需要显式映射。

4.4 注册表：镜像分发与版本管理

核心原理：注册表（Registry）是存储和分发镜像的服务。Docker Hub是公共注册表，但在边缘场景中，由于网络带宽有限或安全要求，通常搭建私有注册表（如Harbor、Registry 2.0）。镜像通过 docker push 上传，通过 docker pull 下载。

操作流程：首先在边缘设备上登录注册表：docker login registry.example.com:5000。然后拉取镜像：docker pull registry.example.com:5000/tinyML-arm64:v1.0。若设备无法访问外网，可使用 docker save 将镜像导出为tar文件，拷贝到设备后 docker load 导入。

# 在开发机上导出镜像
docker save my-image:latest | gzip > my-image.tar.gz
# 拷贝到边缘设备后导入
gunzip -c my-image.tar.gz | docker load

案例拆解：某工厂有20台边缘设备，需要定期更新模型。若逐台 docker pull，会占用大量带宽。更优方案是：在局域网内搭建一个轻量级注册表（docker run -d -p 5000:5000 --name registry registry:2），开发机推送新镜像到该注册表，边缘设备配置 /etc/docker/daemon.json 中的 insecure-registries 以允许HTTP访问，然后定时执行 docker pull 并重启容器。这样，20台设备只需从局域网拉取，速度可达100MB/s。

4.5 边缘设备上的资源限制

核心原理：边缘设备资源有限，Docker通过Linux内核的cgroups机制提供资源隔离和限制。关键参数包括：--memory（内存上限）、--cpus（CPU配额）、--pids-limit（进程数上限）、--read-only（只读根文件系统）。合理设置这些参数可以防止单个容器耗尽系统资源，导致设备死机。

判断方法：使用 docker stats 实时查看容器资源占用。若容器频繁被OOM Killer终止，说明内存限制过小；若CPU使用率持续100%，可能需要优化模型或增加 --cpus 配额。

案例拆解：在树莓派3B+（1GB RAM）上部署语音唤醒服务。初始启动命令为 docker run -d --name wake-word my-wake:latest，运行30分钟后设备变得卡顿，docker stats 显示容器内存占用达到850MB，系统可用内存仅剩120MB。分析发现，音频特征提取库存在内存泄漏。解决方案：

1. 限制内存：--memory 400m --memory-swap 400m，强制容器在内存超限时触发GC或重启。
2. 设置重启策略：--restart on-failure:5，容器因OOM退出后自动重启，最多5次。
3. 优化代码：在Python中显式调用 gc.collect()，并减少音频缓冲区的重复分配。

调整后，容器内存稳定在350MB左右，设备运行一周未出现卡顿。

4.6 综合实战：构建一个完整的边缘推理服务

下面通过一个完整的案例，将上述概念串联起来。假设你需要在Jetson Nano上部署一个口罩检测服务，模型为TensorRT优化的SSD，输入为USB摄像头视频流。

步骤1：编写Dockerfile（在x86开发机上）

FROM nvcr.io/nvidia/l4t-base:r32.7.1
WORKDIR /app
COPY requirements.txt .
RUN pip3 install --no-cache-dir -r requirements.txt
COPY mask_detector.py .
COPY model.trt .
ENV TRT_MODEL=/app/model.trt
EXPOSE 8554
CMD ["python3", "mask_detector.py"]

步骤2：构建多架构镜像

docker buildx create --use
docker buildx build --platform linux/arm64 -t registry.local:5000/mask-detector:arm64-v1.0 --push .

步骤3：在边缘设备上运行

docker pull registry.local:5000/mask-detector:arm64-v1.0
docker run -d --name mask-detector \
  --restart unless-stopped \
  --memory 512m --memory-swap 512m \
  --cpus 2 \
  --pids-limit 200 \
  --device /dev/video0:/dev/video0 \
  -v /home/nvidia/logs:/app/logs \
  --network host \
  registry.local:5000/mask-detector:arm64-v1.0

步骤4：验证与监控

docker logs -f mask-detector
docker stats --no-stream mask-detector

复盘总结：该方案中，卷 /home/nvidia/logs 持久化推理日志，避免容器重建后丢失；--network host 确保RTSP流端口8554直接暴露；--memory 512m 防止内存泄漏导致系统崩溃；--device 映射摄像头设备。若设备重启，--restart unless-stopped 保证容器自动恢复。整个部署过程无需在设备上安装任何Python依赖，只需Docker引擎即可。