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会：

1. 获取容器当前的完整文件系统快照
2. 将所有文件和目录打包成单一的tar文件
3. 忽略镜像的层次结构，创建一个"扁平化"的副本

导入时，Docker会：

1. 解压tar文件内容
2. 创建一个全新的单层镜像
3. 丢弃所有原始的层信息和构建历史

方式二：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会：

1. 保存镜像的所有层文件
2. 保存层之间的关系和依赖
3. 保存镜像的完整元数据
4. 保存构建历史和配置信息

执行load时，Docker会：

1. 重建完整的镜像结构
2. 恢复所有层的缓存关系
3. 保持与原镜像完全相同的特性

深度对比：技术细节

文件结构差异

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（除非有特殊需求）

常见误区

1. 误区：export/import更快更小
   实际：短期看似如此，长期考虑存储和网络成本更高

2. 误区：两种方式可以互换使用
   实际：它们服务于不同的使用场景

3. 误区：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则更适合那些需要捕获运行时状态或进行一次性迁移的特殊场景。