Docker容器与镜像：两种导入导出方式全解析
Docker容器与镜像：两种导入导出方式全解析
在Docker的日常使用中，我们经常需要在不同环境间迁移容器或镜像。Docker提供了两套截然不同的导入导出机制，虽然看起来相似，但它们的工作原理和适用场景却有着本质区别。本文将深入剖析这两种方式，帮你彻底理解它们的差异。
方式一：export/import（容器级操作）
基本概念
export/import是针对容器的操作，它能够将一个完整的容器文件系统导出为tar归档文件，然后在其他地方重新导入为镜像。
操作示例
# 1. 查看当前运行的容器
docker ps# 2. 导出容器（可以是运行中或已停止的）
docker export my_running_container > container_backup.tar
# 或者使用 -o 参数
docker export -o container_backup.tar my_running_container# 3. 导入为新镜像
docker import container_backup.tar my_app:exported
# 可以在导入时添加元数据
docker import container_backup.tar my_app:exported --change "CMD /usr/sbin/nginx -g 'daemon off;'"
工作机制
当你执行export时，Docker会：
- 获取容器当前的完整文件系统快照
- 将所有文件和目录打包成单一的tar文件
- 忽略镜像的层次结构，创建一个"扁平化"的副本
导入时，Docker会：
- 解压tar文件内容
- 创建一个全新的单层镜像
- 丢弃所有原始的层信息和构建历史
方式二：save/load（镜像级操作）
基本概念
save/load是针对镜像的操作，它完整保留镜像的层次结构、元数据和构建历史。
操作示例
# 1. 查看本地镜像
docker images# 2. 保存单个镜像
docker save -o nginx_backup.tar nginx:latest# 3. 保存多个镜像到一个文件
docker save -o multiple_images.tar nginx:latest mysql:8.0 redis:alpine# 4. 保存并压缩（推荐）
docker save nginx:latest | gzip > nginx_backup.tar.gz# 5. 加载镜像
docker load -i nginx_backup.tar
# 或者从压缩文件加载
gunzip -c nginx_backup.tar.gz | docker load
工作机制
执行save时，Docker会：
- 保存镜像的所有层文件
- 保存层之间的关系和依赖
- 保存镜像的完整元数据
- 保存构建历史和配置信息
执行load时，Docker会：
- 重建完整的镜像结构
- 恢复所有层的缓存关系
- 保持与原镜像完全相同的特性
深度对比：技术细节
文件结构差异
export产生的tar文件：
container_export.tar/
├── bin/
├── etc/
├── usr/
├── var/
└── ... (直接的文件系统结构)
save产生的tar文件：
image_save.tar/
├── manifest.json # 镜像清单
├── repositories # 仓库信息
├── 层ID1/
│ ├── json # 层元数据
│ ├── layer.tar # 层内容
│ └── VERSION
├── 层ID2/
└── ...
层信息对比
假设我们有一个这样构建的镜像：
FROM ubuntu:20.04 # 层1: 64MB
RUN apt-get update # 层2: 25MB
RUN apt-get install -y nginx # 层3: 55MB
COPY app/ /var/www/html/ # 层4: 10MB
EXPOSE 80 # 层5: 0MB (元数据)
使用save/load：
docker history my_app:latest
IMAGE CREATED BY SIZE
abc123 /bin/sh -c #(nop) EXPOSE 80 0B
def456 /bin/sh -c #(nop) COPY app/ /var/www/html/ 10MB
ghi789 /bin/sh -c apt-get install -y nginx 55MB
jkl012 /bin/sh -c apt-get update 25MB
mno345 /bin/sh -c #(nop) FROM ubuntu:20.04 64MB
使用export/import：
docker history my_app:imported
IMAGE CREATED BY SIZE
xyz999 /bin/sh -c #(nop) 154MB
看到差别，所有的构建步骤信息都消失了！
性能与存储影响
磁盘空间利用
场景：你有5个基于同一个nginx基础镜像的应用
使用save/load时：
本地镜像存储：
nginx:latest (base layers) 100MB
app1:latest (+ app1 layer) + 20MB = 120MB
app2:latest (+ app2 layer) + 15MB = 115MB
app3:latest (+ app3 layer) + 25MB = 125MB
总共实际占用：160MB (共享基础层)
使用export/import时：
本地镜像存储：
app1:imported 120MB
app2:imported 115MB
app3:imported 125MB
总共实际占用：360MB (无法共享)
传输效率测试
在具有相同基础镜像的环境中部署新版本：
# save/load（只传输变化层）
时间: 30秒，传输: 45MB# export/import（传输完整容器）
时间: 180秒，传输: 850MB
最佳实践建议
选择决策树
需要保存运行时状态？
├─ 是 → 使用 export/import
└─ 否 → 是否需要保持镜像完整性？├─ 是 → 使用 save/load└─ 否 → 仍然推荐 save/load（除非有特殊需求）
常见误区
-
误区：export/import更快更小
实际：短期看似如此，长期考虑存储和网络成本更高 -
误区：两种方式可以互换使用
实际：它们服务于不同的使用场景 -
误区：export/import丢失的只是"无用信息"
实际：丢失的层信息对Docker生态系统的效率至关重要
生产环境建议
# 推荐的生产部署流程
# 1. 构建时使用多阶段构建优化层结构
# 2. 使用save保存发布版本
# 3. 使用压缩减少传输大小
docker save my_app:v1.0.0 | gzip > releases/my_app_v1.0.0.tar.gz# 4. 部署时使用load恢复完整镜像
gunzip -c my_app_v1.0.0.tar.gz | docker load
总结
Docker的这两种导入导出方式各有其设计目的。export/import专注于容器状态的快速备份和迁移，而save/load则致力于保持Docker镜像生态系统的完整性和效率。
理解它们的差异不仅能帮你选择正确的工具，更重要的是能让你更好地利用Docker的分层特性，构建更高效、更可维护的容器化应用。
在大多数生产场景中，save/load是更明智的选择，因为它保持了Docker设计的核心优势。而export/import则更适合那些需要捕获运行时状态或进行一次性迁移的特殊场景。