导出 Docker 镜像的命令是什么？`docker save` 还是 `docker export`？

Question

**常见技术问题：** 导出 Docker 镜像该用 `docker save` 还是 `docker export`？二者常被混淆，但用途截然不同：`docker save` 用于**导出镜像（image）**——保留完整的分层结构、元数据（如标签、历史记录、Dockerfile 指令）和所有父层，生成可跨环境加载的 `.tar` 文件（支持 `docker load` 恢复）；而 `docker export` 导出的是**容器（container）** 的文件系统快照（即运行时状态的扁平化 tar 包），不包含镜像元数据、分层信息或历史，也无法还原为镜像。简言之：要备份/迁移镜像 → 用 `docker save`；仅需提取某容器当前文件内容（如配置、日志）→ 才考虑 `docker export`。误用 `export` 导出镜像会导致镜像丢失、无法复原，是生产环境中典型误操作。

Answer 1

```html

一、现象层：常见误操作与表象症状

在CI/CD流水线或灾备演练中，工程师常执行 docker export container_id > app.tar 后试图在另一台机器运行 docker load < app.tar，结果报错：Error: Error processing tar file(exit status 1): unexpected EOF 或 invalid image format。更隐蔽的问题是：导出后 docker images 显示镜像消失，却误以为“已备份成功”。这种“看似导出、实则销毁”的反直觉行为，已成为Docker入门到进阶阶段最高频的生产事故诱因之一。

二、机制层：镜像（Image）与容器（Container）的本质差异

维度	docker save	docker export
作用对象	镜像（Image，只读模板）	容器（Container，可写运行时实例）
输出内容	完整分层tar（含manifest.json, repositories, 各layer .tar.gz）	单层扁平化tar（仅/根文件系统快照，无元数据）
是否保留历史	✅ 完整保留 docker history 和 Dockerfile 指令链	❌ 彻底丢失所有构建历史与层级关系

三、验证层：动手验证差异的不可逆性

以下命令序列可复现核心差异：

# 1. 构建带多层的镜像
echo -e "FROM alpine\nRUN echo 'layer1' > /a.txt\nRUN echo 'layer2' > /b.txt" | docker build -t test-img -f - .

# 2. 启动容器并修改文件
cid=$(docker run -d test-img sleep 3600)
docker exec $cid sh -c "echo 'runtime-mod' > /c.txt"

# 3. 分别导出
docker save test-img > img-save.tar
docker export $cid > cont-export.tar

# 4. 关键验证：能否还原为可用镜像？
docker load < img-save.tar   # ✅ 成功，test-img 重新出现在 docker images 中
docker load < cont-export.tar # ❌ 失败：no valid image found in tarball

四、架构层：Docker 存储驱动视角下的底层逻辑

Docker 镜像采用分层存储（Layered Filesystem），如 overlay2 下每个镜像层对应一个 diff/ 目录；而容器在镜像顶部叠加一个可写层（UpperDir）。docker save 序列化整个 layer DAG 及其 JSON 元数据；docker export 仅调用 container.Rootfs().Tar() —— 本质是 tar -cf 对当前挂载点做快照，完全绕过 graphdriver 的 layer 管理模块。这解释了为何 export 产物无法被 image.Store() 解析。

五、生产实践层：高危场景与防御性工程方案

• 灾备陷阱：某金融客户用 export 备份关键中间件镜像，K8s集群升级后发现无法回滚——因镜像ID已失效且无源Dockerfile
• CI流水线漏洞：Jenkins脚本将 docker export 产物上传至制品库，下游环境因缺少基础镜像层导致 docker run 启动失败
• 防御方案：
  • 在CI配置中强制校验命令：拒绝包含 docker export.*\.tar 且目标文件名含 image\|img\|base 的提交
  • 部署 docker save --quiet + tar -tf 自动检测导出包结构（检查是否存在 manifest.json）

六、演进层：OCI标准下的兼容性延伸

graph LR
  A[OCI Image Spec v1.0] --> B[docker save 输出符合 OCI layout]
  A --> C[skopeo copy --format oci]
  D[docker export] --> E[不符合 OCI 标准]
  E --> F[无法被 podman build/load 或 crane push]
  B --> G[跨平台迁移：docker → podman → k3s 内置ctr]

随着OCI（Open Container Initiative）成为事实标准，docker save 导出的tar包天然满足 oci-layout 目录规范（含 blobs/, index.json），可直接被 podman load、crane load 或 nerdctl import 消费；而 export 产物因缺失OCI必需的描述符（descriptors）和摘要（digests），在云原生生态中彻底丧失互操作性。

```