★ FEATURED ARTICLE 1. 从“部署翻车”说起为什么必须先搞懂镜像这几年陆陆续续带过不少新人上手 Docker我发现一个特别有意思的规律凡是后续容器玩得溜的人几乎都在镜像上花过足够的时间凡是 Docker 用得磕磕绊绊的人基本都是没弄明白镜像到底是什么就开始“docker run”结果一出问题就抓瞎。最典型的一套“连环翻车”长这样某开发者在服务器上执行docker run nginx发现镜像拉取极慢于是开始怀疑网络好不容易拉下来了docker run -d nginx启动容器页面却访问不了于是又开始排查端口折腾半天发现是-p参数挂错了改正之后页面出来了但容器一重启改过的配置全没了。问他为什么他说“我明明改了容器里的文件啊”。这套路我见得太多了根子就在一件事上他不知道 Docker 镜像是一层一层堆叠出来的只读模板也不知道容器只是在镜像上面加了一层可写层。这两个概念没建立起来后面所有的排查都只能靠猜。所以这篇文章我不打算走那种“def 一个概念然后跑一个 hello world”的敷衍路子而是把镜像这块掰开了揉碎了讲透。从镜像的分层原理、生命周期管理到亲手构建一份可落地的自定义镜像再到生产环境里体积优化和安全性加固最后附上我踩过的坑和处理思路。整套内容如果消化下来你对镜像的理解应该能超过绝大多数“会用 Docker 但不懂镜像”的开发者。这篇内容适合谁如果你是刚接触 Docker 的新手建议逐节看下来如果你已经写过 Dockerfile 但对分层、缓存、多阶段构建这些概念只停留在“用过”层面可以直接跳到第 3 节之后的内容。我尽量把“是什么”和“为什么”讲透再落到“怎么做”。2. 镜像的本质与分层模型读这一节比跑 100 次 docker run 都值2.1 镜像不是“一个文件”而是一摞只读层的逻辑视图很多人第一次接触镜像会在潜意识里把它类比成虚拟机镜像——一个几百兆到几个 GB 的“大文件”。这个类比帮不了你多少因为 Docker 镜像的本质是一组分层layer的集合每一层都记录了对文件系统的一次增量变更。打个比方镜像像千层饼。面粉、糖、黄油各自是不同层烤出来之后你看到的是一个完整的饼但层次结构是真实存在的。镜像是同样的道理基础镜像是最下面几层每执行一条 Dockerfile 指令就往上叠一层。真正被启动时这些层被联合挂载到一个统一的视图里对容器进程来说它看到的就是一个完整的、正常的根文件系统。这个分层模型带来两个直接收益空间效率多个镜像可以共享底层的基础层比如 ubuntu、python、nginx 镜像如果都基于同一个基础系统那么相同的那几层在磁盘上只存一份。实测我本机的/var/lib/docker/overlay2目录里几十个镜像的总磁盘占用远小于所有镜像大小之和靠的就是层复用。传输效率拉取镜像时只有本地缺失的层才需要下载Docker Hub 的镜像加速在很多场景下体验还不错有一部分功劳就是分层复用。2.2 只读层与可写层容器修改文件时到底发生了什么容器和镜像最核心的区别就一句话镜像是只读的容器是镜像加一个可写层。启动容器时Docker 在镜像之上加一个可写层也叫容器层所有对文件系统的写入操作包括新增文件、修改文件、删除文件都发生在这一层。镜像本身从头到尾不会变所以同一个镜像可以启动出无数个互不影响的容器每个容器都有自己独立的那一层变更。这里有一个非常容易踩坑的点很多人以为“在容器里改了文件镜像就变了”误以为把容器像虚拟机一样用。事实上你docker rm掉一个容器你在容器里所有的修改——无论你当时觉得自己改得多重要——全部灰飞烟灭。这就是为什么我强调任何需要持久化的东西要么用数据卷挂载出来要么在 Dockerfile 里把变更固化到镜像里而不是依赖“容器可写层”这个临时区域。另一个相关概念是写时复制Copy-on-Write, CoW机制。当容器要修改一个镜像层里的文件时Docker 不会直接改底层文件而是把这个文件复制到容器的可写层再修改。这样做的好处是即使成百上千个容器共享同一个底层镜像每个容器修改同一个文件时只会复制自己要改的那一份互不干扰。代价是首次写入性能稍慢但绝大多数场景下感知不到差异。2.3 基础镜像、父子镜像与 tag别再把 tag 当成固定版本号在镜像的关系网络里有基础镜像base image和父镜像parent image之分。基础镜像一般指完全从零构建、只有内核之外的用户态文件系统如一些精简的发行版镜像父镜像则是 Dockerfile 里FROM指定的那个镜像。我们平时写FROM ubuntu:22.04ubuntu 就是父镜像。tag标签的坑也不少。nginx:latest只是“默认读到的最近一次推送的标签”它不保证任何版本稳定。在本地latest永远指向你最近拉过的那个版本不同时间拉取结果可能完全不同。生产环境我强烈建议用具体的版本 tag而不是latest同时在使用前确认该 tag 的发布时间和平台架构避免在 x86 服务器上拉到 ARM 镜像导致启动失败。3. 镜像的获取、保存与生命周期管理日常高频操作全梳理3.1 拉取、查看、删除三个高频命令的使用情境先看拉取。docker pull nginx:1.24Docker 会先检查本地是否存在相同层缺失的层才从仓库获取。如果你要部署的机器很多可以考虑内网搭建一个镜像仓库做中转直接把分层复用红利放在基础设施层面而不是靠每台机器各自去外网拉。查看镜像用docker images它会列出仓库名、tag、镜像 ID、创建时间和大小。这里有个容易误解的点镜像 ID 是镜像的 SHA256 摘要的一部分而docker images显示的大小是镜像所有层的总和但不包含共享层被重复计算的部分所以“所有镜像大小加起来之后远大于磁盘实际占用”是完全正常的。删除镜像用docker rmi 镜像ID或名称:tag。当同一个镜像 ID 被多个 tag 引用时删除其中一个 tag 不会真正释放镜像数据只有所有 tag 都被移除后镜像层才会被清理。另外容器还在运行时镜像通常无法被删除需要先把容器停掉并docker rm否则会报“image is being used by running container”的错误。3.2 镜像导入导出离线环境里的救命手段内网环境或者没有外网权限的机房docker pull基本是废的这时候docker save和docker load就能发挥作用。# 在有外网的机器上导出镜像 docker save nginx:1.24 -o nginx-1.24.tar # 传到目标机器后导入 docker load -i nginx-1.24.tar需要提醒的是docker save保存的是整个镜像的所有层和元数据体积相对较大如果你只需要把容器里的文件拷出来应该用docker cp如果你需要把容器迁移到另一台机器且容器内容需要保留推荐先docker commit把容器固化成镜像再docker save。有几个版本因为 containerd 和 Docker 的镜像格式差异docker save出来的 tar 在部分镜像仓库工具上兼容性不太一致建议先在一个测试环境走通再批量操作。3.3 镜像仓库选择官方仓库、私有仓库与镜像加速Docker Hub 是默认的公共仓库开发者用得最多。但它在部分网络环境下拉取速度不稳定所以就有了镜像加速器的概念你配置一个加速地址Docker 拉镜像时会从加速器缓存获取。在生产环境我更推荐使用私有镜像仓库常见开源方案是维护一个本地 registry 服务。推送镜像的命令docker tag myapp:v1.0 registry.internal.example.com/myapp:v1.0 docker push registry.internal.example.com/myapp:v1.0配置私有仓库有几个要点HTTPS 证书要提前配好如果是内网 HTTP 访问需要在 Docker daemon 配置里把该地址加入 insecure-registries 列表推送前务必确认 tag 使用了完整的仓库地址前缀否则默认推送公网仓库。4. 手把手构建自定义镜像从 Dockerfile 到多阶段构建4.1 Dockerfile 指令速查与选型逻辑Dockerfile 本质上就是“让镜像可复现地构建出来的配方文件”核心指令我按使用频率整理成表指令作用使用建议FROM指定基础镜像尽量选官方镜像和固定 tagWORKDIR设置工作目录统一路径避免到处 cdCOPY / ADD复制文件进镜像优先 COPYADD 只在需要解压时用RUN执行命令并提交新层尽量合并控制层数ENV设置环境变量紧跟在 FROM 之后EXPOSE声明容器监听端口是声明不自动映射CMD / ENTRYPOINT定义启动行为CMD 可被覆盖ENTRYPOINT 一般固定USER切换运行用户生产环境必须做HEALTHCHECK定义健康检查生产环境建议加选型逻辑里最容易被忽略的是基础镜像的取舍。以 Python 服务为例python:3.11-bookworm、python:3.11-slim和python:3.11-alpine体积差异巨大完整版可能 1 GB 以上slim 版本大概几百 MBalpine 更小。但体积小不等于零代价alpine 用的是 musl libc有些依赖编译期会出问题。我的建议是能用 slim 就用 slim需要极端压缩的才考虑 alpine但提前做好动态链接库缺失的心理准备。4.2 一个可落地的完整 Dockerfile 示例下面这个示例我特意把生产环境常见的要素都排进去了作用是一个基于 Python 的 Web API 服务。# 1. 构建阶段安装依赖并打包 FROM python:3.11-slim AS builder ENV PIP_DISABLE_PIP_VERSION_CHECK1 \ PIP_NO_CACHE_DIR1 \ PYTHONDONTWRITEBYTECODE1 \ PYTHONUNBUFFERED1 WORKDIR /app # 先拷贝依赖清单文件利用 Docker 层缓存 COPY requirements.txt . RUN pip install --prefix/install -r requirements.txt # 2. 运行时阶段只拷贝安装结果和业务代码 FROM python:3.11-slim AS runtime ENV PYTHONUNBUFFERED1 \ APP_HOME/app WORKDIR $APP_HOME # 从构建阶段拷贝已安装的依赖到同一个路径 COPY --frombuilder /install /usr/local # 创建非 root 用户并切换到该用户 RUN groupadd -r appuser useradd -r -g appuser -d $APP_HOME appuser \ chown -R appuser:appuser $APP_HOME USER appuser COPY --chownappuser:appuser app.py . EXPOSE 8000 CMD [python, app.py]关于这个文件三个核心设计我给你拆开讲。首先是多阶段构建builder 和 runtime 两个 FROM。构建阶段里 pip 会下载并编译依赖需要完整的编译工具链和网络环境运行时阶段只需要已安装好的依赖和代码不需要那些临时文件。如果用单阶段构建最终镜像会包含一堆构建缓存、多余系统库体积至少翻一倍。两阶段构建让最终镜像只保留运行所需的最小集合。其次是利用层缓存优化构建速度。我把COPY requirements.txt和RUN pip install放在代码拷贝之前因为 Docker 构建缓存是以“指令 上下文变更”为粒度判断的。只要 requirements.txt 没变每次改业务代码时 Docker 都会直接命中缓存跳过耗时的依赖安装。构建一次镜像后后续增量构建可能只用几秒钟这个收益在 CI/CD 里极其明显。最后是非 root 用户。容器内的 root 权限和主机 root 权限并没有完全隔离一旦应用被攻破攻击者拿到的是容器的 root 权限。切换到普通用户能显著降低风险面这也是生产环境的基本要求。4.3 构建命令与上下文目录为什么你的镜像里有多余文件构建命令本身很简单docker build -t myapp:v1.0 .但很多人对最后那个“.”的作用理解不够。它是构建上下文的路径Docker 会把整个上下文目录打包发送给守护进程Dockerfile 里的COPY只能引用这个上下文里的文件。所以如果你在上下文目录里放了大量无关文件比如日志、临时文件、.git 目录、node_modules每次构建都会把这些文件也打包过去直接拖慢构建速度甚至会不小心把敏感文件嵌进镜像。解决办法是在上下文目录下放一个.dockerignore文件语法类似.gitignore。.git __pycache__ *.pyc .env logs tmp我在实际项目里见过一个真实案例某项目的上下文目录里有 5 GB 的日志文件构建一次要七八分钟等排查完才发现 Docker 每次都在打包这些日志。加了.dockerignore之后构建时间降到 1 分钟以内。这件事值得刻在工位上。5. 镜像瘦身、缓存机制与安全加固生产环境不能含糊的三个课题5.1 镜像体积优化从 1.5 GB 到 300 MB 的常规路径先明确体积优化不是纯粹为了炫技它直接决定拉取时间、磁盘占用和启动速度。常规优化路径我按优先级排第一选择更小的基础镜像。把python:3.11-bookworm换成python:3.11-slim通常能立刻砍掉 60% 体积。第二多阶段构建把编译产物和最终运行环境分开。第三清理安装缓存。apt 安装后执行rm -rf /var/lib/apt/lists/*pip 安装时设置PIP_NO_CACHE_DIR1这些缓存文件在镜像里没有任何用处。第四合并 RUN 指令。每条 RUN 都会产生一个层如果指令之间存在文件的创建和删除合并成一条能在该层内部清理掉临时文件而不是让这些文件留在层历史里。我用一个 Node.js 应用举例未优化时镜像体积约 800 MB做完三件事之后稳定在 150 MB 左右基础镜像从完整版 node 镜像换成 node:20-slim先COPY package.json再RUN npm install然后COPY . .保证业务代码变化时依赖缓存不被破坏把npm cache clean --force写进同一个 RUN 指令尾部。最后再提一步某些场景可以用docker history 镜像名查看每一层的体积定位哪个指令制造了超大的层这是一个很好用的排查手段。5.2 构建缓存命中规则为什么改了 requirements 却还是用了旧依赖Docker 的层缓存判断机制说简单也简单执行某条指令前Docker 会对比当前指令和上一层的缓存是否匹配再对比该指令涉及的上下文文件是否有变化。但有几类“感知不到的变化”会导致缓存假命中指令没有变化但网络源里的软件包已经更新了。最典型的就是apt-get update这条指令永远没有“输入变化”缓存可能一直命中导致后续 install 的还是旧包。COPY 的文件内容相同但权限、属主变了。Docker 会检测到元数据变化但有时不触发缓存失效。ARG 和 ENV 的值已经改变但 Dockerfile 里该指令没有变化。两个避坑技巧更新依赖源时临时加--no-cache参数绕过缓存给关键 RUN 指令前加一个ARG CACHE_BUST20240101想强制失效时改这个 ARG 的值即可。5.3 镜像安全清单除了非 root 用户还有什么要注意镜像安全本质上包含两部分供应链安全和运行时安全。供应链安全方面优先级是官方镜像大于社区镜像固定 tag 而不是latest定期扫描镜像漏洞。主流的扫描工具可以集成到 CI 流程里在镜像构建完成后自动扫描高危漏洞直接阻断构建。仓库里过期的镜像层要定期清理避免“孤儿层”长期占用磁盘。运行时安全方面除了前面说的非 root 用户还要注意尽量挂载只读根文件系统容器内不落盘业务数据用docker run --read-only配合临时目录挂载即使应用有写文件的冲动也不会污染可写层为容器设置内存和 CPU 限额避免单容器异常消费整台机器资源HEALTHCHECK不是装饰它让编排系统能自动重启不健康容器。6. 常见问题与排查技巧实录镜像相关高频坑位速查6.1 镜像拉取慢或超时的完整处理思路镜像拉取慢第一步先确认是不是所有镜像都慢。如果都慢大概率是 Docker Hub 的网络链路问题按优先级尝试配置镜像加速器、切换更优网络环境、在内网部署镜像仓库中转。如果只有某个镜像慢查看具体是哪个层耗时高有可能是某个层组件体积异常大比如包含模型文件或大数据集。超时报错经常是“dial tcp ... i/o timeout”解决方案基本同上。一个有点反直觉的点是国内云厂商和国外服务器上加速器效果差异很大如果你常年在同一家云厂商建议直接用厂商提供的容器镜像服务地址而不是网上随便找的加速地址。6.2 构建时常见报错及对应解法“COPY failed: no source files specified”大概率是路径写错或构建上下文里根本没有这个文件。先检查当前目录和文件是否存在再检查.dockerignore是否误伤了目标文件。“failed to solve with frontend dockerfile.v0”通常是 Dockerfile 语法错误或某条指令不合法FROM拼写、指令大小写建议全大写、格式换行都是高发问题。“exec format error”镜像架构和宿主机架构不匹配。比如在 ARM 主机上运行了 amd64 架构的镜像。可以用docker inspect 镜像ID查看 Architecture 字段确认也可以直接用构建参数做交叉编译。“no space left on device”磁盘被镜像和容器占满了。用docker system df查看空间分布然后按需清理docker image prune删除悬空镜像docker container prune清理所有已停止容器极端情况下docker system prune -a会把未在运行的镜像全部清理但注意这条命令会连带删除所有没在用镜像执行前仔细想一想。6.3 容器运行后马上挂掉如何利用日志与调试镜像个定位docker ps -a看到容器 Exited先看日志docker logs 容器名或ID如果是“exec: python: executable file not found”大概率是基础镜像里没有 python 或路径不对。如果是“ModuleNotFoundError”大概率是依赖没装或没拷贝进运行时镜像。这些可以用docker run -it --entrypoint /bin/bash myapp:v1.0进入调试模式手工检查文件系统和依赖。调试完退出时记住调试过程产生的容器变更不会影响镜像本身。6.4 一个容易忽略的点构建缓存带来的“老版本”烦恼我在一个模拟项目里遇到过开发本地构建出了新版本镜像但线上 CD 用的还是旧缓存层导致某次修复根本没生效。因为 CD 过程构建时 Docker 认为所有层都未变化渲染了旧缓存。解决办法是构建命令加--no-cache强制重新构建同时确认构建日志里每一条指令是CACHED还是实际执行。CI 系统中最好固定镜像 digest 而不是 tag才能保证部署的就是你测试通过的镜像。7. 镜像的调试与导出深层排查思路和实用工具7.1 dive直观查看镜像分层体积的工具如果镜像体积始终压不下来推荐一个工具叫 dive。它能逐层展示镜像的体积变化并直接标注出“效率低”的层。安装后一条命令dive myapp:v1.0你会立刻看到哪个 RUN 指令带来了 200 MB 的临时文件哪个 COPY 引入了一堆该被忽略的目录。工具本身不能帮你自动优化但它能把“凭感觉猜层体积”变成“看一眼就知道改哪里”。7.2 从正在运行的容器反推镜像状态有时候需要从运行中的容器排查问题几个实用命令docker inspect 容器名 # 查看完整配置包括挂载、环境变量、网络 docker exec -it 容器名 /bin/sh # 进入运行中的容器 docker top 容器名 # 查看容器内进程 docker diff 容器名 # 查看容器相对于镜像更改了哪些文件docker diff在排查“容器内文件到底改了什么”时极其好用输出里A表示新增C表示变更D表示删除。某次容器假死我用docker diff发现应用日志把可写层写满了几 GB问题一目了然。7.3 镜像导出导入的进阶场景离线部署与CI流水线离线部署场景镜像导出后有几种分发方式直接拷贝 tar 包在一台中转机上 load 后重新 push 到内网仓库也可以用更现代的格式 OCI 规范导出。在 CI/CD 流水线里我建议镜像构建完成后立刻将镜像推送到私有仓库并记录 digest部署时根据 digest 拉取而不是靠 tag 名。这能规避 tag 被覆盖的问题也给回滚提供了一个明确的“当时那个版本”。8. 我的一点个人体会踩过无数镜像相关的坑之后最深的体会是镜像这个东西说到底是“只读模板 分层复用 可写层”这三个概念其余都是它们的推论。你理解了分层就知道为什么缓存能加速理解了只读就知道为什么容器删了修改就没了理解了可写层就知道持久化要靠数据卷而不是容器内部。很多 docker run 参数和 Dockerfile 指令本质上都是围绕这三件事在展开。最后再分享一个小经验如果你刚上手 Docker建议每天花十分钟用docker history随便查看一个镜像的分层历史连续看几天你对“一条 Dockerfile 指令等于一层镜像”的感觉就会非常扎实。毕竟镜像这关过了容器编排那关才真正走得动。
阅读完成 · 觉得有帮助？
