深入理解 Docker 镜像：从概念到本质
一、镜像到底是什么？
1. 官方定义 vs 通俗理解
官方定义：
Docker 镜像是一个只读的模板，包含创建 Docker 容器所需的完整文件系统和配置。
通俗比喻：
| 概念 |
类比 |
说明 |
| Docker 镜像 |
游戏的安装光盘 |
包含完整的游戏文件，但不能直接运行 |
| Docker 容器 |
安装后的游戏 |
可以运行的游戏程序 |
| Dockerfile |
游戏制作说明书 |
说明如何制作这张光盘 |
| Docker Registry |
游戏商店 |
存放各种游戏光盘的地方 |
更贴近生活的比喻：
1
2
3
4
5
6
7
8
9
10
11
| 1. 你买了一个【乐高玩具盒】 → 这就是【镜像】
- 盒子里有：积木块（文件） + 说明书（配置）
- 但不能直接玩，只是材料
2. 你按照说明书拼装 → 这就是【运行容器】
- 拼出来的【乐高模型】就是【容器】
- 可以玩，可以展示
3. 你拼了多个一样的模型 → 这就是【多个容器实例】
- 每个都是独立的
- 但都来自同一个玩具盒
|
2. 镜像的本质：分层的文件系统
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| 一个镜像 = 多个只读层（Layer）的堆叠
示例：一个简单的 Web 应用镜像
┌─────────────────────────────────────┐ ← 最上层（可写层，在容器中）
│ 你的应用程序文件 │
│ /app/index.html │ ← Layer 4（应用层）
├─────────────────────────────────────┤
│ 安装 Node.js 和依赖包 │
│ RUN npm install │ ← Layer 3（依赖层）
├─────────────────────────────────────┤
│ 复制你的应用代码 │
│ COPY . /app │ ← Layer 2（代码层）
├─────────────────────────────────────┤
│ 基础操作系统 │
│ FROM node:18-alpine │ ← Layer 1（基础层）
└─────────────────────────────────────┘
|
二、镜像里面到底是什么？
1. 镜像的物理结构
当你执行 docker pull ubuntu:latest，实际上下载了：
1
2
3
4
5
6
7
8
| ubuntu:latest 镜像包含：
├── 📁 layers/ # 镜像层目录
│ ├── sha256:a1b2c3... # 基础层（操作系统）
│ ├── sha256:d4e5f6... # 第二层（基础工具）
│ └── sha256:g7h8i9... # 第三层（应用文件）
├── 📄 manifest.json # 清单文件（描述各层关系）
├── 📄 config.json # 配置文件（元数据）
└── 📄 repositories # 仓库信息
|
查看镜像的层信息：
1
2
3
4
5
6
7
8
|
docker history ubuntu:latest
IMAGE CREATED CREATED BY SIZE
e4c58958181a 2 weeks ago /bin/sh -c
<missing> 2 weeks ago /bin/sh -c
<missing> 2 weeks ago /bin/sh -c
|
2. 镜像的真实内容
解压一个镜像看看里面有什么：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
docker save ubuntu:latest -o ubuntu.tar
tar -xf ubuntu.tar
ls -la
manifest.json
layer1.tar
layer2.tar
layer3.tar
...
tar -tf layer1.tar | head -20
bin/
bin/bash
bin/cat
bin/chmod
...
etc/
etc/passwd
etc/group
...
|
实际上，镜像就是：
1
2
3
4
5
6
| 一个完整的 Linux 文件系统快照，包含：
- /bin, /usr/bin # 可执行程序
- /etc # 配置文件
- /lib, /usr/lib # 库文件
- /home # 用户目录（通常为空）
- /app 或 /opt # 你的应用程序
|
三、镜像 vs 可执行文件
1. 根本区别：封装级别不同
| 特性 |
传统可执行文件 |
Docker 镜像 |
| 包含内容 |
单个程序文件 |
整个运行环境 |
| 依赖管理 |
需要手动安装依赖 |
包含所有依赖 |
| 运行环境 |
依赖宿主机环境 |
自带完整环境 |
| 隔离性 |
共享系统资源 |
资源隔离 |
| 部署方式 |
复制文件 + 安装依赖 |
直接运行 |
2. 具体对比示例
场景：部署一个 Python Web 应用
传统方式（可执行文件方式）：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
sudo apt install python3.9
pip install flask==2.0.1
pip install redis==4.0.0
pip install mysql-connector==2.2.9
export DATABASE_URL=mysql://...
export REDIS_URL=redis://...
scp app.py server:/home/user/
python3 app.py
|
Docker 镜像方式：
1
2
3
4
5
6
7
8
9
10
11
12
|
FROM python:3.9-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
ENV DATABASE_URL=mysql://...
ENV REDIS_URL=redis://...
CMD ["python", "app.py"]
|
1
2
3
4
5
6
7
|
docker run -d myapp:latest
|
3. 镜像运行原理
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| 当运行 `docker run ubuntu:latest` 时：
1. Docker 引擎：
- 读取镜像的 config.json
- 找到入口点（Entrypoint）和命令（CMD）
2. 创建容器层（可写层）：
┌─────────────────────────────────────┐
│ 容器可写层（Container RW Layer） │ ← 新增
├─────────────────────────────────────┤
│ 镜像层4：你的应用 │
│ 镜像层3：安装依赖 │
│ 镜像层2：复制代码 │
│ 镜像层1：基础系统 │
└─────────────────────────────────────┘
3. 启动进程：
- 使用镜像中定义的 Entrypoint（如 /bin/bash）
- 在容器隔离的环境中运行
- 所有文件访问都通过联合文件系统（UnionFS）定位
|
四、镜像的入口点：如何”执行”一个镜像
1. 镜像的启动命令定义
查看镜像的启动配置：
1
2
3
4
5
6
7
8
9
10
| docker inspect ubuntu:latest --format='{{json .Config}}'
{
"Cmd": ["/bin/bash"],
"Entrypoint": null,
"WorkingDir": "/",
"Env": ["PATH=..."],
...
}
|
2. 镜像启动的三种方式
方式1：直接运行镜像中的命令
1
2
3
4
5
6
7
|
docker run -it ubuntu:latest
docker run -d nginx:latest
|
方式2：覆盖默认命令
1
2
3
4
5
|
docker run ubuntu:latest ls -la /
docker run nginx:latest nginx -v
|
方式3：自定义入口点
1
2
3
4
5
|
FROM ubuntu:latest
COPY myapp /usr/local/bin/
ENTRYPOINT ["/usr/local/bin/myapp"]
|
3. 实际案例：各种类型镜像的”可执行文件”
| 镜像类型 |
实际入口 |
相当于执行 |
| Web 服务器 |
nginx -g "daemon off;" |
启动 Nginx 进程 |
| 数据库 |
mysqld |
启动 MySQL 服务 |
| 编程语言 |
python (交互模式) |
进入 Python REPL |
| 工具镜像 |
git 或其他工具 |
运行该工具 |
1
2
3
4
5
6
7
8
9
10
11
12
13
|
docker run redis:latest
docker run -it node:18
docker run alpine/git version
|
五、镜像 vs 虚拟机：完全不同的概念
对比表格
| 维度 |
Docker 镜像/容器 |
虚拟机镜像 |
传统可执行文件 |
| 封装内容 |
应用 + 依赖库 |
完整操作系统 + 应用 |
仅应用本身 |
| 运行方式 |
容器运行时 |
虚拟机监控器 |
操作系统直接执行 |
| 启动速度 |
秒级（<1秒） |
分钟级（30秒-数分钟） |
毫秒级 |
| 资源占用 |
MB 级，共享内核 |
GB 级，独立内核 |
KB-MB 级 |
| 隔离级别 |
进程级隔离 |
硬件级隔离 |
无隔离 |
| 性能损耗 |
1-5% |
15-30% |
几乎无损耗 |
| 镜像大小 |
几十MB到几百MB |
几GB到几十GB |
几KB到几百MB |
| 移植性 |
任何支持 Docker 的系统 |
特定虚拟化平台 |
特定操作系统 |
可视化对比
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| 传统部署： Docker部署：
┌─────────────────┐ ┌─────────────────┐
│ App A │ │ Container A │
├─────────────────┤ ├─────────────────┤
│ App B │ │ Container B │
├─────────────────┤ ├─────────────────┤
│ 各种依赖库 │ ├─────────────────┤
├─────────────────┤ │ Docker引擎 │
│ 操作系统/内核 │ ├─────────────────┤
└─────────────────┘ │ 主机操作系统/内核 │
主机 └─────────────────┘
主机
虚拟机部署：
┌─────────────────┐
│ App A │
├─────────────────┤
│ Guest OS │
├─────────────────┤
│ Hypervisor │
├─────────────────┤
│ Host OS/Kernel │
└─────────────────┘
|
六、创建自己的镜像：从 Dockerfile 到运行
1. 简单示例：创建一个可执行的镜像
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
FROM alpine:3.18
RUN apk add --no-cache \
curl \
bash \
python3
COPY hello.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/hello.sh
ENV NAME="World"
CMD ["/usr/local/bin/hello.sh"]
|
1
2
3
|
echo "Hello, ${NAME:-Docker}!"
|
2. 构建和运行
1
2
3
4
5
6
7
8
9
10
11
12
13
|
docker build -t myhello:latest .
docker image inspect myhello:latest
docker run myhello:latest
docker run -e NAME="GitHub" myhello:latest
|
3. 进阶：包含完整应用的镜像
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
ENV PYTHONUNBUFFERED=1
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]
|
七、镜像的存储格式：OCI 标准
1. 镜像格式规范
OCI（Open Container Initiative）镜像规范定义：
1
2
3
4
5
| 一个标准镜像包含：
1. Image Manifest - 镜像清单（描述各层和配置）
2. Image Configuration - 配置（架构、OS、入口点等）
3. Filesystem Layers - 文件系统层（实际文件内容）
4. Image Index - 镜像索引（多架构支持）
|
2. 实际存储结构
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
/var/lib/docker/
├── image/
│ └── overlay2/
├── containers/
└── volumes/
tree /var/lib/docker/image/overlay2/imagedb/content/sha256/
e4c58958181a...
├── manifest
├── diff
└── link
|
3. 镜像的传输格式
1
2
3
4
5
6
7
8
|
1. 客户端请求：我要 ubuntu:latest
2. Registry 返回：需要下载这些层：
- layer1: sha256:a1b2c3... (基础系统)
- layer2: sha256:d4e5f6... (更新包)
- layer3: sha256:g7h8i9... (配置)
3. 客户端逐层下载并校验
4. 本地组装成完整镜像
|
八、常见问题解答
Q1：镜像是可执行文件吗？
A：不完全是，但包含可执行文件。
镜像像一个自包含的软件包，里面包含：
- ✅ 可执行文件（如 /bin/bash, /usr/bin/python）
- ✅ 运行这些文件所需的环境
- ✅ 配置文件、依赖库、数据文件
Q2：镜像如何运行？
A：通过容器运行时启动。
1
2
3
4
5
6
| docker run myimage →
1. 提取镜像各层文件
2. 创建容器可写层
3. 设置隔离环境（命名空间、cgroup）
4. 执行镜像定义的 Entrypoint/CMD
5. 进程在容器内运行
|
Q3：一个镜像能运行多个程序吗？
A：可以，但不推荐。
1
2
3
4
5
6
7
8
9
10
11
|
CMD service nginx start && service mysql start && tail -f /dev/null
version: '3'
services:
web:
image: nginx:latest
db:
image: mysql:latest
|
Q4：镜像和容器的关系？
A：类 vs 实例，模板 vs 运行实例。
1
2
3
4
| 镜像（类/模板） → 容器（实例）
ubuntu:latest → 你的 Ubuntu 容器
nginx:alpine → 你的 Nginx 服务器
mysql:8.0 → 你的 MySQL 数据库
|
九、实际应用场景
场景1：开发环境一致性
1
2
3
4
5
|
docker run -v $(pwd):/app -it dev-image:latest
|
场景2：CI/CD 流水线
1
2
3
4
5
6
|
jobs:
test:
container: node:18-bullseye
steps:
- run: npm test
|
场景3：微服务部署
1
2
3
4
5
6
|
docker run -d --name auth auth-service:1.2.3
docker run -d --name api api-service:2.1.0
docker run -d --name db postgres:15
|
场景4：工具分发
1
2
3
4
5
6
7
8
9
|
docker run --rm curlimages/curl https://api.example.com
docker run --rm -v $(pwd):/work jrottenberg/ffmpeg -i input.mp4 output.avi
docker run --rm -v $(pwd):/app hashicorp/terraform plan
|
十、总结：镜像的核心价值
1. 镜像的三重身份
身份1：标准化的软件包
- 包含应用 + 所有依赖
- 版本明确，可重复部署
- 跨平台兼容（x86/ARM）
身份2：隔离的运行时环境
身份3：持续交付的载体
- CI/CD 的输出物
- 版本回滚的单元
- 蓝绿部署的基础
2. 一句话理解镜像
镜像 = 完整的、可移植的、自包含的软件运行环境快照
它不是单个可执行文件，而是一个完整的软件运行环境，被打包成一个可以随处运行的标准格式。
3. 类比总结
| 传统软件 |
Docker 镜像 |
优势 |
| “请在 Ubuntu 22.04 上安装 Python 3.9 和这些依赖…” |
docker run python-app:latest |
一键运行，环境一致 |
| “在我机器上好好的” |
“在任何有 Docker 的机器上都能运行” |
消除环境差异 |
| 复杂的安装文档 |
Dockerfile + 镜像 |
可重复，自动化 |
| 依赖冲突问题 |
隔离的环境 |
互不影响 |
最终答案：
镜像是包含完整运行环境的只读模板，不是单个可执行文件，而是能”变出”可运行容器的魔法盒子。
wechat
alipay