3、Docker基础入门：理解Docker镜像、容器、Dockerfile、docker-compose等核心概念，掌握常用命令（build、run、exec、logs）与容器生命周期管理

在TinyML推理服务的实际部署中，模型训练完成只是第一步，真正的挑战在于如何将Python依赖、C库、OpenCV、TensorFlow Lite或ONNX Runtime等运行时环境，连同模型文件一起，以可复现、可移植的方式交付到边缘设备或服务器上。Docker正是解决这一问题的行业标准工具。本章将围绕Docker的四大核心对象——镜像、容器、Dockerfile、docker-compose——展开，帮助你建立从“构建”到“运行”再到“运维”的完整认知链路，并重点掌握容器生命周期管理中的关键命令与排障思路。

上图展示了Docker三大核心阶段的关系：构建阶段通过Dockerfile定义环境，使用docker build生成镜像；运行阶段通过docker run从镜像启动容器，容器是实际运行推理服务的隔离环境；编排阶段则通过docker-compose管理多个容器的协同工作。下面我们逐一深入。

3.1 核心概念：镜像、容器、Dockerfile与docker-compose

3.1.1 核心原理：分层存储与隔离运行

镜像（Image）是一个只读的、分层的模板，包含了运行应用所需的全部文件系统内容：操作系统基础库、Python解释器、依赖包、模型文件以及启动命令。镜像采用UnionFS（联合文件系统）技术，每一层都是只读的，构建时通过缓存复用层，极大节省存储空间。例如，基于python:3.9-slim的镜像，所有TinyML服务共享这一基础层，只有业务代码和模型文件作为新层添加。

容器（Container）是镜像的运行实例。当执行docker run时，Docker在镜像只读层之上添加一个可写层，并通过Linux Namespace（命名空间）和Cgroups（控制组）实现进程隔离与资源限制。容器内的进程看不到宿主机其他进程，拥有独立的网络栈、文件系统视图和PID命名空间。对于TinyML推理服务，这意味着即使模型推理代码存在内存泄漏或崩溃，也不会影响宿主机其他服务。

Dockerfile是构建镜像的“配方文件”，采用声明式语法。每一行指令（如FROM、RUN、COPY）都会生成一个新的镜像层。合理的Dockerfile设计能显著减小镜像体积并提高构建速度。

docker-compose是用于定义和运行多容器应用的工具。通过一个YAML文件，可以声明服务、网络、卷等资源，实现一条命令启动整个推理服务栈（如模型服务+Redis缓存+监控面板）。

3.1.2 判断方法：如何选择镜像与容器策略

维度	镜像	容器	docker-compose
本质	静态模板	动态运行实例	多容器编排定义
生命周期	持久存在，可复用	可创建、启动、停止、删除	随项目定义存在
存储	只读分层	可写层+挂载卷	管理卷和网络
适用场景	版本发布、CI/CD	单实例推理服务	微服务、依赖多个中间件
常用命令	build, tag, push, pull	run, exec, logs, stop, rm	up, down, ps, logs

选择策略：如果推理服务仅需一个进程且无外部依赖，直接使用docker run即可；如果服务需要Redis、MySQL或同时启动多个模型副本，则必须使用docker-compose进行编排。

3.1.3 案例拆解：一个TinyML推理服务的Dockerfile

假设我们要部署一个基于TensorFlow Lite的图像分类服务，项目结构如下：

project/
├── app.py              # Flask推理服务
├── model.tflite        # 量化后的模型
├── requirements.txt    # Python依赖
└── Dockerfile

Dockerfile内容：

# 阶段1：使用轻量级Python基础镜像
FROM python:3.9-slim

# 设置工作目录
WORKDIR /app

# 先复制依赖文件，利用层缓存
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 再复制业务代码和模型
COPY app.py .
COPY model.tflite .

# 暴露服务端口
EXPOSE 8080

# 启动命令
CMD ["python", "app.py"]

构建命令：docker build -t tiny-ml-inference:v1.0 .。这里的关键优化是先复制requirements.txt再复制代码，这样当代码变更时，Docker可以复用已缓存的依赖层，避免重复安装。

3.1.4 常见误区与总结复盘

3.2 常用命令实战：build、run、exec、logs与生命周期管理

3.2.1 核心原理：容器状态机与命令映射

容器的生命周期包括：已创建（Created）→ 运行中（Running）→ 已暂停（Paused）→ 已停止（Exited）→ 已删除（Deleted）。Docker命令与状态转换的对应关系如下：

• docker create：从镜像创建容器，但不启动。
• docker start：启动已创建的容器。
• docker run：create + start的组合，并支持-it（交互终端）、-d（后台运行）、-p（端口映射）等参数。
• docker stop：发送SIGTERM信号，等待优雅退出（默认10秒），超时后发送SIGKILL。
• docker restart：停止并重新启动。
• docker rm：删除已停止的容器，释放可写层。

3.2.2 操作流程：从构建到运行的完整命令链

# 1. 构建镜像（在Dockerfile所在目录）
docker build -t tiny-ml:v1.0 .

# 2. 查看本地镜像
docker images

# 3. 运行容器（后台模式，映射端口8080-8080）
docker run -d --name inference-server -p 8080:8080 tiny-ml:v1.0

# 4. 查看运行状态
docker ps

# 5. 查看日志（实时跟踪）
docker logs -f inference-server

# 6. 进入容器内部调试
docker exec -it inference-server /bin/bash

# 7. 停止容器
docker stop inference-server

# 8. 删除容器（-f 强制删除运行中的容器）
docker rm -f inference-server

对于TinyML服务，docker exec尤为重要。当推理请求返回异常时，可以进入容器检查模型文件是否存在、依赖库版本是否正确、环境变量是否生效。

3.2.3 案例拆解：推理服务容器排障全流程

背景：某团队部署YOLOv5s模型服务，容器启动后立即退出，docker ps看不到进程。

初始现象：docker run -d -p 8080:8080 yolo-server返回容器ID，但docker ps -a显示状态为Exited (1)。

分析过程：

1. 查看日志：docker logs yolo-server，发现错误ModuleNotFoundError: No module named 'torch'。
2. 检查Dockerfile：发现requirements.txt中缺少torch依赖，或安装时使用了--no-deps。
3. 进入容器验证：docker run -it --entrypoint /bin/bash yolo-server，手动执行python -c "import torch"确认缺失。

实际操作：修改requirements.txt添加torch==2.0.1，重新构建镜像。但构建后镜像体积从1.2GB增至3.5GB，启动时间变长。

结果对比：优化方案：改用pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime作为基础镜像，避免重复安装CUDA依赖。最终镜像体积2.1GB，启动时间从45秒降至20秒。

风险与代价：更换基础镜像可能导致系统库版本差异，需回归测试模型推理精度。

复盘经验：容器启动失败时，第一动作永远是docker logs；依赖缺失优先检查基础镜像选择；大体积依赖应通过多阶段构建或外部卷优化。

3.2.4 常见误区与总结复盘

3.3 docker-compose：多容器推理服务编排

3.3.1 核心原理：声明式服务编排

docker-compose通过YAML文件描述一组服务及其关系。对于TinyML场景，典型架构包括：推理服务（Flask/FastAPI）、缓存（Redis）、消息队列（RabbitMQ）和监控（Prometheus）。compose文件中的每个service对应一个容器，可以指定镜像、端口、卷、环境变量和依赖关系。

3.3.2 操作流程：编写compose文件并启动

# docker-compose.yml
version: '3.8'
services:
  inference:
    build: .
    ports:
      - "8080:8080"
    environment:
      - MODEL_PATH=/models/model.tflite
    volumes:
      - ./models:/models
    depends_on:
      - redis
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
    volumes:
      - redis-data:/data

volumes:
  redis-data:

启动命令：docker-compose up -d。查看状态：docker-compose ps。停止并清理：docker-compose down -v（-v同时删除卷）。

3.3.3 案例拆解：带Redis缓存的推理服务

背景：图像分类服务需要处理高频请求，每次推理约50ms。为降低重复请求的延迟，引入Redis缓存推理结果。

目标：缓存命中时响应时间<5ms，未命中时<60ms。

关键配置：

• 推理服务代码中检查Redis键（如img_hash），命中则直接返回结果。
• compose文件中通过depends_on确保Redis先启动。
• 使用networks定义内部网络，仅暴露推理服务端口。

操作步骤：

1. 编写app.py集成Redis客户端。
2. 构建镜像并启动：docker-compose up --build -d。
3. 压测验证：使用wrk -t4 -c100 -d30s http://localhost:8080/predict。

结果对比：缓存命中率85%时，平均延迟从52ms降至8ms，吞吐量提升4倍。

风险与代价：Redis缓存占用内存约200MB，需监控内存使用；缓存过期策略需与模型版本更新联动。

复盘经验：compose编排的价值在于“一键复现”整个环境，但要注意depends_on只控制启动顺序，不保证服务就绪。应使用健康检查（healthcheck）确保依赖服务可用。

3.3.4 常见误区与总结复盘