技术精进

从1.2GB到80MB：我重写Dockerfile的“瘦身”实录

大概在三年前的一个周五下午，我正准备结束一周的工作，监控群里突然弹出了磁盘告警。排查后发现，CI/CD 流水线所在的构建服务器磁盘爆满，而罪魁祸首竟然是一个刚刚构建的 Node.js 前端应用镜像——体积高达 1.2GB。

当时我就在想：一个只是用来托管静态文件的 Nginx 容器，凭什么比我电脑上的操作系统安装包还大？

这并不是个例。在很多中小团队中，大家往往把 Dockerfile 当作 Shell 脚本来写，认为只要 docker run 能跑起来就算成功。但实际上，镜像体积不仅关乎存储成本，更直接影响分发速度、启动时间以及生产环境的安全性。

配图

今天，我想结合那次具体的优化经历，复盘一下如何通过三个核心策略，将一个臃肿的“巨无霸”镜像优化到 80MB，并总结出一套可复用的 Dockerfile 编写心法。

一、 警惕“层”的陷阱：少即是多

刚开始接触 Docker 时，我们很容易陷入一种线性思维：把安装软件的步骤一行行写下来。

当时我的同事小张写的 Dockerfile 大概长这样：

# 错误示范
FROM ubuntu:20.04
RUN apt-get update
RUN apt-get install -y nodejs
RUN apt-get install -y npm
RUN npm install -g yarn
COPY . /app
RUN rm -rf /var/lib/apt/lists/*

这看起来逻辑很通顺，但在 Docker 的世界里，这是大忌。

因为 Docker 的每一条指令（特别是 RUN、COPY、ADD）都会构建一个新的镜像层（Layer）。 这种分层机制类似于洋葱，你在上一层创建了文件，在下一层执行删除，实际上文件并没有从磁盘物理消失，只是被“标记”为不可见。

在这个案例中，apt-get update 下载的缓存文件在第一层被写入，虽然最后一行执行了 rm，但那是在新的层里操作的。结果就是：缓存文件依然占据着镜像体积。

优化策略：链式指令与清理合并

我当时做的第一件事，就是把这些相关的操作合并成一条指令，并在同一层内完成“下载-安装-清理”的闭环。

# 优化后
FROM ubuntu:20.04
RUN apt-get update && \
    apt-get install -y nodejs npm && \
    npm install -g yarn && \
    rm -rf /var/lib/apt/lists/*

思考一下： 你的 Dockerfile 里是否有连续的 RUN 指令？哪怕只是简单的合并，通常也能减少 10%-30% 的体积。

通过这一步简单的合并，我把那个镜像减少了近 200MB。但对于 1.2GB 的总大小来说，这还只是热身。

二、 只要结果，不要过程：多阶段构建的魔法

分析那个 1.2GB 的镜像层级时，我发现了真正的庞然大物：node_modules 和各类编译工具（gcc, make, python等）。

这是一个典型的开发误区：把“构建环境”带入了“生产环境”。

应用运行时只需要编译后的静态文件（HTML/CSS/JS）和 Nginx 服务器，根本不需要 Node.js 环境，更不需要那几百兆的源码依赖。然而，为了执行 npm run build，我们被迫安装了这一整套工具链。

配图

在 Docker 17.05 之前，我们需要维护两个 Dockerfile（一个用于构建，一个用于运行），非常麻烦。但现在，我们可以使用多阶段构建（Multi-stage Builds）。

优化策略：掐头去尾，只留精华

我将 Dockerfile 重构为两个阶段：

  1. 构建阶段：基于 Node 镜像，安装依赖，编译代码。
  2. 运行阶段：基于纯净的 Nginx 镜像，只从上一阶段拷贝编译好的 /dist 目录。
# 第一阶段：构建 (起个别名 builder)
FROM node:16 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# 第二阶段：运行
FROM nginx:alpine
# 关键：只拷贝构建产物，抛弃源代码和 node_modules
COPY --from=builder /app/dist /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

这一招效果立竿见影。原本包含 Node 环境、源码、依赖包的 1.2GB 镜像，瞬间变成了只包含 Nginx 和静态文件的 80MB 镜像。

这次优化带来的连锁反应是惊人的： 部署时间从 5 分钟缩短到了 30 秒，因为网络传输的数据量减少了 90% 以上。

三、 选对基座：Alpine 还是 Distroless？

做完多阶段构建后，我已经很有成就感了。但我习惯再多问自己一句：还能再小一点吗？

我们之前的运行阶段使用的是 nginx:latest，它默认基于 Debian 系统。这意味着我的镜像里包含了一整套 Debian 的基础工具（bash, ls, grep 等）。

但在这个场景下，我真的需要这些工具吗？应用只是一个 Web Server 及其配置文件。

优化策略：使用精简版基础镜像

业界目前主要有两个精简流派：

  1. Alpine Linux：体积极小（约 5MB），基于 musl libc。
  2. Distroless：Google 推出的镜像，甚至连 Shell 都没有，只包含应用运行的最小依赖。

考虑到后期排查问题可能还需要进入容器看一眼，我选择了兼容性较好的 nginx:alpine。

# 这是一个巨大的差异
# FROM ubuntu:20.04  -> 基础镜像约 70MB
# FROM alpine:3.14   -> 基础镜像约 5MB

不过这里要提一个我踩过的坑。有一次我们在 Python 项目中盲目切换到 Alpine，结果因为 glibc 和 musl 的兼容性问题，导致很多 C 语言编写的依赖库（如 numpy）无法运行，编译时间反而激增。

避坑指南： 对于 Node.js、Go、Rust 这类静态编译或自带运行时的语言，Alpine 是绝佳选择；但对于 Python、Java 等强依赖系统动态库的语言，使用 slim 版本（如 python:3.9-slim）通常是兼容性和体积的最佳平衡点。

结尾：不仅仅是省空间

经过这三板斧的优化（合并指令、多阶段构建、精简基座），那个 1.2GB 的怪兽镜像最终稳定在了 20MB 左右（Nginx 基础 + 代码）。

回过头来看，优化 Dockerfile 的本质，其实是工程思维的体现。 我们在追求“能跑就行”的同时，是否忽略了资源效率和安全性？（注：越小的镜像，攻击面越小，包含的 CVE 漏洞通常也越少）。

你现在的项目中，是否也有那种几百兆甚至上 G 的“黑盒”镜像？

给你的 3 个落地行动建议：

  1. 立刻检查： 使用命令 docker history <你的镜像ID>，查看是哪一层占用了最大空间。
  2. 上手工具： 尝试使用 docker-slim 或者 VS Code 的 Docker 插件，它们能自动给出优化建议。
  3. 配置忽略： 检查你的项目根目录有没有 .dockerignore 文件。如果没有，请立刻创建一个，并把 .git、node_modules、tmp 等无关文件加进去，这往往是新手最容易忽略的“体积杀手”。

好的 Dockerfile 应该像一段优秀的代码：简洁、清晰、没有一句废话。希望这篇实录能帮你迈出优化的第一步。

© 2026 SelfTechHub