镜像导出是CI/CD中保障离线性、可审计性与环境一致性的关键环节，需嵌入流水线末尾自动执行：代码拉取→单元测试→构建带语义标签镜像→验证健康端点→docker save导出→归档或上传→生成SHA256校验。
镜像导出本身不是流水线的终点，而是自动化交付中保障离线性、可审计性和环境一致性的关键环节。它不单独构成完整流水线，但必须嵌入CI/CD流程中，才能真正实现“一次构建、随处运行”的闭环。
导出动作要嵌入CI阶段末尾
在Jenkins、GitLab CI或GitHub Actions中，docker save不应作为人工操作，而应是构建和测试通过后的标准步骤。典型顺序是：
- 拉取代码 → 运行单元测试 → 构建Docker镜像（含语义化标签）
- 验证镜像可用性（如启动容器并检查健康端点）
- 执行
docker save -o app-${TAG}.tar app:${TAG} - 将 tar 包作为构建产物归档（如Jenkins的Archive Artifacts，或上传至对象存储）
多镜像打包与压缩需统一策略
微服务架构下常需导出多个关联镜像（如前端+后端+网关）。这时应避免逐条命令，改用脚本封装：
- 用
docker save一次性导出多个镜像：docker save -o full-stack.tar nginx:1.22 alpine:3.18 myapi:v2.1 - 结合
gzip压缩降低传输体积：docker save nginx:latest redis:7-alpine | gzip > images.gz - 生成校验文件（如SHA256），供下游加载时验证完整性
目标环境适配决定导出方式选型
是否需要 docker save/load，取决于部署场景约束：
- 内网隔离环境（如金融、政务）→ 必须用
save+ 离线介质（U盘/内网FTP）+load - 跨云Registry迁移 → 优先走
docker pull → tag → push，更高效且保留签名 - CI流水线缓存加速 → 可用
save将中间镜像暂存为tar，再由后续jobload复用，跳过重复构建
安全与可追溯性不能省略
导出环节容易被忽略的是元数据留存和权限控制：
- 导出前确保镜像已打上不可变标签（如
v1.4.2或commit-abc123），避免latest导致溯源困难 - 在流水线日志中记录导出镜像的
Digest：docker images --digests | grep app:${TAG} - 禁止在导出脚本中硬编码敏感路径或密钥；使用CI工具提供的凭据管理（如Jenkins Credentials Binding）
