123xiao | 无名键客
返回

《Docker 多阶段构建与镜像瘦身实战：从构建提速到安全加固的中级优化指南》

字数: 0 阅读时长: 1 分钟

Docker 多阶段构建与镜像瘦身实战：从构建提速到安全加固的中级优化指南

很多团队第一次把应用容器化时，Dockerfile 往往是“能跑就行”的风格：

  • 基础镜像直接上 ubuntu 或 node:latest
  • 构建工具、调试工具、源码、缓存全塞进最终镜像
  • COPY . . 一把梭
  • root 用户直接跑服务
  • 构建慢、镜像大、漏洞多，还不容易排查

我自己早期也这么干过。最典型的结果是：一个本来几十 MB 就能解决的服务，最后打成了几百 MB；CI 一构建就慢；安全扫描一片红；上线后还发现镜像里带着根本用不到的编译器和包管理器。

这篇文章不讲太“概念化”的东西，而是从实际可落地的优化路径出发，带你把 Docker 镜像从“能用”提升到“更快、更小、更安全”。

背景与问题

先看几个常见症状：

  1. 构建时间越来越长
    代码一改，依赖全量重装，CI/CD 每次都像冷启动。

  2. 镜像体积过大
    发布、拉取、启动都变慢，尤其在边缘节点或跨地域部署时很明显。

  3. 安全基线不过关
    镜像中包含 shell、编译器、调试工具、root 权限，攻击面不必要地扩大。

  4. 构建和运行环境耦合
    运行时根本不需要 GCC、Maven、npm cache，但它们却被打进了线上镜像。

  5. 排查问题成本高
    Dockerfile 层级混乱，缓存失效原因不清楚，镜像构建行为不可预测。

这些问题，很多都能通过多阶段构建 + 分层优化 + 安全加固一起解决。

前置知识与环境准备

建议你已经具备这些基础：

  • 知道 Dockerfile 常见指令：FROM、COPY、RUN、CMD
  • 会执行基本命令：docker build、docker run、docker images
  • 了解应用构建与运行的区别，比如：
    • Java：编译期需要 Maven/Gradle，运行期只要 JRE/JAR
    • Go：构建期需要 Go toolchain，运行期只需要二进制
    • Node.js：构建前端需要 npm/pnpm，运行时可能只需静态文件或最小 Node 环境

本文示例以 Node.js Web 应用 为主，同时穿插 Go 的思路，便于你举一反三。

核心原理

1. 什么是多阶段构建

多阶段构建的核心思想很简单：

把“构建应用”和“运行应用”拆成多个阶段，只把最终运行真正需要的产物复制到最后一个镜像里。

比如：

  • 第一阶段：安装依赖、编译代码
  • 第二阶段：只保留构建产物和最小运行时

这样做的直接收益：

  • 最终镜像更小
  • 运行环境更干净
  • 漏洞面更少
  • 构建逻辑更清晰

2. 为什么它能瘦身

因为 Docker 镜像是按层叠加的。你在某一层安装了很多工具，即便后面删掉，历史层仍然可能保留痕迹。
而多阶段构建通过“只复制结果”，绕开了这个问题。

3. 为什么它能提速

提速主要来自两个点：

  • 更合理的层缓存设计
    • 先复制依赖清单，再安装依赖
    • 代码变动时，只重建后续层
  • 缩小构建上下文
    • 用 .dockerignore 排除无关文件，减少传输和哈希计算

4. 为什么它更安全

因为最终镜像里通常可以不包含：

  • 包管理器
  • 编译器
  • shell 工具
  • 测试文件
  • 源代码
  • root 权限运行环境
flowchart TD
    A[源码目录] --> B[构建阶段 Builder]
    B --> C[安装依赖]
    C --> D[编译/打包]
    D --> E[生成运行产物]
    E --> F[运行阶段 Runtime]
    F --> G[仅复制必要文件]
    G --> H[最小镜像启动应用]

一张图看懂：普通构建 vs 多阶段构建

flowchart LR
    subgraph Traditional[单阶段构建]
      T1[基础镜像]
      T2[安装构建工具]
      T3[复制源码]
      T4[安装依赖]
      T5[编译]
      T6[运行应用]
      T1 --> T2 --> T3 --> T4 --> T5 --> T6
    end

    subgraph MultiStage[多阶段构建]
      M1[builder 镜像]
      M2[安装工具与依赖]
      M3[编译产物]
      M4[runtime 镜像]
      M5[仅复制 dist/node_modules生产依赖]
      M6[运行应用]
      M1 --> M2 --> M3
      M3 --> M4 --> M5 --> M6
    end

实战代码（可运行）

下面我们用一个 Node.js 示例，逐步从“普通写法”优化到“多阶段 + 瘦身 + 安全加固”。

示例项目结构

demo-node-app/
├─ package.json
├─ package-lock.json
├─ server.js
├─ .dockerignore
└─ Dockerfile

示例应用代码

package.json

{
  "name": "demo-node-app",
  "version": "1.0.0",
  "description": "Docker multi-stage demo",
  "main": "server.js",
  "scripts": {
    "start": "node server.js"
  },
  "dependencies": {
    "express": "^4.18.2"
  }
}

server.js

const express = require("express");
const app = express();

const PORT = process.env.PORT || 3000;

app.get("/", (req, res) => {
  res.json({
    message: "hello docker multi-stage",
    hostname: process.env.HOSTNAME || "unknown"
  });
});

app.listen(PORT, () => {
  console.log(`server running on port ${PORT}`);
});

先看一个不推荐但常见的 Dockerfile

FROM node:18

WORKDIR /app

COPY . .

RUN npm install

EXPOSE 3000

CMD ["npm", "start"]

这个写法能跑，但问题不少：

  • COPY . . 太早，源码一变依赖层缓存就废了
  • npm install 会把开发依赖也装进去
  • 使用完整基础镜像，体积偏大
  • root 用户运行
  • 没有做最小化处理

第一步：优化缓存顺序

先别急着上多阶段，先把层缓存设计做对。

FROM node:18-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci --omit=dev

COPY . .

EXPOSE 3000

CMD ["node", "server.js"]

为什么更好

  • 先复制 package.json / package-lock.json
  • 依赖安装单独成层
  • 应用代码改动时，只重新执行 COPY . . 之后的步骤
  • npm ci 比 npm install 更适合 CI 和可重复构建
  • --omit=dev 避免安装开发依赖

不过，这仍然是单阶段构建。如果构建阶段需要 TypeScript、Webpack、Vite 或原生编译工具，最终镜像仍可能偏大。

第二步：多阶段构建正式上场

假设我们的项目有构建过程，比如前端或 TypeScript 应用，需要先 npm run build。下面给出一个通用多阶段示例。

多阶段 Dockerfile

FROM node:18-alpine AS builder

WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .
RUN npm run build || echo "skip build step"

FROM node:18-alpine AS runtime

WORKDIR /app

ENV NODE_ENV=production

COPY package*.json ./
RUN npm ci --omit=dev && npm cache clean --force

COPY --from=builder /app/dist ./dist
COPY --from=builder /app/server.js ./server.js

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

EXPOSE 3000

CMD ["node", "server.js"]

这个版本的思路是：

  • builder 阶段负责装全量依赖、执行构建
  • runtime 阶段只保留生产依赖与运行所需文件
  • 使用非 root 用户启动服务

如果你的项目是纯后端 Node 服务，没有 dist，可以不复制 dist，只复制必要源码文件。

第三步：更适合当前示例的可运行版本

因为上面的 demo-node-app 没有 npm run build，我们给出一个真正开箱即跑的版本。

Dockerfile

FROM node:18-alpine AS deps

WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev

FROM node:18-alpine AS runtime

WORKDIR /app
ENV NODE_ENV=production

COPY --from=deps /app/node_modules ./node_modules
COPY server.js ./
COPY package.json ./

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

EXPOSE 3000
CMD ["node", "server.js"]

.dockerignore

这个文件非常关键，很多人忽略了，结果构建上下文又大又乱。

node_modules
npm-debug.log
Dockerfile
.dockerignore
.git
.gitignore
README.md
coverage
dist
.env
*.local

构建与运行

构建镜像

docker build -t demo-node-app:ms .

启动容器

docker run --rm -p 3000:3000 demo-node-app:ms

验证服务

curl http://localhost:3000

你应该能看到类似输出：

{"message":"hello docker multi-stage","hostname":"..."}

逐步验证清单

做完优化后，我建议不要只看“能不能跑”，最好按下面清单检查：

1. 镜像体积是否下降

docker images | grep demo-node-app

2. 镜像层是否更清晰

docker history demo-node-app:ms

3. 是否仍然以 root 运行

docker run --rm demo-node-app:ms id

4. 是否只包含生产依赖

docker run --rm demo-node-app:ms ls /app/node_modules

5. 构建缓存是否生效

先构建一次，再只修改 server.js 重新构建，观察依赖安装层是否复用。

BuildKit：让构建再快一点

如果你已经在做中级优化，那 BuildKit 很值得启用。它能提供更好的缓存机制和更现代的构建能力。

启用方式

DOCKER_BUILDKIT=1 docker build -t demo-node-app:ms .

使用缓存挂载优化 npm 下载

# syntax=docker/dockerfile:1.4

FROM node:18-alpine AS deps

WORKDIR /app
COPY package*.json ./
RUN --mount=type=cache,target=/root/.npm npm ci --omit=dev

FROM node:18-alpine AS runtime

WORKDIR /app
ENV NODE_ENV=production

COPY --from=deps /app/node_modules ./node_modules
COPY server.js ./
COPY package.json ./

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

EXPOSE 3000
CMD ["node", "server.js"]

这里的关键点是：

  • 第一次构建会下载依赖
  • 后续构建会复用 npm 缓存
  • 对 CI/CD 构建速度提升比较明显
sequenceDiagram
    participant Dev as 开发者
    participant Docker as Docker Build
    participant Cache as 构建缓存
    participant Registry as 镜像仓库

    Dev->>Docker: 提交 Docker build
    Docker->>Cache: 检查 package-lock 与层缓存
    alt 依赖未变化
        Cache-->>Docker: 复用依赖层
    else 依赖变化
        Docker->>Cache: 重新安装并写入缓存
    end
    Docker->>Docker: 复制业务代码
    Docker->>Docker: 生成 runtime 镜像
    Docker->>Registry: 推送更小的最终镜像

常见坑与排查

下面这些坑，我基本都踩过，尤其是在 CI 环境里更容易暴露。

坑 1：COPY . . 导致缓存频繁失效

现象

明明只改了一行业务代码，结果依赖重新安装，构建时间暴涨。

原因

你在安装依赖之前就把整个目录复制进去了，任何文件变化都会让该层缓存失效。

正确方式

COPY package*.json ./
RUN npm ci --omit=dev
COPY . .

坑 2：.dockerignore 没写，构建上下文巨大

现象

构建输出里 Sending build context to Docker daemon 非常大，甚至几百 MB。

排查

看看本地有没有这些东西被传进构建上下文：

  • node_modules
  • .git
  • dist
  • 测试报告
  • 日志文件
  • 本地环境变量文件

解决

补上 .dockerignore，这是性价比极高的优化。

坑 3：删文件不等于瘦身成功

现象

Dockerfile 里明明执行了 rm -rf，但镜像还是很大。

原因

Docker 镜像是分层的，你删除的是后续层的内容，前面层已经记录过这些文件。

解决

  • 尽量在同一层安装和清理
  • 更推荐用多阶段构建，只复制最终产物

坑 4：Alpine 不是银弹

现象

换成 alpine 后镜像变小了，但运行报错，尤其是某些原生依赖模块。

原因

Alpine 基于 musl libc，而不是 glibc。某些二进制依赖或原生模块兼容性不好。

解决建议

根据场景选基础镜像：

  • 追求极致小：alpine
  • 兼容性优先：debian-slim / 官方 slim 镜像
  • 极简运行时：distroless

不要为了小几 MB，换来半天排障。

坑 5：多阶段复制漏文件

现象

构建成功，运行时报找不到配置文件、静态资源或入口文件。

原因

runtime 阶段只复制了部分产物，漏掉了：

  • 配置文件
  • 模板文件
  • 静态资源
  • 生产依赖

排查命令

docker run --rm -it demo-node-app:ms sh

如果镜像没有 shell，可以临时用 builder 阶段或 debug 镜像排查。

坑 6：非 root 用户后权限异常

现象

切换 USER appuser 后，应用写日志、创建缓存目录失败。

原因

复制进去的目录属主仍是 root，非 root 用户没有写权限。

解决方式

COPY --chown=appuser:appgroup server.js ./

或者在创建目录后显式授权：

RUN mkdir -p /app/logs && chown -R appuser:appgroup /app

安全/性能最佳实践

这一部分很重要。很多文章只讲“怎么变小”，但在生产里，小只是结果，稳定、安全、可维护才是目标。

1. 固定基础镜像版本，不要直接用 latest

不推荐：

FROM node:latest

推荐：

FROM node:18.18-alpine

更进一步，你可以固定到 digest，避免基础镜像漂移：

FROM node:18.18-alpine@sha256:xxxxxxxxxxxxxxxx

适用边界：

  • 生产环境建议固定版本
  • 如果是开发实验环境，可适当放宽

2. 使用最小化运行时镜像

常见选择：

  • alpine：小，但有兼容性边界
  • slim：比完整版小，兼容性较好
  • distroless：极简且安全，适合成熟生产环境

如果你已经比较熟悉容器运维，distroless 很值得尝试，因为它几乎不带 shell 和包管理器，攻击面更小。

例如 Go 程序特别适合：

FROM golang:1.21 AS builder

WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app main.go

FROM gcr.io/distroless/static-debian12
COPY --from=builder /src/app /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]

3. 以非 root 用户运行

这是非常基础但经常被忽略的安全基线。

RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

好处：

  • 容器逃逸后的危害面更小
  • 更容易通过安全审计
  • 避免误操作写系统目录

4. 减少镜像中的敏感信息

不要把这些内容直接打进镜像：

  • .env
  • 私钥、证书
  • npm token
  • 云平台 Access Key
  • 调试配置

正确做法：

  • 构建时使用安全 secret 注入机制
  • 运行时通过环境变量、Kubernetes Secret、外部配置中心注入

5. 做漏洞扫描，但不要只看数量

常见工具有：

  • Docker Scout
  • Trivy
  • Grype
  • Snyk

你要关注的不只是“高危有几个”，还要看：

  • 是否存在可利用路径
  • 是否在最终 runtime 镜像中
  • 是否能通过升级基础镜像解决
  • 是否只是 builder 阶段依赖

很多扫描误报来自构建阶段。如果你把 builder 工具链隔离掉，最终风险暴露会少很多。

6. 合理利用缓存，但别把缓存当产物

缓存用于加速构建，不应该进入最终镜像。

比如 npm：

RUN --mount=type=cache,target=/root/.npm npm ci --omit=dev

而不是把下载缓存长期留在 runtime 镜像里。

7. 一层做一件有意义的事

不是说层越少越好，而是层次要可读、可缓存、可维护。

推荐思路：

  • 依赖安装单独成层
  • 构建单独成层
  • 运行镜像尽可能纯净

这样团队协作时，别人接手你的 Dockerfile，不会像在考古。

8. 定期重建镜像

就算业务代码不变，基础镜像里的系统包也可能有安全更新。
所以建议：

  • 定时重建基础服务镜像
  • 配合漏洞扫描与版本审计
  • 不要让旧镜像“永久在线”

一个更完整的生产化 Node Dockerfile 参考

下面给一个更偏生产实践的版本，包含缓存、非 root、最小运行时思路。

# syntax=docker/dockerfile:1.4

FROM node:18-alpine AS deps
WORKDIR /app

COPY package*.json ./
RUN --mount=type=cache,target=/root/.npm npm ci --omit=dev

FROM node:18-alpine AS runtime
WORKDIR /app

ENV NODE_ENV=production
ENV PORT=3000

COPY --from=deps /app/node_modules ./node_modules
COPY package.json ./
COPY --chown=node:node server.js ./

USER node

EXPOSE 3000

CMD ["node", "server.js"]

这个版本适合什么场景

适合：

  • 中小型 Node API 服务
  • 没有复杂原生依赖的应用
  • 追求简单、稳定、比默认写法更干净的团队

不一定适合：

  • 依赖大量原生编译模块
  • 需要 shell 调试的临时排障镜像
  • 对 glibc 兼容性有明确要求的应用

方案取舍：不要为了“最小”牺牲可运维性

这是中级优化里很关键的一点。

很多人学完镜像瘦身后，会有一种冲动：
“我要把镜像做到最小。”

但生产里更合理的目标通常是：

  • 足够小
  • 构建足够快
  • 风险足够低
  • 排障成本可接受

比如：

方案体积兼容性安全性排障便利性
完整基础镜像大高一般高
slim中较高较好较好
alpine小中较好中
distroless很小中高高低

我的经验是：

  • 开发/测试环境：可以保留一定调试能力
  • 生产环境：优先最小运行时与非 root
  • 强排障诉求场景：可保留 debug 变体镜像，而不是所有环境都用超极简镜像

总结

如果你想把 Dockerfile 从“能跑”升级到“适合长期维护”，可以按这条路径推进：

  1. 先优化层缓存顺序

    • 先复制依赖清单，再安装依赖，再复制源码

  2. 补齐 .dockerignore

    • 立刻减少构建上下文和无效文件进入镜像

  3. 引入多阶段构建

    • 构建环境和运行环境分离，只复制最终需要的产物

  4. 使用更合适的基础镜像

    • slim、alpine、distroless 按兼容性需求选择

  5. 默认非 root 运行

    • 这是低成本高收益的安全加固项

  6. 启用 BuildKit 和缓存挂载

    • 持续优化 CI 构建速度

  7. 用扫描工具验证，而不是凭感觉

    • 看最终 runtime 镜像的真实风险暴露

最后给一个很实用的判断标准：

一个好的生产镜像，不是“最炫技”的镜像，而是团队能稳定构建、快速发布、低风险运行、出问题也能定位的镜像。

如果你现在的 Dockerfile 还停留在 COPY . . && npm install 这个阶段，那么只要把文中的步骤做完一遍，通常就能看到很明显的收益：构建更快、镜像更小、上线更稳、安全更好过审。

分享到：
Share this post via WhatsApp Share this post on Facebook Share this post on X Share this post via Telegram Share this post on Pinterest Share this post via email
上一篇
《Web3 中间件实战：用 The Graph + Ethers.js 构建可扩展的链上数据查询与事件监听服务》
下一篇
《中级开发者如何用 RAG 构建企业级 AI 知识库问答系统：从向量检索到效果评测》