Docker 镜像体积优化实战：从 1GB 到 100MB 的瘦身之路

为什么镜像体积如此重要？

在容器化部署成为主流的今天，Docker 镜像的体积直接影响着 CI/CD 流水线的速度、镜像仓库的存储成本、以及生产环境的部署效率。一个 1GB 的镜像和一个 100MB 的镜像之间的差距，不仅仅是数字上的区别——它意味着更快的构建推送、更短的拉取等待、更少的网络带宽消耗，以及更小的攻击面。

本文将基于一个真实的 Node.js 后端服务，完整记录从 1.02GB 优化到 98MB 的实战过程，每一步都附带可复现的代码和原理分析。

起点：一个“能用”但臃肿的 Dockerfile

项目初始的 Dockerfile 非常朴素：

FROM node:18
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
EXPOSE 3000
CMD ["node", "dist/main.js"]

构建后镜像体积为 1.02GB。问题出在哪里？基础镜像 node:18 基于完整的 Debian 系统，本身就接近 900MB；COPY . . 把 node_modules、.git、测试文件全部塞了进去；npm install 安装了 devDependencies，而生产环境根本不需要它们。

第一步：换用 Alpine 基础镜像（1.02GB → 380MB）

Alpine Linux 是一个面向安全的轻量级发行版，基础镜像仅约 5MB。Node.js 官方提供了 Alpine 版本：

FROM node:18-alpine
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
EXPOSE 3000
CMD ["node", "dist/main.js"]

重新构建后，体积降至 380MB。这一步的收益巨大，但 Alpine 使用 musl libc 而非 glibc，某些依赖原生模块的包（如 sharp、bcrypt）可能需要额外处理。本例中项目依赖纯 JavaScript 包，因此没有遇到兼容性问题。

第二步：利用 .dockerignore 排除无关文件（380MB → 310MB）

COPY . . 是一个危险操作——它会把 .git、.env、日志文件、本地 node_modules 全部复制进镜像。创建一个 .dockerignore 文件：

node_modules
.git
.env
*.log
dist
coverage
.vscode

注意这里排除了 dist，因为构建会在镜像内完成。如果采用多阶段构建（后面会讲），构建产物会从构建阶段复制过来，本地 dist 不应进入上下文。

这一步将体积降至 310MB。

第三步：多阶段构建（310MB → 140MB）

这是最关键的一步。多阶段构建允许我们在一个阶段安装依赖并编译，在另一个阶段只复制运行所需的产物。

# ---- 构建阶段 ----
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# ---- 运行阶段 ----
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY --from=builder /app/dist ./dist
EXPOSE 3000
CMD ["node", "dist/main.js"]

构建阶段安装了全部依赖（包括 devDependencies）并执行编译，运行阶段只安装生产依赖并复制编译产物。最终镜像 140MB。

这里使用 npm ci 而非 npm install，前者严格依据 package-lock.json 安装，速度更快且结果可复现。

第四步：选择更精简的基础镜像（140MB → 110MB）

node:18-alpine 仍然包含 npm、yarn 等工具，而运行时只需要 Node.js 本身。可以使用 node:18-alpine 的变体，或者直接基于 Alpine 手动安装 Node：

FROM alpine:3.19
RUN apk add --no-cache nodejs
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/main.js"]

但手动安装 Node 可能版本不匹配，更稳妥的方式是使用 node:18-alpine 并清理缓存：

FROM node:18-alpine
RUN rm -rf /usr/local/lib/node_modules/npm /usr/local/bin/npm

移除 npm 后体积降至 110MB。

第五步：合并 RUN 指令与清理缓存（110MB → 98MB）

Docker 的每条 RUN 指令都会产生一个层，层中的临时文件即使被删除，仍会留在镜像历史中。因此需要将安装和清理合并到同一条 RUN 中：

FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci && npm cache clean --force
COPY . .
RUN npm run build

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production && npm cache clean --force && \
    rm -rf /usr/local/lib/node_modules/npm /usr/local/bin/npm
COPY --from=builder /app/dist ./dist
EXPOSE 3000
USER node
CMD ["node", "dist/main.js"]

最终镜像体积 98MB，相比最初的 1.02GB 减少了 90%。

优化效果对比

额外建议

使用 distroless 镜像：Google 的 distroless 镜像只包含应用和运行时依赖，没有 shell、包管理器，安全性极高，但调试困难，适合生产环境。

定期检查镜像层：使用 docker history <image> 查看每一层的大小，定位体积异常的层。也可以使用 dive 工具进行交互式分析。

固定基础镜像版本：使用 node:18.19.0-alpine3.19 而非 node:18-alpine，避免因基础镜像更新导致构建结果不可复现。

考虑使用 BuildKit：Docker BuildKit 支持并行构建、更好的缓存机制和 --mount=type=cache 缓存 npm 包，能显著加速构建过程。

总结

镜像体积优化是一个系统性工程，核心思路可以归纳为三点：选对基础镜像、只复制需要的东西、合并清理操作。从 1GB 到 100MB 的瘦身之路，每一步都有明确的技术手段和可量化的收益。在实际项目中，不必一次性追求极致，可以根据团队情况循序渐进地推进优化。

未经允许不得转载：任鹏个人博客 » Docker 镜像体积优化实战：从 1GB 到 100MB 的瘦身之路