📚 课程目录第2章 Docker基础回顾

2、Docker基础回顾：镜像、容器、卷、网络等核心概念，以及Docker与ROS2结合的典型工作流

在进入ROS2机器人Docker部署的实战之前，必须先夯实Docker的核心知识体系。很多开发者在使用Docker时，往往只停留在docker run和docker build的层面，对镜像分层、容器生命周期、卷的挂载类型、网络模式差异缺乏系统理解，导致在机器人开发中遇到设备权限丢失、共享内存无法访问、多机通信失败等棘手问题。本章将系统梳理Docker的四大核心概念——镜像、容器、卷、网络，并给出与ROS2结合的典型工作流，为后续章节的依赖管理、设备权限配置和启动脚本编写打下坚实基础。

上图展示了Docker四大核心概念之间的逻辑关系：镜像作为只读模板被实例化为容器，容器通过卷实现数据持久化，通过网络实现与宿主机及外部世界的通信。在ROS2机器人场景中，这四个概念环环相扣，任何一个环节配置不当都可能导致部署失败。下面逐一深入剖析。

2.1 镜像：ROS2运行环境的静态封装

核心原理

Docker镜像是一个只读的、分层存储的文件系统快照。每一层代表一个Dockerfile指令（如RUN apt-get install、COPY等）产生的变更。这种分层设计使得多个镜像可以共享底层数据，大幅节省磁盘空间并加速构建。对于ROS2开发，镜像通常包含：基础操作系统（Ubuntu 22.04）、ROS2发行版（Humble）、编译工具链（colcon、cmake）、依赖库（Eigen、OpenCV、PCL等）以及自定义的ROS2功能包源码。

判断方法

查看镜像的层级信息可以使用docker history <镜像名>，这能帮助你理解镜像的构建过程，排查体积过大的原因。例如，如果发现某一层执行了apt upgrade，这往往会导致镜像体积膨胀且不可复现，因为升级的包版本会随时间变化。判断一个镜像是否适合ROS2开发，关键看三点：是否包含完整的ROS2基础环境、是否安装了必要的编译和运行依赖、是否设置了正确的环境变量（如source /opt/ros/humble/setup.bash）。

# 查看镜像分层信息
docker history ros2-humble:latest

# 查看镜像环境变量
docker inspect ros2-humble:latest | grep -A 10 "Env"

案例拆解：构建一个可复现的ROS2开发镜像

假设团队需要统一5名开发者的ROS2 Humble环境，避免“在我机器上能编译”的尴尬。我们编写如下Dockerfile：

FROM ubuntu:22.04
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y \
    curl gnupg lsb-release && \
    curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg && \
    echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(lsb_release -cs) main" | tee /etc/apt/sources.list.d/ros2.list > /dev/null && \
    apt-get update && apt-get install -y \
    ros-humble-desktop \
    python3-colcon-common-extensions \
    ros-humble-gazebo-ros-pkgs \
    && rm -rf /var/lib/apt/lists/*
RUN echo "source /opt/ros/humble/setup.bash" >> ~/.bashrc
WORKDIR /workspace

构建命令为docker build -t ros2-humble:dev .。这里的关键设计是：将apt-get update和apt-get install合并为一条RUN指令，避免产生过多的中间层；使用rm -rf /var/lib/apt/lists/*清理缓存，减小镜像体积。构建完成后，所有开发者拉取同一镜像，即可获得完全一致的编译环境。

经验提醒：在Dockerfile中，尽量将变化频率低的指令放在前面（如安装系统依赖），变化频率高的指令放在后面（如COPY源码）。这样可以利用Docker的构建缓存，大幅缩短迭代构建时间。

2.2 容器：ROS2进程的运行沙箱

核心原理

容器是镜像的运行实例，它在镜像只读层之上增加了一个可写层。容器内的进程与宿主机共享内核，但通过Linux内核的命名空间（Namespace）实现PID、网络、文件系统、用户等方面的隔离，通过Cgroups限制资源使用。对于ROS2机器人，容器内通常运行ros2 launch启动的多个节点进程，这些进程共享同一个ROS2域（Domain ID）和命名空间。

操作流程

容器的典型生命周期包括：创建（docker create）、启动（docker start）、进入（docker exec）、停止（docker stop）、删除（docker rm）。在实际ROS2开发中，最常用的模式是docker run一次性完成创建和启动，并通过-it参数进入交互式终端。

# 启动一个交互式ROS2容器，挂载源码目录
docker run -it --rm \
  --name ros2_dev \
  -v $(pwd)/src:/workspace/src \
  ros2-humble:dev \
  bash

进入容器后，即可执行colcon build和ros2 launch。这里--rm参数表示容器退出后自动删除，适合临时开发环境；-v参数将宿主机的源码目录挂载到容器内，实现代码实时同步。

常见误区

风险提示：很多初学者误以为容器内的文件修改会持久保存。实际上，容器可写层的数据在容器删除后会丢失。如果直接在容器内修改了源码或安装了新软件包，必须通过docker commit将容器保存为新镜像，或者使用卷挂载将数据持久化到宿主机。否则，一旦执行docker rm，所有修改将灰飞烟灭。

2.3 卷：数据持久化与共享的桥梁

核心原理

卷（Volume）是Docker管理的数据存储机制，它独立于容器的生命周期。卷有三种类型：匿名卷（自动生成的随机名称）、命名卷（用户指定名称）、绑定挂载（直接映射宿主机目录）。在ROS2机器人开发中，绑定挂载最为常用，因为它允许开发者在宿主机上使用熟悉的IDE编辑代码，容器内实时同步。

类型	命令示例	适用场景	优点	缺点
匿名卷	`-v /container/path`	容器内临时数据	无需管理名称	难以复用
命名卷	`-v mydata:/container/path`	数据库、日志存储	易于备份和迁移	宿主机路径不直观
绑定挂载	`-v $(pwd):/workspace`	源码开发、配置文件	实时同步，直观	依赖宿主机目录结构

案例拆解：ROS2 bag包录制与共享

假设机器人运行过程中需要录制ROS2话题数据（ros2 bag），录制产生的数据量可能达到数GB。如果存储在容器可写层，容器删除后数据即丢失。正确做法是使用命名卷或绑定挂载：

# 使用命名卷存储bag数据
docker run -it --rm \
  --name ros2_recorder \
  -v rosbag_data:/data \
  ros2-humble:dev \
  bash -c "source /opt/ros/humble/setup.bash && ros2 bag record -o /data/robot_run1 /scan /odom"

录制完成后，即使容器删除，数据仍保存在命名卷rosbag_data中。后续可以启动另一个容器挂载同一卷进行数据回放和分析。这种模式在机器人数据采集和算法验证中非常实用。

2.4 网络：ROS2通信的命脉

核心原理

Docker默认提供bridge、host、none三种网络模式。bridge模式为容器分配独立的虚拟网络接口，容器之间可以互通，但与宿主机通过NAT访问外部网络；host模式直接共享宿主机的网络栈，容器内的端口和IP与宿主机完全一致；none模式则完全禁用网络。对于ROS2机器人，网络模式的选择直接影响DDS（数据分发服务）通信的可靠性。

判断方法

当ROS2节点需要与宿主机上的其他进程（如硬件驱动节点）通信时，必须使用host网络模式。因为bridge模式下，容器内的DDS发现协议（默认使用UDP多播）无法穿透NAT，导致节点无法互相发现。判断是否需要host模式，可以问自己：容器内的ROS2节点是否需要与容器外的ROS2节点通信？如果答案是肯定的，那么必须使用--network=host。

# 使用host网络模式运行ROS2节点
docker run -it --rm \
  --network=host \
  --ipc=host \
  ros2-humble:dev \
  bash -c "source /opt/ros/humble/setup.bash && ros2 run demo_nodes_cpp talker"

这里同时使用了--ipc=host，这是因为ROS2的某些中间件（如Fast-DDS的Shared Memory传输）需要共享内存，而共享内存属于IPC命名空间，默认情况下容器与宿主机隔离，必须显式共享。

  关键结论：在ROS2机器人部署中，强烈建议统一使用--network=host --ipc=host。这不仅能解决DDS通信问题，还能避免端口映射的麻烦，并确保共享内存传输的高效性。代价是容器失去了网络隔离，但对于机器人这种单机应用场景，安全性风险可控。

2.5 Docker与ROS2结合的典型工作流

工作流全景

一个标准的ROS2 + Docker开发工作流包含以下五个阶段：

镜像构建阶段：编写Dockerfile，定义基础系统、ROS2版本、依赖库和编译工具。使用docker build生成可复现的镜像。
开发调试阶段：使用docker run -it -v $(pwd):/workspace --network=host启动容器，挂载源码，在容器内进行编译和单节点调试。
集成测试阶段：启动多个容器或在一个容器内启动多个功能包，模拟完整的机器人系统，进行联合调试。
部署运行阶段：将镜像导出或推送到镜像仓库，在目标机器人上拉取镜像并运行。此时通常使用docker run -d后台运行，配合--restart=always实现开机自启。
数据持久化阶段：将日志、地图、bag包等数据通过卷挂载到宿主机指定目录，便于事后分析和模型训练。

案例拆解：从开发到部署的完整闭环

假设我们开发了一款基于ROS2的差速驱动机器人，包含激光雷达驱动、里程计计算、导航堆栈三个功能包。开发阶段，我们在宿主机上编写代码，通过绑定挂载同步到容器内编译。具体流程如下：

# 1. 构建开发镜像（包含所有依赖）
docker build -t robot_dev:latest .

# 2. 启动开发容器，挂载源码和设备
docker run -it --rm \
  --name robot_dev_container \
  --network=host \
  --ipc=host \
  --privileged \
  -v /dev/ttyUSB0:/dev/ttyUSB0 \
  -v $(pwd)/robot_ws:/robot_ws \
  robot_dev:latest \
  bash

# 3. 在容器内编译
cd /robot_ws && colcon build --symlink-install

# 4. 运行导航系统
source install/setup.bash && ros2 launch robot_nav navigation.launch.py

在部署阶段，我们将开发镜像中的源码编译产物打包成运行镜像（仅包含可执行文件和依赖库，不包含源码和编译工具），体积从2.5GB缩减到800MB。然后在机器人上执行：

# 运行部署镜像，自动启动导航系统
docker run -d \
  --name robot_nav \
  --network=host \
  --ipc=host \
  --privileged \
  --restart=always \
  -v /dev/ttyUSB0:/dev/ttyUSB0 \
  -v /var/log/robot:/var/log/robot \
  robot_nav:latest \
  ros2 launch robot_nav navigation.launch.py

这里--privileged参数赋予了容器访问宿主机所有设备的权限，虽然存在安全隐患，但在机器人场景中，为了访问激光雷达、IMU、电机驱动板等设备，这是最直接的方案。更安全的做法是使用--device参数逐个映射设备，但需要提前知道所有设备的设备文件路径。

常见误区与复盘

误区一：忽视--ipc=host导致共享内存通信失败。症状是节点间话题消息时断时续，或者报错Failed to open shared memory file。复盘发现，Fast-DDS默认使用共享内存传输，而容器默认隔离了IPC命名空间。

误区二：在容器内使用localhost进行ROS2通信。在bridge网络模式下，容器内的localhost指向容器自身，无法与宿主机或其他容器通信。必须使用host网络模式，或者使用宿主机IP地址。

误区三：设备权限配置不完整。仅映射了/dev/ttyUSB0，但激光雷达可能还需要/dev/ttyACM0或USB总线权限。建议在调试阶段使用--privileged快速验证，确认设备列表后再收紧权限。

总结复盘

Docker与ROS2的结合，本质上是将复杂的机器人软件环境封装为可移植、可复制的标准化单元。镜像解决了环境一致性问题，容器解决了进程隔离问题，卷解决了数据持久化问题，网络解决了通信问题。在实际项目中，建议遵循以下原则：

镜像分层设计：将基础系统、ROS2核心、项目依赖、业务代码分为四层，每层独立构建，便于缓存和更新。
开发与部署镜像分离：开发镜像包含编译工具和源码，部署镜像仅包含运行所需的最小文件集。
统一使用host网络：在机器人单机场景下，host网络模式是最简单、最可靠的方案。
设备权限显式声明：在启动脚本中明确列出所有需要映射的设备文件，避免使用--privileged带来的安全风险。
日志和数据卷外置：所有需要保留的数据必须通过卷挂载到宿主机，防止容器重建导致数据丢失。