第二章: Docker 镜像 (Image) 深度解析与管理

在本章中，我们将沿着一条精心设计的路径，逐步揭开镜像的神秘面纱：

1. 首先，我们将回到软件部署的原点，探讨传统模式下的种种困境，从而理解 Docker 镜像所带来的革命性价值。
2. 接着，我们将深入镜像的内部构造，揭示其高效、轻量的秘密——联合文件系统与分层存储机制。
3. 然后，我们将全面掌握一套镜像管理的 基础操作技能，包括从远端获取、在本地查看和进行标记。
4. 紧接着，我们将学习 高效的镜像维护策略，学会清理无用镜像，释放宝贵的磁盘空间。
5. 最后，我们将探索一种重要的 离线交付方案，掌握在没有网络的环境中迁移和部署镜像的能力。

2.1. 标准化交付：镜像的价值与诞生背景

承上启下: 我们在第一章将镜像比作静态的“类”或“蓝图”。在深入其技术细节前，我们有必要先回到一切开始的地方，理解它为何被创造出来，以及它为软件开发世界带来了怎样的变革。

痛点背景: 想象一下在没有 Docker 的时代，将一个典型的 Web 应用（例如，一个 Node.js 后端 + PostgreSQL 数据库的项目）部署到一台新的服务器上，往往是一场充满不确定性的挑战：

• 环境不一致: 你的开发机是 macOS，运行着 Node.js v18.17.0；而生产服务器是 Ubuntu 20.04，其官方源的 Node.js 可能是 v12.x。这种细微的环境差异是导致应用异常的温床，催生了那句经典的开发者名言：“在我电脑上明明是好的！”
• 依赖地狱: 为了让应用跑起来，你需要在服务器上手动安装特定版本的 Node.js、PostgreSQL 客户端库，可能还需要 Redis、ImageMagick 等一系列系统级依赖。这个过程繁琐、容易出错，且难以自动化和复现。
• 交付物混杂: 你交付给运维的，可能是一个包含源代码的 zip 包，外加一份长长的 README.md 文档，上面写满了复杂的安装步骤和配置指南。这种代码与环境分离的交付方式，极大地增加了沟通成本和出错风险。

解决方案: Docker 镜像的诞生，正是为了终结这种混乱。

一个 Docker 镜像，可以被理解为一个 包含了运行一个应用所需一切的、标准化的、自给自足的软件包。这个“包”里不仅有你的应用程序代码，还固化了其运行时环境，包括：

• 应用运行时: 例如特定版本的 Node.js、Python 或 JRE。
• 系统工具库: 例如 curl、git 或其他基础命令。
• 操作系统文件: 应用运行所依赖的底层文件系统结构。
• 应用配置: 例如默认的配置文件、环境变量等。

通过将应用及其所有依赖“冷冻”在一个轻量级、可移植的镜像中，我们创造了一个 不可变 的交付单元。无论是在开发者的 Windows/WSL2、测试团队的 Linux 服务器，还是在云端的生产环境，这个镜像都能以完全相同的方式运行，从而从根本上消除了环境不一致的问题。

2.2. 镜像的内部构造：联合文件系统与分层存储

承上启下: 现在我们理解了镜像作为“标准化软件包”的重大价值。但一个新的问题随之而来：如果每次修改一行代码，就要重新制作和传输一个包含完整操作系统的、体积可能高达数百 MB 的“软件包”，那效率岂不是极其低下？Docker 的设计者早已预见了这一点，其解决方案就是镜像的 分层存储 机制。

痛点背景:

• 一个 ubuntu 基础镜像大约 70MB，一个 node 镜像大约 900MB。如果我基于 node 镜像只加入 1MB 的代码，最终的应用镜像难道是 901MB 吗？
• 我在拉取镜像时，控制台显示的 Pull complete 和 Already exists 是什么意思？

解决方案: 这种高效的背后，是 联合文件系统 在发挥作用。它是一种可以将多个目录（分支）在逻辑上合并成一个单一视图的文件系统。Docker 正是利用此技术，将镜像设计成由一系列 只读层 堆叠而成的结构。

• 层层叠加: 镜像的构建过程就像是搭积木。最底层通常是一个精简的操作系统（如 alpine），称为基础镜像。之后，每一个安装软件、复制文件或修改环境的动作，都会在其上叠加一个新的、只读的层。
• 共享与复用: 这种分层结构的最大优势在于 最大限度地资源共享。如果你本地有 node:18 和 node:19 两个镜像，它们共同依赖的许多底层系统库（例如 debian 的基础层）在磁盘上只会存储一份。当你拉取新镜像时，Docker 会检查哪些层你本地已经拥有，并直接跳过下载，只拉取你没有的增量层，这也就是你看到 Already exists 的原因。

当我们基于此镜像启动一个容器时，Docker 会在这个只读的层堆栈之上，再添加一个纤薄的 可写“容器层”。你在容器内对文件系统的所有修改，都发生在这个可写层，而下方的所有镜像层都保持不变。

我们可以通过 docker history 命令来直观地看到一个镜像的“积木”是如何搭建起来的。

1
2
3
4
5

# 为了确保示例一致，我们先拉取一个特定版本的 nginx 镜像
docker pull nginx:1.25.2

# 查看该镜像的历史分层信息
docker history nginx:1.25.2

1
2
3
4
5
6
7
8
IMAGE          CREATED        CREATED BY                                      SIZE      COMMENT
176252F220A8   5 months ago   /bin/sh -c #(nop)  CMD ["nginx" "-g" " daemo…   0B        
<missing>      5 months ago   /bin/sh -c #(nop)  STOPSIGNAL SIGQUIT           0B        
<missing>      5 months ago   /bin/sh -c #(nop)  EXPOSE 80                    0B        
<missing>      5 months ago   /bin/sh -c #(nop)  ENTRYPOINT ["/docker-ent…   0B        
<missing>      5 months ago   /bin/sh -c #(nop)  COPY file: ce423... in /do…   4.62kB    
...
<missing>      5 months ago   /bin/sh -c #(nop)  ADD file: e6a6a... in /       72.8MB    

2.3. 基础操作：获取、查看与标记镜像

承上启下: 有了对镜像分层结构的清晰认知，我们现在可以满怀信心地开始与这些“蓝图”进行交互了。下面是你在日常工作中会用到的最核心的镜像管理命令。

1. 获取镜像 (docker pull)

此命令用于从远程的镜像仓库（Registry），如官方的 Docker Hub，下载镜像到你的本地机器。

1
2
3
4
5
6
7
8
9

# 语法: docker pull [REGISTRY_HOST/][USERNAME/] NAME [: TAG]

# 从 Docker Hub 拉取官方最新的 Ubuntu 镜像
# Docker 会自动拉取 TAG 为 latest 的版本
docker pull ubuntu

# 拉取一个指定版本的、极度轻量化的 Alpine Linux 镜像
# 在生产环境中，强烈推荐使用明确的 TAG 来保证环境一致性
docker pull alpine:3.18

在拉取过程中，你可以清晰地看到 Docker 正在逐层下载，并对已存在的层进行复用。

2. 查看本地镜像 (docker images 或 docker image ls)

此命令会列出你本地存储的所有镜像。

1

docker images

1
2
3
4
5
REPOSITORY   TAG          IMAGE ID       CREATED        SIZE
nginx        1.25.2       176252f220a8   5 months ago   187MB
ubuntu       latest       6b7dfa7e8fdb   5 months ago   77.8MB
alpine       3.18         146313f01743   6 months ago   7.34MB
hello-world  latest       fedb12345678   10 months ago  9.14kB

• REPOSITORY: 镜像的名称，标识了这是什么软件。
• TAG: 镜像的标签，通常用于表示版本。一个 IMAGE ID 可以有多个标签。
• IMAGE ID: 镜像的唯一身份 ID，是其内容的 SHA256 哈希值摘要。
• SIZE: 镜像所有层解压后的大小总和。

3. 为镜像添加标记 (docker tag)

此命令并不会创建或复制一份新的镜像实体，它只是为某个已存在的 IMAGE ID 创建一个额外的引用或别名。这在推送镜像到私有仓库或进行版本管理时至关重要。

场景: 假设你基于 alpine:3.18 制作了自己的应用，现在想把它标记为 my-app:1.0。

1
2
3
4
5
6
7

# 语法: docker tag SOURCE_IMAGE [: TAG] TARGET_IMAGE [: TAG]

# 为 alpine: 3.18 镜像创建一个新的标签 my-app: 1.0
docker tag alpine:3.18 my-app:1.0

# 再次查看本地镜像列表
docker images

1
2
3
4
REPOSITORY   TAG          IMAGE ID       CREATED        SIZE
my-app       1.0          146313f01743   6 months ago   7.34MB
alpine       3.18         146313f01743   6 months ago   7.34MB
...

2.4. 高效管理：清理磁盘空间与镜像维护

承上启下: 随着你不断地拉取和构建镜像，本地磁盘空间会逐渐被占用。学会如何安全、高效地进行“大扫除”是每位 Docker 实践者的必备技能。

痛点背景:

• 随着时间推移，系统中会积累大量旧版本或在构建过程中产生的中间镜像。
• 有时会出现一些没有 REPOSITORY 和 TAG，显示为 <none> 的镜像，这些被称为“悬浮镜像”(dangling images)，它们是清理的首要目标。

1. 删除镜像 (docker rmi 或 docker image rm)

1
2
3
4
5
6
7
8

# 语法: docker rmi IMAGE_NAME: TAG  或者  docker rmi IMAGE_ID

# 删除我们之前创建的 my-app: 1.0 标签
# 注意：这只是删除了一个标签，实际的镜像数据还在，因为 alpine: 3.18 还在引用它
docker rmi my-app:1.0

# 只有当最后一个指向该 IMAGE ID 的标签被删除后，镜像数据才会被真正删除
docker rmi alpine:3.18

2. 自动化清理 (docker image prune)

这是一个极其有用的命令，用于批量清理不再需要的镜像。

1
2
3
4
5
6
7
8
9
10

# 该命令会安全地删除所有悬浮的（dangling）镜像
docker image prune

# ---- 谨慎操作的参数 ----

# -a 或 --all 参数会删除所有当前没有任何容器正在使用的镜像，而不仅仅是悬浮镜像
docker image prune -a

# --filter 参数可以更精细地控制，例如删除所有在 24 小时前创建的、未被使用的镜像
docker image prune -a --filter "until=24h"

定期执行 docker image prune 是保持开发环境整洁的好习惯。

2.5. 离线交付：镜像的导入与导出

承上启下: 标准的镜像分发依赖于镜像仓库，但如果你需要将镜像部署到一台无法访问外网的“内网”或“离线”服务器呢？这时，手动的导入导出功能就派上了用场。
docker save 命令可以将一个或多个本地镜像打包成一个单一的 .tar 归档文件。这个文件是镜像的完整快照，包含了所有的层和元数据。

适用场景: 备份镜像，或将其打包以便拷贝到离线环境中。

1
2
3
4
5
6

# 将本地的 nginx: 1.25.2 镜像保存为 nginx-image.tar 文件
docker save -o nginx-image.tar nginx:1.25.2

# 你会得到一个实实在在的 tar 文件，可以随意传输
# ls -lh nginx-image.tar
# -rw------- 1 user user 180M Sep 18 17:30 nginx-image.tar

docker load 命令是 save 的逆向操作。它从指定的 .tar 文件中读取数据，并将镜像完整地加载到本地的镜像库中。

适用场景: 在离线服务器上，从 .tar 文件恢复镜像。

1
2
3
4
5

# 假设我们已将 nginx-image.tar 文件拷贝到了目标服务器
# 从该文件中加载镜像到 Docker
docker load -i nginx-image.tar

# 加载完成后，执行 docker images 就能看到 nginx: 1.25.2 这个镜像了

2.6. 本章核心速查总结

本章我们深入了 Docker 镜像的“灵魂”——分层存储，并掌握了一套完整的命令行管理工具。

总结要点:
镜像是 Docker 工作流的起点。深刻理解其 分层、共享、只读 的本质，是后续学习 Dockerfile 优化、实现高效 CI/CD 的关键。熟练运用本章的管理命令，能确保你的开发环境始终保持整洁和高效。

2.7. 高频面试题与陷阱