Docker镜像与容器：搞懂容器化的基础

可视化演示

展示Docker镜像分层存储架构、容器生命周期状态流转、以及多阶段构建优化与数据卷持久化。

镜像分层原理

蛋糕店中央厨房里，一块冷冻芒果慕斯胚并不是一坨面团压出来的，而是一层一层叠起来的：最底下是戚风蛋糕底，抹一层奶油，铺一层芒果粒，最后淋上镜面果胶。每一层都在不同工位批量做好，再按固定顺序叠放。这样做最大的好处是：不同款式的蛋糕可以共用同一款戚风底，中央厨房不用为每款蛋糕重新烤底。

Docker 镜像的结构和这块蛋糕胚一模一样。一个镜像并不是磁盘上的一个大文件，而是由一层层只读文件系统叠加而成。Dockerfile 里的每一条指令，都会在原有层之上生成一个新的层。ubuntu:22.04 是最底层的蛋糕底，RUN apt-get install python3 是抹上的奶油层，COPY app.py 是铺上的芒果粒。每一层构建完成后就不可变，只能在其之上加新层，不能回头修改旧层。

这种分层设计带来了两个巨大好处。第一是层复用：十几个不同镜像都用 ubuntu 做底时，宿主机只需要存一份 ubuntu 层，剩下的各自存各自的增量层，磁盘占用急剧下降。第二是容器轻量：容器启动时，Docker 并不会复制整个镜像，而是在镜像层顶上叠加一个可写层，容器内所有的写操作都发生在这一层——就像客人吃蛋糕时，只是在蛋糕胚上临时加了颗草莓，胚子本身没有动。

回到蛋糕店：冷柜里一摞摞蛋糕胚，不同款式共用同一款戚风底，谁需要谁取。客人吃的“胚子加临时加料”，加料只在最顶部那一层，底下的胚子永远不会被碰坏。理解了镜像分层的“冷冻胚子思维”，后面所有容器操作都顺理成章了。

Dockerfile编写

蛋糕店的招牌背后，一定有一本写满配方的菜谱：选什么胚子、加多少奶油、烤多久、如何摆盘。按照菜谱操作，一百次做出来味道都一样。店员换了一茬又一茬，蛋糕品质却始终稳定——菜谱就是这家店的“不可变资产”。

Dockerfile 就是镜像的菜谱。它用文本形式逐行声明“如何从一个基础镜像构建出最终镜像”。最常见的四个指令是：FROM 指定基础镜像，相当于“选胚子”；RUN 执行命令安装依赖、创建目录，相当于“加料”；COPY 把本地的代码和配置文件拷进镜像，相当于“把准备好的配料摆上去”；CMD 规定容器启动时执行什么进程，相当于“上桌流程”。每一条指令执行完，都会在文件系统上产生增量，这个增量被打包成一个新层。

把 Dockerfile 写好，镜像的构建就变成了一条自动化流水线。你不需要记住每一步手动操作，只需要维护这份菜谱。而且由于层是增量的，构建时可以逐层比对缓存：只要某层的指令和上下文没变，构建系统就直接复用旧层，跳过执行，这就是后面要讲的构建缓存。菜谱写得越清晰，层的划分越合理，构建和复用就越高效。

菜谱里改一行字，做出来的蛋糕就不一样；Dockerfile 里改一条指令，镜像就多出一层或变了一层。正因如此，Dockerfile 在团队里要像菜谱一样被认真 review 和版本管理——它是可复现部署的根基。

容器生命周期

一块蛋糕从客人下单到收盘倒垃圾，有一个完整的一生：下单（订单生成）、后厨开工（制作中）、暂停等客人（暂缓）、端上桌被吃完（结束）、收盘倒掉（清理）。蛋糕店老板必须清楚每一份蛋糕处于哪个阶段，后厨才不会乱成一团。

容器也有这样一套生命周期状态。docker create 基于镜像生成一个容器实例，此时容器处于 created 状态，进程还没启动，就像订单刚生成、后厨还没动手。docker start 启动容器，进程运行起来，进入 running 状态。docker pause 可以冻结容器内所有进程（发 SIGSTOP 信号），对应 paused 状态，类似后厨接到电话让蛋糕先别做。docker stop 优雅停止容器（发 SIGTERM，超时后 SIGKILL），进程退出，容器进入 stopped 状态——注意此时容器的文件系统还在磁盘上，随时可以 start 重新启动。最后 docker rm 删除容器，把可写层彻底清理掉。

理解状态流转对排障至关重要。比如容器启动后立刻退出，多半是启动命令执行失败，要看退出码和日志；比如 docker ps 默认只显示 running 状态的容器，想看所有容器要加 -a 参数。状态之间可以双向或单向迁移，但有几个铁律：只有 stopped 状态的容器才能被安全删除，paused 的容器必须先 unpause 才能停止。

盘子收了、蛋糕没了，但冷柜里的胚子还在——镜像没被删，随时可以几分钟再做一个。容器之所以“轻”，就是因为它只是一层薄薄的可写层，盖在大家共享的只读胚子上，删掉这层，胚子毫发无损。

常用命令实战

后厨的墙上挂着一排趁手的工具：看库存的、进货的、下单的、查订单的、看烤箱状态的、进冷库的、倒垃圾的。一个熟练的店长闭着眼都能摸到对应的工具，蛋糕店才能高效运转。

Docker 的命令体系就是后厨的这套工具墙。镜像管理：docker images 查看本地所有镜像（库存清单），docker pull 从仓库拉取镜像（进货），docker rmi 删除本地镜像（清理过期库存）。容器操作：docker run 是最高频的一条命令，它等价于“如果本地没有镜像就 pull + create + start”一条龙；docker ps 查看运行中的容器（当前订单），加 -a 看全部；docker rm 删除容器。日志与进入：docker logs 查看容器输出（看烤箱状态），docker exec -it <容器> bash 进入容器内部排查问题（进后厨巡一圈）。资源查看：docker top 看容器内进程列表，docker stats 实时监控 CPU、内存、网络和磁盘 IO。

初学者最容易混淆的是 run 和 start：run 是从镜像新建容器并启动，start 是启动一个已存在的 stopped 容器。前者每次都会生成一个新的容器 ID，后者复用同一个容器。所以如果你改动了代码重新构建了镜像，一定要重新 run，而不是 start 旧容器——旧容器的可写层里还是老代码。

把这些命令用熟，你就能像店长管理后厨一样，条理清晰地管理一整台服务器上的几十个容器：知道库存有什么、哪些订单在跑、哪个容器出了问题、问题出在哪一层。

构建优化秘诀

好的蛋糕店有两间厨房：备料厨房里堆着面粉、鸡蛋和搅拌机，又脏又乱；出餐厨房只放烤好的胚子、奶油和水果，干净整洁。客人永远不会走进备料厨房——他们只关心端上桌的那块蛋糕，而不是后厨有多少工具。

镜像构建也遵循同样的哲学，这就是多阶段构建。在一个 Dockerfile 里写多个 FROM 指令，前几个阶段是“备料厨房”：装编译器、跑测试、构建产物；最后一个阶段是“出餐厨房”：从一个干净的基础镜像开始，只把前几个阶段构建出的产物 COPY 过来，所有编译器、临时文件、缓存统统不带走。最终镜像只包含运行必需的东西，体积大幅缩小。

除了多阶段构建，还有三个常见的优化手段。第一是镜像瘦身：尽量使用 alpine 等精简基础镜像、安装依赖后清理 apt 缓存、不要 COPY 多余的本地文件。第二是利用构建缓存：把变化最少的指令写在 Dockerfile 最前面（先 COPY 依赖清单文件再 RUN 安装，而不是先 COPY 全部代码），这样代码改动时依赖层还能命中缓存。第三是 .dockerignore：像 .gitignore 一样，把 node_modules、.git、日志等排除在构建上下文之外，既减小上传体积，又避免不该进镜像的文件混入。

端上桌的蛋糕只需要胚子加点缀，不需要把整个备料厨房一起端上来。多阶段构建让“备料”和“出餐”彻底分离，镜像体积可以从几百 MB 瘦到几十 MB，拉取时间从分钟级降到秒级，部署体验天差地别。

安全加固实践

蛋糕店打烊之后，店长会做三件事：把冷柜锁上（限制访问）、切掉不必要的电源（限制资源）、给员工配门禁卡而不是大门钥匙（最小权限）。这三道防线看起来不起眼，却能挡住绝大多数安全事故。

容器安全加固的思路如出一辙。第一道防线是非 root 运行：容器内默认以 root 用户运行，如果应用被攻破，攻击者就拿到了容器内的最高权限。在 Dockerfile 里用 RUN useradd app 创建普通用户，再 USER app 切换，配合 Kubernetes 的 runAsNonRoot 强制约束，把攻击面压到最小。第二道防线是只读文件系统：用 --read-only 挂载容器根文件系统，应用就无法往容器可写层写入恶意文件，需要写临时文件时单独挂载 tmpfs 或数据卷。第三道防线是资源配额限制：用 --memory 512m --cpus 1 限制容器的内存和 CPU，防止某个失控容器把宿主机资源耗尽，拖垮同主机的其他容器。

此外还有一道防线容易被忽略：镜像漏洞扫描。用 trivy、clair 等工具扫描镜像中的操作系统包和应用依赖，找出已知 CVE 漏洞，在构建阶段就拦截问题镜像。安全不是上线后的补救，而是从 Dockerfile 第一行就开始的约束。

店铺安防做扎实了，才敢放心把蛋糕店开在云上这种人流密集的地方。同理，容器跑在共享内核的宿主机上，安全加固不是可选项而是必选项——每一道防线都在帮你降低“一锅端”的风险。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""模拟Docker分层镜像与容器可写层机制"""import os  class ImageLayer(object):    """只读镜像层: 保存文件路径到字节内容的映射"""    def __init__(self, name, files):        self.name = name        self.files = dict(files)        self.readonly = True     def read(self, path):        return self.files.get(path)  class Container(object):    """容器: 镜像只读层之上叠加一个私有可写层"""    def __init__(self, image_layers):        self.image_layers = image_layers        self.writable = {}  # 可写层: 修改或新增的文件     def read(self, path):        # 先查可写层, 再逐层向下查找镜像层        if path in self.writable:            return self.writable[path]        for layer in self.image_layers:            content = layer.read(path)            if content is not None:                return content        return None     def write(self, path, content):        # 写入可写层, 不改动任何镜像层        self.writable[path] = content  def main():    # 构建一个三层镜像: 基础层 + 依赖层 + 应用层    base = ImageLayer("ubuntu-base", {"/etc/os-release": b"Ubuntu 22.04 LTS"})    deps = ImageLayer("python-deps", {"/usr/bin/python3": b"python3.10",                                      "/usr/bin/pip3": b"pip3"})    app = ImageLayer("app-code", {"/app/main.py": b"print('hello docker')"})    image = [base, deps, app]     # 容器1: 读取镜像, 写入新配置    c1 = Container(image)    c1.write("/app/config.yaml", b"lr=0.01")    print("[容器1] 读到main.py:", c1.read("/app/main.py"))    print("[容器1] 读到config.yaml:", c1.read("/app/config.yaml"))     # 容器2: 与容器1共享同一份镜像, 但看不到容器1的写入    c2 = Container(image)    print("[容器2] 读到config.yaml:", c2.read("/app/config.yaml"))    print("[容器2] 读到os-release:", c2.read("/etc/os-release"))    print("镜像层未被修改:", base.files["/etc/os-release"] == b"Ubuntu 22.04 LTS")  if __name__ == "__main__":    main()

1. class Container(object):每个容器实例拥有独立的可写层，对应 docker create 出来的容器
2. self.image_layers = image_layers所有容器共享同一份只读镜像层，这就是镜像分层的复用机制
3. self.writable = {}容器私有的可写层，存放对文件的修改和新增
4. if path in self.writable:先查可写层，模拟容器内“修改优先看到自己写的”行为
5. for layer in self.image_layers:按层从上往下查找文件，模拟联合文件系统的合并视图
6. c1.write("/app/config.yaml", ...)写操作只落在可写层，不触碰任何镜像层
7. c2.read("/app/config.yaml")容器2读不到容器1的写入，容器间完全隔离
8. base.files["/etc/os-release"]镜像层内容原封不动，验证镜像的不可变性

常见误区

面试题