前言
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 才会触发物理删除，清理文件系统中的层数据。
- 当一个镜像 ID 对应多个 Tag（如
3. docker prune：全系统层面的垃圾回收
docker prune是 Docker 的垃圾回收（GC）指令集，用于批量清理“悬空”或“未使用”的资源。
- 悬空资源 (Dangling)：指没有 Tag 且没有被任何容器引用的镜像（通常显示为
<none>:<none>），或者是没有关联任何容器的卷。这些通常是构建过程中产生的中间产物。 - 未使用资源 (Unused)：指当前未被任何正在运行的容器所引用的资源。范围比“悬空”更广。
核心指令解析：
docker image prune：默认仅清理悬空镜像。docker container prune：批量清理所有处于Exited状态的容器。docker system prune：这是最激进的清理命令。它会同时执行以下操作：- 删除所有已停止的容器。
- 删除所有未被容器使用的网络。
- 删除所有悬空镜像。
- 删除构建缓存（Build Cache）。
docker system prune -a：极度危险操作。加上-a(--all) 标志后，它不仅删除悬空镜像，还会删除所有当前未被运行容器使用的镜像。这意味着如果本地缓存了ubuntu:latest镜像但暂时没跑容器，执行该命令后镜像将被直接删除，下次使用需重新拉取。
总结
Docker 的命令体系设计严谨，分别对应了不同的资源管理层级。
- 生命周期管理：遵循
Create(配置) ->Start(激活) ->Run(组合) 的逻辑。 - 数据迁移：区分
Save/Load(镜像完整备份) 与Export/Import(文件系统快照)。 - 资源清理：依据依赖关系链，从
rm(容器) 到rmi(镜像)，最终通过prune实现自动化的垃圾回收。
深入理解这些机制，能够有效避免生产环境中的数据丢失风险，优化存储空间利用率，并提升容器编排的稳定性。
