精通 DevOps 工具与最佳实践 - DevOps 知识中心 精通 DevOps 工具与最佳实践 - DevOps 知识中心

使用多阶段构建优化Docker镜像：全面指南

掌握Docker多阶段构建，大幅缩小镜像体积、加速部署并增强安全性。本指南提供分步说明、Go和Node.js的实用示例以及关键最佳实践。学习如何通过分离构建依赖来优化Dockerfile，确保只有必要组件进入最终运行时镜像。对于任何希望构建高效安全容器化应用的人来说，这都是必读内容。

使用多阶段构建优化Docker镜像：全面指南

多阶段构建解决了一个非常常见的Docker问题：构建应用所需的工具通常不是运行应用所需的工具。

Go编译器、Node包缓存、Maven仓库、测试框架和构建头文件在镜像构建时很有用，但在运行时镜像中却是累赘。它们会拖慢拉取速度，增加需要修补的软件量，并使理解生产环境中实际运行的内容变得更加困难。

使用多阶段Dockerfile，您可以在一个阶段构建，然后仅将完成的工件复制到更小的运行时阶段。最终镜像不会继承构建阶段，除非您显式地从其中复制文件。

单阶段镜像的问题

考虑一个典型的Go应用。您需要Go工具链来编译它。一旦有了Linux二进制文件，编译器就不再需要了。单阶段镜像仍然会保留它：

FROM golang:1.21-alpine

WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -o myapp

EXPOSE 8080
CMD ["./myapp"]

这可以运行，但最终镜像仍然包含Go工具链和构建缓存。同样的模式也出现在Node、Java、Rust、带有原生扩展的Python包以及前端构建中。

代价是实际的：

  • 增加镜像大小：更多的层，更多的数据需要拉取和存储。
  • 延长部署时间：更大的镜像需要更长的传输时间。
  • 引入安全风险：不必要的软件增加了攻击面。
  • 模糊运行时环境：使得更难理解真正需要什么。

较小的镜像在运行时不会自动更快，但它们在CI、注册表和部署系统中移动得更快。它们也使安全审查不那么嘈杂。

多阶段构建的作用

每个FROM指令都会启动一个新阶段。您可以命名一个阶段，并在之后从中复制文件：

FROM golang:1.21-alpine AS builder
# 在此构建文件

FROM alpine:3.20
COPY --from=builder /app/myapp /app/myapp

第二阶段从头开始。它不包含/usr/local/go、源文件、包缓存或第一阶段中的构建工具，除非您复制它们。

一个简洁的Go示例

这是一个小型应用：

package main

import (
	"fmt"
	"log"
	"net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
	fmt.Fprintf(w, "Hello from optimized Docker image!")
}

func main() {
	http.HandleFunc("/", handler)
	log.Println("Server starting on :8080...")
	log.Fatal(http.ListenAndServe(":8080", nil))
}

多阶段Dockerfile：

FROM golang:1.21-alpine AS builder

WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download

COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags='-w -s' -o myapp

FROM alpine:3.20

WORKDIR /app
COPY --from=builder /app/myapp /app/myapp

EXPOSE 8080
CMD ["/app/myapp"]

go.mod和go.sum文件在完整源代码树之前被复制，这样当只有应用代码更改时，Docker可以重用依赖下载层。当您想要静态二进制文件时，CGO_ENABLED=0很有用。如果您的应用依赖于C库，您可能需要一个包含这些库的运行时镜像，而不是强制静态构建。

构建并比较：

docker build -t go-app:multi-stage .
docker images go-app:multi-stage
docker history go-app:multi-stage

不要依赖博客的示例大小。检查您自己的镜像。依赖选择、基础镜像版本、调试符号、证书、时区数据和原生库都会影响结果。

运行时基础镜像选择

alpine很流行，因为它很小，但小并不总是等同于兼容。Alpine使用musl libc，而许多常见的Linux发行版使用glibc。大多数Go静态二进制文件运行良好。一些Python、Node、Java或原生包的行为会有所不同。

常见的运行时选项：

运行时基础 适用场景 权衡
alpine 小镜像，简单二进制文件 musl兼容性差异
debian:bookworm-slim 广泛的Linux兼容性 比Alpine大
Distroless镜像 工具较少的运行时环境 在容器内调试更困难
scratch 仅静态二进制文件 无shell、CA证书或包管理器，除非复制

如果应用调用HTTPS端点，请确保最终镜像包含CA证书。没有证书的scratch镜像可能会以看起来像网络问题的方式失败。

FROM alpine:3.20 AS certs
RUN apk add --no-cache ca-certificates

FROM scratch
COPY --from=builder /app/myapp /myapp
COPY --from=certs /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
CMD ["/myapp"]

其他语言/框架的多阶段构建

同样的思路适用于任何有构建步骤的地方。

对于Node前端：

FROM node:20-alpine AS builder

WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:1.27-alpine
COPY --from=builder /app/dist /usr/share/nginx/html

对于Node API，如果开发安装包含开发依赖，不要复制node_modules：

FROM node:20-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev

FROM node:20-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=deps /app/node_modules ./node_modules
COPY . .
CMD ["node", "server.js"]

对于Java：

FROM maven:3.9-eclipse-temurin-21 AS builder
WORKDIR /src
COPY pom.xml .
RUN mvn -q -DskipTests dependency:go-offline
COPY src ./src
RUN mvn -q -DskipTests package

FROM eclipse-temurin:21-jre
WORKDIR /app
COPY --from=builder /src/target/app.jar /app/app.jar
CMD ["java", "-jar", "/app/app.jar"]

构建缓存也很重要

多阶段构建减少了最终镜像大小，但Dockerfile的顺序仍然控制着缓存行为。将稳定的依赖文件放在易变的源文件之前。在可重现的构建中使用npm ci而不是npm install。在生产环境中固定基础镜像版本，而不是依赖latest。

使用BuildKit，缓存挂载可以加速包下载，而无需将缓存烘焙到最终镜像中：

# syntax=docker/dockerfile:1.7
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN --mount=type=cache,target=/go/pkg/mod go mod download
COPY . .
RUN --mount=type=cache,target=/root/.cache/go-build \
    CGO_ENABLED=0 GOOS=linux go build -o myapp

该缓存用于构建机器，而不是运行时镜像。

复制什么，不复制什么

复制最小的完整运行时集。对于编译的服务，这可能是一个二进制文件加上配置模板和CA证书。对于前端，可能是一个dist目录。对于Java，可能是一个jar加上JRE。

不要复制源代码、包管理器缓存、测试夹具、本地.env文件、SSH密钥或您不运行的构建输出。使用.dockerignore文件，这样这些文件一开始就不会进入构建上下文：

.git
node_modules
coverage
dist
*.log
.env

.dockerignore文件不能替代仔细的COPY指令，但它可以防止意外的上下文膨胀和秘密泄露。

调试多阶段构建

命名您的阶段。命名的阶段更容易定位：

docker build --target builder -t app-builder .
docker run --rm -it app-builder sh

当构建成功但最终镜像因文件复制到错误路径或缺少运行时库而失败时，这很有用。

您还可以检查复制到最终镜像中的文件：

docker run --rm -it --entrypoint sh my-image

如果镜像没有shell，在诊断时临时将最终阶段切换到对调试友好的基础镜像，然后再放回生产基础镜像。

实用规则

为每个不同的任务使用一个阶段：依赖、构建、测试、运行时。保持运行时阶段简单。如果有人打开最终的Dockerfile阶段，他们应该能够快速回答一个问题：这个容器实际需要哪些文件才能运行？

这就是多阶段构建的真正价值。较小的镜像很好。清晰的运行时边界更好。