Docker常见问题（多种类似命令之间的区别）

前言

Docker 作为容器化技术的标准，其核心价值在于对应用运行环境的标准化封装与隔离。要精通 Docker 的运维与开发，必须深入理解其底层命令的工作原理、数据流向以及状态流转机制。本文将围绕容器的生命周期管理（Create/Start/Run）、镜像的持久化与迁移（Import/Load）以及资源的回收机制（Rm/Rmi/Prune）展开深度剖析。

第一部分：容器生命周期管理的底层逻辑

容器的生命周期本质上是进程状态与文件系统状态的组合。Docker 提供了 docker create、docker start 和 docker run 三个命令来精确控制这一过程。理解这三者的区别，需要从 Docker Daemon（守护进程）如何处理容器配置、读写层（Read-Write Layer）以及命名空间（Namespaces）的角度入手。

1. docker create：构建容器静态实体的过程

docker create 命令的核心职能是初始化容器的配置信息并建立文件系统层级，但并不触发容器内主进程的执行。

在执行 docker create [IMAGE] 时，Docker Daemon 会执行以下一系列原子操作：

镜像检查与获取：验证本地是否存在指定镜像。
读写层分配：基于联合文件系统（UnionFS），在镜像的只读层（Read-Only Layers）之上，叠加一层空的读写层。这一层用于存储容器运行期间产生的所有数据变更。
配置元数据生成 ：在 /var/lib/docker/containers/<container-id>/ 目录下生成 config.v2.json 和 hostconfig.json 文件。这些文件记录了容器的网络设置、环境变量、挂载点以及资源限制（Cgroups 配额）。
状态标记 ：将容器状态标记为 Created。

此命令的战略意义在于"配置与运行解耦"。在复杂的编排场景中，可能需要先行预分配容器的 ID、网络接口或挂载卷，待所有依赖资源就绪后，再统一触发运行。

2. docker start：激活容器运行时环境

docker start [CONTAINER] 的作用是将一个处于 Created 或 Exited 状态的静态容器转化为一个运行中的进程。

当执行此命令时，Docker 引擎的后端运行时（如 runc）介入工作：

命名空间隔离：初始化 Linux Namespaces（包括 PID、NET、IPC、MNT、UTS），为容器创建独立的进程运行环境。
控制组应用：根据创建时的配置，将容器进程加入对应的 Cgroups，实施 CPU、内存等资源的硬限制。
主进程执行 ：读取镜像或配置中指定的 ENTRYPOINT 和 CMD 指令，启动 PID 为 1 的主进程。
状态变更 ：将容器状态更新为 Up。

若容器是从 Exited 状态启动，之前在读写层产生的数据（如日志文件、数据库记录）依然存在，保证了数据在容器重启过程中的持久性。

3. docker run：复合操作的原子化封装

docker run 是 Docker 中使用频率最高的命令，它并非单一功能的指令，而是 docker create 和 docker start 的逻辑组合，并增加了前台交互的处理能力。

执行 docker run [IMAGE] 的完整内部流程如下：

API 调用：Docker Client 向 Docker Daemon 发送请求。
镜像拉取 ：若本地缺失镜像，触发 docker pull 操作。
容器创建 ：执行 create 逻辑，分配 ID 和文件系统。
容器启动 ：执行 start 逻辑，拉起进程。
流附加（Attach）：默认情况下，Client 端会监听容器的标准输入（STDIN）、标准输出（STDOUT）和标准错误（STDERR），实现日志的实时回显或终端交互。

命令差异性总结表：

特性	docker create	docker start	docker run
核心动作	分配资源，写入配置	初始化隔离环境，执行进程	组合动作（Create + Start）
容器状态变化	Null -> Created	Created/Exited -> Up	Null -> Up
网络资源	预分配设置，但不激活	激活虚拟网卡与 IP	配置并激活
典型场景	细粒度控制、预配置	故障恢复、分步启动	快速部署、临时任务

第二部分：镜像数据的持久化、迁移与恢复

在涉及跨网络环境（如气密内网）迁移 Docker 资产时，docker save/load 与 docker export/import 是两组关键的解决方案。尽管它们最终都能生成镜像，但其底层的数据结构、元数据完整性以及适用场景存在本质区别。

1. 镜像归档机制：docker save 与 docker load

docker save 导出的 tar 包是镜像层（Layers）与元数据的完整集合。

数据完整性 ：该命令保留了镜像的所有历史层级。每一个 RUN、COPY 指令生成的层都会被独立打包。同时，包含 manifest.json 和镜像配置 JSON 文件，完整保留了镜像的 Tag 信息、环境变量（ENV）、端口暴露（EXPOSE）、启动命令（CMD/ENTRYPOINT）以及构建历史。
多镜像打包：支持一次性将多个镜像打包进同一个 tar 文件。

对应地，docker load 的作用是将这个完整的归档文件"重放"到 Docker 的图驱动（Graph Driver）中。

恢复逻辑：Docker 引擎会读取 tar 包中的 manifest，校验每一层的 SHA256 签名。如果本地已存在相同的层（由 ID 标识），则跳过加载，实现增量恢复；否则，解压层数据并重建镜像元数据。
结果一致性：恢复后的镜像 ID 与源镜像 ID 完全一致，这保证了环境的精确复制。

2. 容器快照机制：docker export 与 docker import

docker export 导出的对象是容器的文件系统快照。

扁平化处理：该命令会将容器当前的读写层与所有只读层合并，打包成一个单纯的文件系统 tar 包。在此过程中，所有的层级信息被丢弃，所有的构建历史、元数据（如 ENV、CMD）全部丢失。
数据范围：仅包含容器当前可见的文件。挂载卷（Volumes）中的数据通常不会被导出（除非挂载点位于导出路径内且未被特殊处理）。

docker import 则利用这个文件系统快照构建一个新的镜像。

镜像重构：导入后，Docker 会创建一个全新的镜像层（Base Layer），包含 tar 包中的所有文件。
元数据重建 ：由于原始元数据丢失，新镜像没有预设的 CMD 或 ENTRYPOINT。在执行 docker import 时，通常需要使用 --change 参数（如 --change "CMD /bin/bash"）来手动补充运行时配置。
结果特性：生成的是一个没有父层历史的"扁平"镜像，体积可能比原始分层镜像更小，但也失去了分层共享的优势。

3. 核心差异深度对比

维度	docker save / load	docker export / import
操作对象	镜像 (Images)	容器 (Containers)
文件内容	完整的层级数据 + 完整元数据	仅文件系统快照 (Filesystem Snapshot)
历史记录	完整保留 (可以回滚)	全部丢失 (无法回滚)
环境变量/CMD	保留	丢失 (需重新指定)
镜像体积	较大 (包含所有历史变更)	较小 (仅包含最终状态)
适用场景	环境整体迁移、备份、离线交付	制作基础镜像、精简镜像体积、提取文件系统

第三部分：Docker 资源的清理与维护策略

随着 Docker 的长期运行，系统中会积累大量的容器、镜像、网络和卷资源。无效资源不仅占用磁盘空间（尤其是 /var/lib/docker），还可能导致 IP 地址耗尽或构建缓存冲突。docker rm、docker rmi 和 docker prune 分别针对不同粒度的资源清理提供了解决方案。

1. docker rm：容器实例的移除

docker rm 专门用于移除容器记录及其可写层。

状态约束 ：默认只能移除 Exited 或 Created 状态的容器。若容器正在运行，Docker 守护进程会拒绝操作，以防止误删生产服务。
强制删除机制 ：使用 -f (--force) 参数时，Docker 会通过 SIGKILL 信号强制终止容器进程，随后执行删除操作。
数据卷残留 ：这是一个关键的知识盲点。默认执行 docker rm container_name 不会删除该容器关联的匿名卷（Anonymous Volumes）。这些卷会变成"悬空卷"（Dangling Volumes），长期占用磁盘。正确的做法是使用 docker rm -v container_name，随容器一同清理关联的匿名卷。

2. docker rmi：镜像资产的移除

docker rmi 用于从本地存储库中卸载镜像。

引用计数检查 ：Docker 采用引用计数机制管理镜像。当执行 docker rmi image_id 时，系统会检查是否有已停止或运行中的容器依赖于该镜像的任何一层。如果存在依赖（即引用计数 > 0），删除操作会失败。必须先删除相关容器 (docker rm)，释放引用后才能删除镜像。
标签解绑 vs 物理删除 ：
- 当一个镜像 ID 对应多个 Tag（如 image:latest 和 image:v1）时，docker rmi image:latest 仅执行解绑操作（Untag），镜像实体依然存在。
- 当该镜像 ID 的最后一个 Tag 被移除，或者直接通过 ID 进行删除时，Docker 才会触发物理删除，清理文件系统中的层数据。

3. docker prune：全系统层面的垃圾回收

docker prune 是 Docker 的垃圾回收（GC）指令集，用于批量清理"悬空"或"未使用"的资源。

悬空资源 (Dangling) ：指没有 Tag 且没有被任何容器引用的镜像（通常显示为 <none>:<none>），或者是没有关联任何容器的卷。这些通常是构建过程中产生的中间产物。
未使用资源 (Unused) ：指当前未被任何正在运行的容器所引用的资源。范围比"悬空"更广。

核心指令解析：

docker image prune：默认仅清理悬空镜像。
docker container prune ：批量清理所有处于 Exited 状态的容器。
docker system prune ：这是最激进的清理命令。它会同时执行以下操作：
1. 删除所有已停止的容器。
2. 删除所有未被容器使用的网络。
3. 删除所有悬空镜像。
4. 删除构建缓存（Build Cache）。
docker system prune -a ：极度危险操作 。加上 -a (--all) 标志后，它不仅删除悬空镜像，还会删除所有当前未被运行容器使用 的镜像。这意味着如果本地缓存了 ubuntu:latest 镜像但暂时没跑容器，执行该命令后镜像将被直接删除，下次使用需重新拉取。

总结

Docker 的命令体系设计严谨，分别对应了不同的资源管理层级。

生命周期管理 ：遵循 Create (配置) -> Start (激活) -> Run (组合) 的逻辑。
数据迁移 ：区分 Save/Load (镜像完整备份) 与 Export/Import (文件系统快照)。
资源清理 ：依据依赖关系链，从 rm (容器) 到 rmi (镜像)，最终通过 prune 实现自动化的垃圾回收。

深入理解这些机制，能够有效避免生产环境中的数据丢失风险，优化存储空间利用率，并提升容器编排的稳定性。