Docker基础教程（三十八）基本操作之导入容器的docker import命令：别再“镜像”搬家了！Docker import：你的专属时光机与镜像瘦身大师

最新推荐文章于 2025-09-24 07:57:55 发布

原创最新推荐文章于 2025-09-24 07:57:55 发布 · 1.3k 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#docker #eureka #容器

Docker基础教程专栏收录该内容

258 篇文章

订阅专栏

在Docker的浩瀚宇宙中，我们习惯了使用docker pull从仓库拉取现成的镜像，用docker build配合Dockerfile构建规整有序的镜像。然而，总有一些场景，需要一点“野路子”，一点更直接、更底层的操作。这时，docker import命令就像一位隐藏在角落里的扫地僧，其貌不扬，却身怀绝技。

今天，就让我们抛开常规，潜入底层，深度分析这个充满“网感”和“黑客气息”的docker import命令，看看它如何成为我们的专属时光机和镜像瘦身大师。

一、灵魂拷问：import 是什么？和 load 是亲兄弟吗？

首先，我们必须澄清一个最常见的误解：docker import 和 docker load 不是一回事！虽然它们都吃 .tar 文件，但消化方式天差地别。

docker load：镜像的“完美复刻”
它用于载入一个由 docker save 导出的完整镜像库（repository）。这个压缩包（.tar 或 .tar.gz）里保存的是镜像的完整信息，包括所有的分层（layer）、元数据（metadata）、标签（tag）和历史记录（history）。加载后，就像是把整个镜像家族，连同它们的族谱，原封不动地搬到了你的本地仓库。这是一种“镜像到镜像”的迁移。
docker import：文件系统的“灵魂注入”
它用于将一个文件系统归档（一个 tar 文件）导入为一个全新的、单一的镜像层。这个 tar 文件可以来自任何地方：一个正在运行的容器的文件系统快照、一个使用 tar 命令打包的目录、甚至是手动构建的根文件系统。import 会丢弃原镜像的所有历史和信息，只为这个新的文件系统快照创建一个新的、独立的镜像。这是一种“文件系统到镜像”的创造。

简单比喻：

docker load 像是一键还原整个电脑系统镜像（C盘、D盘、程序、设置全都在）。
docker import 像是你手动整理好了一个C:\Windows文件夹，然后把它变成了一个全新的、可以启动的操作系统安装盘，但这个盘里只有系统文件，没有你原来的任何个人数据或程序历史。

理解了这核心区别，我们就掌握了import的第一要义：它从文件系统创造镜像，而非恢复镜像。

二、庖丁解牛：import 命令语法与核心参数

命令语法非常简单，但其内涵深远：

docker import [选项] <文件>|<URL>|- [镜像名[:标签]]

文件|URL|-：

- 文件：最常见的来源，本地文件系统上的 tar 归档文件路径。
- URL：可以直接从一个远程地址（如HTTP链接）下载并导入归档文件。
- -：一个神奇的符号，代表从标准输入（stdin）读取数据流。这允许我们使用管道(|)将其他命令的输出直接传递给import，实现无缝衔接。

[选项]：

- -c, --change：灵魂所在！允许你在导入过程中应用Dockerfile指令来修改镜像配置。这是让一个“死”的文件系统“活”起来的关键。支持的指令有：

- - CMD：设置容器启动时默认执行的命令。
  - ENTRYPOINT：设置容器启动时的入口点。
  - ENV：设置环境变量。
  - EXPOSE：声明运行时容器提供服务的端口。
  - USER：设置运行时的用户。
  - WORKDIR：设置工作目录。

- -m, --message：为导入的镜像提交信息，类似于git的commit message。

[镜像名[:标签]]：
为你新创造的镜像指定名称和标签。如果不指定标签，默认为latest。

三、实战演练：完整示例——打造一个极简的Nginx服务器镜像

理论说得再多，不如动手一试。假设我们有一个特殊的需求：我们需要一个极度精简的、只包含我们自定义配置和网页的Nginx镜像，而不需要任何Dockerfile构建过程中可能带来的冗余层或历史。

场景：我们有一台Ubuntu服务器，上面已经手动编译并安装了Nginx，并且放置了我们的网页项目。现在我们想把这个“黄金状态”的服务器环境直接打包成一个Docker镜像。

步骤1：在目标机器上准备文件系统并打包
首先，我们登录到这台Ubuntu服务器。假设Nginx安装在/usr/local/nginx，我们的网页放在/data/www。

# 创建一个包含所有所需文件的tar包
# 注意：我们是在宿主机上操作，不是在容器里！
sudo tar -czf nginx-base.tar.gz \
    /usr/local/nginx \
    /data/www \
    /lib/x86_64-linux-gnu/libnss* \ # 别忘了打包一些可能的依赖库
    /etc/passwd /etc/group # 基础账户信息

(注意：这是一个简化示例。实际生产中，精准地打包所有依赖项非常复杂，通常更推荐用Dockerfile构建。但这种方法在“抢救”或“克隆”特定环境时非常有用。)

步骤2：将打包文件传输到Docker主机
使用scp或其他工具将nginx-base.tar.gz文件传到我们运行Docker的机器上。

scp nginx-base.tar.gz user@docker-host:/tmp/

步骤3：使用docker import创造奇迹
现在，在我们的Docker主机上操作。

# 进入文件所在目录
cd /tmp

# 使用docker import命令，并通过--change设置启动命令
docker import \
    --change "CMD [/usr/local/nginx/sbin/nginx, -g, 'daemon off;']" \
    --change "EXPOSE 80" \
    nginx-base.tar.gz \
    my-custom-nginx:v1.0

# 输出类似：sha256:a67c0fb6f0b3c5f63a43d47c478a4b19a67c0fb6f0b3c5f63a43d47c478a4b19

命令解析：

--change "CMD ..."：让这个镜像在启动为容器时，默认执行Nginx命令，并以daemon off;方式在前台运行（这是Docker容器的最佳实践）。
--change "EXPOSE 80"：声明这个镜像内部的应用程序会使用80端口。
nginx-base.tar.gz：是我们的“材料”。
my-custom-nginx:v1.0：是我们创造出的新镜像的名字和标签。

步骤4：验证我们的作品

# 查看镜像列表，应该能看到它
docker images my-custom-nginx

# 运行一个临时容器来测试
docker run -d --rm --name nginx-test -p 8080:80 my-custom-nginx:v1.0

# 访问一下，看看是否成功
curl http://localhost:8080

# 如果看到网页内容，恭喜你，成功了！

步骤5（高级玩法）：使用管道“无文件”导入
如果我们能通过SSH直接访问那台Ubuntu服务器，甚至可以跳过创建中间文件的步骤：

# 在Docker主机上执行一条命令
ssh user@target-server "sudo tar -czf - /usr/local/nginx /data/www" | \
docker import \
    --change "CMD [/usr/local/nginx/sbin/nginx, -g, 'daemon off;']" \
    - \
    my-custom-nginx:ssh-version

这里，ssh命令在远程服务器上执行打包，并将数据流（-f -）输出到标准输出，然后通过管道|直接传递给本地的docker import，而import使用-从标准输入读取。一气呵成，中间不产生任何临时文件！