Docker多阶段构建实战：Go/Java/Rust镜像从GB到MB的极致瘦身

一个650MB镜像引发的思考

上周五下午,我盯着K8s dashboard上那个转了五分钟还在拉取镜像的Pod,心里一阵烦躁。一个简单的Spring Boot应用,打包成Docker镜像后650MB。团队里新来的实习生问我:“这镜像怎么这么大?”我愣了一下,突然意识到自己也从没认真想过这个问题。

那天晚上我回去研究了一晚上。第二天早上,同一个应用,镜像只有89MB。部署时间从5分钟缩短到不到1分钟。实习生看我的眼神都变了。

其实就是改了Dockerfile里几行代码。这个技巧叫”多阶段构建”。

说实话,刚开始我也觉得这玩意儿没啥用。我们团队的Go项目镜像295MB,Java项目动不动就上500MB,习惯了就觉得Docker镜像就该这么大。直到那天我看到有人把Rust镜像从2GB压到了11MB——没错,是GB到MB——我才意识到自己可能一直在用错误的方式打包镜像。

问题的核心在于:编译型语言需要编译器和构建工具把源代码编译成可执行文件,但运行时根本不需要这些东西。传统的Dockerfile把Maven、Gradle、Go编译器全打包进去了,就像你搬家时把装修用的电钻水泥也搬到新家一样——完全没必要。

今天我会用Go、Java、Rust三个真实案例告诉你怎么用多阶段构建给镜像瘦身。你会看到:

• Go应用从295MB降到6.47MB(减少98%)
• Java Spring Boot从650MB降到89MB(减少86%)
• Rust应用从2GB降到11.2MB(减少99.4%)

如果你只关心某一种语言,可以直接跳到对应章节。每个案例都是完整的,可以直接复制代码运行。

你的镜像为什么这么臃肿?

我先给你看个对比表格,这是我之前测试的真实数据:

第一次看到这个表时我整个人都懵了。特别是那个Rust的数据,2GB到11MB,这不是优化,这是魔法啊。

后来我仔细分析了镜像的组成,才明白问题出在哪。编译型语言有个特点:需要编译器把源代码编译成二进制可执行文件。你写Go要用golang编译器,写Java要用Maven或Gradle,写Rust要用Cargo。这些工具体积都不小:

• Go编译器:约300MB
• Maven + OpenJDK:约500MB
• Rust工具链:约1.5GB

传统的Dockerfile长这样:

FROM golang:1.21
WORKDIR /app
COPY . .
RUN go build -o myapp
CMD ["./myapp"]

看起来没问题对吧?实际上大有问题。这个Dockerfile把整个golang:1.21镜像(295MB)作为基础镜像,里面包含了Go编译器、各种构建工具、调试工具。你的应用编译完成后,这些东西一个都没删掉,全打包进最终镜像了。

就像你买了个毛坯房,请了装修队来装修。装修完成后,你把水泥、电钻、切割机、工人的工具箱全锁在房间里,然后搬进去住。听起来很荒谬,但很多人的Dockerfile就是这么干的。

运行时真正需要的,其实只有那个编译好的二进制文件。Go编译出来的二进制文件通常只有几MB到几十MB。Java的jar包可能稍大一些,但也就几十MB。Rust编译的二进制文件也很小。剩下的几百MB都是编译工具和基础镜像的开销。

这种臃肿不只是浪费存储空间。真正的痛点在于:

1. 拉取镜像慢:CI/CD流水线里,每次部署都要拉取镜像。650MB的镜像在网络不好时能等到你怀疑人生
2. 安全风险:生产镜像里包含编译器、源代码、构建工具,等于给攻击者留了一堆工具
3. 构建缓存浪费:修改一行代码,整个镜像都要重新构建,因为编译器和代码耦合在一起了

我记得有次在阿里云上部署,团队五个人同时部署新版本,每个人的镜像都是500MB+,直接把内网带宽跑满了。那次之后我下决心研究镜像优化。

多阶段构建:一个Dockerfile解决两个环境

多阶段构建是Docker 17.05引入的特性。核心思想特别简单:在一个Dockerfile里定义多个阶段,前面的阶段负责编译,后面的阶段负责运行,中间只传递必要的产物。

用人话讲:装修队在第一阶段装修房子,装修完后,你只把装修好的房子搬到第二阶段,水泥电钻全留在第一阶段不要了。

来看个最简单的例子:

# 第一阶段:构建阶段
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# 第二阶段:运行阶段
FROM alpine:3.18
WORKDIR /app
COPY --from=builder /app/myapp .
CMD ["./myapp"]

看到关键点了吗?

1. 第一个FROM后面加了AS builder,给这个阶段起名叫builder
2. 第二个FROM开始了新阶段,用的是轻量级的alpine镜像
3. COPY —from=builder从builder阶段复制编译好的二进制文件,其他东西全丢了

第一阶段的golang:1.21镜像有295MB,但最终镜像只有alpine的体积(5MB)加上你的二进制文件(可能几MB),总共也就十几MB。

我第一次看懂这个原理时,脑子里突然灵光一闪——这不就是”只要结果,不要过程”吗?编译器、源代码、中间文件全是过程,最终的二进制文件才是结果。Docker会自动把第一阶段的镜像扔掉,只保留第二阶段的。

你可能会问:如果我要调试第一阶段怎么办?Docker提供了一个超实用的命令:

docker build --target builder -t myapp:debug .

--target builder告诉Docker只构建到builder阶段,不执行第二阶段。这样你就能进入第一阶段的容器里调试了。

这个设计真的很优雅。你可以有三个、四个甚至更多阶段:

FROM node:18 AS frontend-builder
# 前端构建

FROM golang:1.21 AS backend-builder
# 后端构建

FROM nginx:alpine
# 把前端和后端产物都复制进来
COPY --from=frontend-builder /app/dist /usr/share/nginx/html
COPY --from=backend-builder /app/api /usr/local/bin/api

每个阶段独立完成自己的任务,最后汇总到运行阶段。这种组织方式让Dockerfile的逻辑变得特别清晰。

说实话,我现在写Dockerfile,只要是编译型语言,默认就用多阶段构建。已经养成习惯了。

Go应用的极致瘦身

Go是我最喜欢做镜像优化的语言。为什么?Go编译出来的二进制文件是静态链接的,不依赖任何系统库,可以直接扔到空白镜像里运行。

先看传统的做法(别学):

FROM golang:1.21
WORKDIR /app
COPY . .
RUN go build -o myapp
CMD ["./myapp"]

构建一下:

docker build -t myapp:old .
docker images myapp:old
# REPOSITORY   TAG    IMAGE ID       SIZE
# myapp        old    abc123def456   295MB

295MB。一个简单的HTTP服务,就要这么大。

现在来看多阶段优化版本:

# 构建阶段
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 scratch
WORKDIR /app
COPY --from=builder /app/myapp .
EXPOSE 8080
CMD ["./myapp"]

再构建一次:

docker build -t myapp:new .
docker images myapp:new
# REPOSITORY   TAG    IMAGE ID       SIZE
# myapp        new    def456ghi789   6.47MB

6.47MB!从295MB到6.47MB,减少了98%。

这个Dockerfile有几个关键点:

1. CGO_ENABLED=0

这个环境变量告诉Go编译器禁用CGO,生成纯静态链接的二进制文件。如果你的代码用了C库(比如SQLite),这招就不灵了,得用别的基础镜像。

2. -ldflags=“-w -s”

这是编译器优化参数:

• -w:去掉调试信息
• -s:去掉符号表

这能让二进制文件再小20%-30%。生产环境基本用不到这些信息,砍掉没问题。

3. FROM scratch

scratch是Docker的空白镜像,什么都没有,体积0字节。Go的静态二进制文件可以直接在scratch里运行,不需要任何系统库。

4. 依赖缓存技巧

注意我先复制go.mod和go.sum,再执行go mod download。这样做的好处是:只要这两个文件不变,Docker就会使用缓存的依赖层,不用重新下载。改了业务代码不会触发依赖重新下载,构建速度快很多。

我测试过,用了这个技巧后,改代码重新构建的时间从2分钟降到了15秒。

进阶:处理时区和CA证书

scratch镜像太干净了,连时区数据和CA证书都没有。如果你的应用需要发HTTPS请求或者处理时区,会报错。解决办法是从builder阶段复制这些文件:

FROM scratch
WORKDIR /app
# 复制时区数据
COPY --from=builder /usr/share/zoneinfo /usr/share/zoneinfo
# 复制CA证书
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
COPY --from=builder /app/myapp .
ENV TZ=Asia/Shanghai
CMD ["./myapp"]

或者干脆用gcr.io/distroless/static-debian11代替scratch,这个镜像只有2MB,但包含了时区数据和CA证书:

FROM gcr.io/distroless/static-debian11
COPY --from=builder /app/myapp /app/myapp
CMD ["/app/myapp"]

我现在一般用distroless,省心很多。

Java/Spring Boot的优雅瘦身

Java的镜像优化比Go复杂一些。Java需要JRE运行环境,不能像Go那样用scratch镜像。但用对方法,体积还是能压下来很多。

传统做法(很多Java项目都这么干):

FROM maven:3.8-openjdk-17
WORKDIR /app
COPY . .
RUN mvn clean package -DskipTests
CMD ["java", "-jar", "target/myapp.jar"]

构建后的镜像有650MB。Maven镜像本身就500MB,再加上你的jar包和各种缓存,体积失控很正常。

多阶段优化版本:

# 构建阶段
FROM maven:3.8-openjdk-17-slim AS builder
WORKDIR /app

# 先复制pom.xml,下载依赖(利用缓存)
COPY pom.xml .
RUN mvn dependency:go-offline -B

# 复制源代码并打包
COPY src ./src
RUN mvn package -DskipTests

# 运行阶段
FROM openjdk:17-jre-slim
WORKDIR /app

# 只复制jar包
COPY --from=builder /app/target/*.jar app.jar

# JVM参数调优
ENV JAVA_OPTS="-Xms128m -Xmx512m -XX:+UseContainerSupport"

EXPOSE 8080
CMD java $JAVA_OPTS -jar app.jar

构建后:

docker images myapp:new
# REPOSITORY   TAG    IMAGE ID       SIZE
# myapp        new    xyz789abc012   89MB

从650MB降到89MB,减少86%。

关键点解析:

1. JDK vs JRE

构建阶段用openjdk-17(包含编译器),运行阶段用openjdk-17-jre-slim(只有运行时)。JRE比JDK小一半多:

• OpenJDK 17: 约500MB
• OpenJDK 17 JRE: 约200MB
• OpenJDK 17 JRE Slim: 约80MB

2. Maven依赖缓存

先复制pom.xml,执行mvn dependency:go-offline下载所有依赖。只要pom.xml不变,这一层就会被缓存。改业务代码不会触发重新下载依赖。

这个技巧太重要了。我之前没用这招,每次改一行代码重新构建都要下载依赖,Maven仓库在国外,经常卡住十几分钟。现在只要几秒钟。

3. JVM参数调优

-XX:+UseContainerSupport让JVM感知容器的内存限制。不加这个参数,JVM会按宿主机的内存来分配堆大小,容器很容易OOM。

-Xms128m -Xmx512m设置堆内存范围。根据你的应用实际需求调整,别无脑设1G。

Gradle版本

如果你用Gradle,稍微改一下:

FROM gradle:8.5-jdk17 AS builder
WORKDIR /app

# 复制Gradle配置文件
COPY build.gradle settings.gradle ./
COPY gradle ./gradle

# 下载依赖
RUN gradle dependencies --no-daemon

# 复制源代码并构建
COPY src ./src
RUN gradle bootJar --no-daemon

FROM openjdk:17-jre-slim
WORKDIR /app
COPY --from=builder /app/build/libs/*.jar app.jar
ENV JAVA_OPTS="-Xms128m -Xmx512m -XX:+UseContainerSupport"
CMD java $JAVA_OPTS -jar app.jar

一个坑:Spring Boot分层构建

Spring Boot 2.3+支持jar分层,可以把依赖和业务代码分开,进一步优化缓存。这个稍微高级一点,代码长这样:

FROM maven:3.8-openjdk-17-slim AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline -B
COPY src ./src
RUN mvn package -DskipTests
RUN java -Djarmode=layertools -jar target/*.jar extract

FROM openjdk:17-jre-slim
WORKDIR /app
# 按照层的顺序复制,依赖层变化频率最低
COPY --from=builder /app/dependencies/ ./
COPY --from=builder /app/spring-boot-loader/ ./
COPY --from=builder /app/snapshot-dependencies/ ./
COPY --from=builder /app/application/ ./
CMD ["java", "org.springframework.boot.loader.JarLauncher"]

这样即使你改了业务代码,依赖层也不会失效,构建更快。不过老实讲,我一般不用这招,维护成本稍高,上面那个简单版本已经够用了。

Rust应用的最小化部署

Rust的镜像优化效果最夸张。Rust工具链超级大(1.5GB+),但编译出来的二进制文件超级小。我第一次看到优化效果时都惊了——2.1GB到11.2MB,这也太离谱了。

传统做法:

FROM rust:1.75
WORKDIR /app
COPY . .
RUN cargo build --release
CMD ["./target/release/myapp"]

构建完镜像2.1GB。Rust工具链太大了,rustc编译器、cargo、各种依赖,全打包进去了。

多阶段优化版本:

# 构建阶段
FROM rust:1.75 AS builder
WORKDIR /app

# 复制依赖文件,先编译依赖(利用缓存)
COPY Cargo.toml Cargo.lock ./
RUN mkdir src && echo "fn main() {}" > src/main.rs
RUN cargo build --release
RUN rm -rf src

# 复制真实代码,编译应用
COPY src ./src
RUN touch src/main.rs  # 更新时间戳,触发重新编译
RUN cargo build --release

# 运行阶段
FROM gcr.io/distroless/cc-debian11
WORKDIR /app
COPY --from=builder /app/target/release/myapp .
CMD ["./myapp"]

构建后:

docker images myapp:new
# REPOSITORY   TAG    IMAGE ID       SIZE
# myapp        new    rst345uvw678   11.2MB

11.2MB!减少了99.4%。

Rust特有的缓存优化

Rust的依赖编译特别慢,经常一编译就是十几分钟。上面那个技巧的核心是:先创建一个假的main.rs,让cargo编译依赖,然后删掉假文件,复制真实代码再编译。

这样只要Cargo.toml和Cargo.lock不变,依赖层就会被缓存。改业务代码只需要重新编译你的代码,不用重新编译依赖。

我实测过,一个中型项目,用了这招后,修改代码重新构建的时间从15分钟降到了2分钟。

静态链接 vs 动态链接

Rust默认编译的二进制文件可能依赖glibc。如果你的代码完全是纯Rust,没用C库,可以用musl编译成完全静态链接的二进制,然后用scratch镜像:

FROM rust:1.75 AS builder
WORKDIR /app

# 安装musl工具链
RUN rustup target add x86_64-unknown-linux-musl

COPY Cargo.toml Cargo.lock ./
RUN mkdir src && echo "fn main() {}" > src/main.rs
RUN cargo build --release --target x86_64-unknown-linux-musl
RUN rm -rf src

COPY src ./src
RUN touch src/main.rs
RUN cargo build --release --target x86_64-unknown-linux-musl

# 运行阶段
FROM scratch
COPY --from=builder /app/target/x86_64-unknown-linux-musl/release/myapp /myapp
CMD ["/myapp"]

这样镜像体积还能再小一点,可能只有5-8MB。

不过说实话,我一般直接用gcr.io/distroless/cc,兼容性更好,体积也就多几MB,值得。

一个坑:Cargo缓存位置

有些文章会教你把/usr/local/cargo目录也缓存起来。别这么干。这个目录里有大量编译中间产物,会让缓存层变得特别大,反而更慢。我踩过这个坑,当时缓存层有800MB,每次构建都要等很久。

让构建又快又稳的进阶技巧

前面讲的是多阶段构建的基本用法。这一节聊聊一些让构建更快、更稳定的技巧。

1. .dockerignore文件

这个太重要了,但很多人忽略。.dockerignore的作用和.gitignore类似,告诉Docker哪些文件不要复制到构建上下文。

我之前没用这个,每次构建Docker都要把整个项目目录(包括node_modules、.git、target等)打包发给Docker daemon。一个项目几百MB,光发送上下文就要等半分钟。

现在每个项目我都会创建.dockerignore:

# 版本控制
.git
.gitignore

# 依赖目录
node_modules
target
dist
build

# IDE
.vscode
.idea
*.swp

# 测试和文档
**/*_test.go
**/*_test.rs
*.md
docs/

# 环境变量和密钥
.env
.env.local
*.key
*.pem

加了这个文件后,我的构建速度快了3-5倍。特别是在CI/CD流水线里,效果特别明显。

2. 调试多阶段构建

前面提到过--target参数,这里展开说说。假设你的构建在builder阶段失败了,怎么调试?

# 只构建到builder阶段
docker build --target builder -t myapp:debug .

# 进入这个镜像
docker run -it myapp:debug sh

# 在容器里手动执行构建命令,看哪里出错

这招特别实用。有次我的Go项目构建失败,报了个奇怪的错误。我用这个方法进入builder容器,手动运行go build,才发现是Go版本和依赖不兼容。

3. 命名构建阶段

给每个阶段起个有意义的名字,别用stage1、stage2这种。对比一下:

# 不好
FROM golang:1.21 AS stage1
FROM node:18 AS stage2
FROM nginx AS stage3

# 好
FROM golang:1.21 AS backend-builder
FROM node:18 AS frontend-builder
FROM nginx AS runtime

几个月后回来看代码,你会感谢当初起名认真的自己。

4. BuildKit并行构建

Docker BuildKit是新一代构建引擎,支持并行构建、更好的缓存机制。启用它:

export DOCKER_BUILDKIT=1
docker build .

或者在构建时临时启用:

DOCKER_BUILDKIT=1 docker build .

BuildKit有几个好处:

• 多个独立阶段可以并行构建
• 更智能的缓存策略
• 构建输出更清晰

我现在默认都用BuildKit,在CI/CD里也配置了DOCKER_BUILDKIT=1。

5. 固定基础镜像版本

别用FROM golang:latest,这是个坑。生产环境一定要固定版本:

# 不好 - 行为不确定
FROM golang:latest

# 好 - 明确版本
FROM golang:1.21.5-alpine3.18

# 更好 - 用SHA256固定
FROM golang@sha256:abc123...

我之前吃过亏,某次部署突然失败,查了半天发现是golang:latest更新了,新版本和我们的依赖不兼容。从那以后我都固定版本。

6. 合理使用COPY的缓存

COPY指令的顺序很重要。把不常变的文件放前面,常变的放后面:

# 好的顺序
FROM golang:1.21-alpine AS builder
WORKDIR /app

# 1. 先复制依赖文件(很少变)
COPY go.mod go.sum ./
RUN go mod download

# 2. 再复制源代码(经常变)
COPY . .
RUN go build -o myapp

# 不好的顺序
COPY . .  # 一次性复制所有文件
RUN go mod download && go build -o myapp

第一种方式,改代码不会触发依赖重新下载。第二种方式,改任何文件都要重新下载依赖。

这个技巧在前面的案例里反复用到了,但值得再强调一遍——这是缓存优化的核心原理。

基础镜像选择指南

选基础镜像挺让人头疼的。Alpine、Slim、Distroless、Scratch,每个都有人推荐,到底选哪个?我根据实际经验,整理了一张对比表:

我的选择策略:

Go应用

• 首选:gcr.io/distroless/static-debian11(包含CA证书)
• 备选:scratch(需要手动复制CA证书和时区数据)
• 如果用了CGO:gcr.io/distroless/base-debian11或alpine

Java应用

• 首选:openjdk:17-jre-slim(完整JRE,兼容性好)
• 进阶:gcr.io/distroless/java17-debian11(更小更安全,但调试困难)
• 避免:openjdk:17-alpine(JVM在Alpine上有些bug)

Rust应用

• 首选:gcr.io/distroless/cc-debian11(包含C运行时库)
• 如果纯静态编译:scratch
• 避免:完整的rust镜像(生产环境没必要)

关于Alpine的坑

很多文章推荐Alpine,但我踩过几个坑:

1. musl libc兼容性:Alpine用的是musl libc,不是glibc。有些程序(特别是Java、Python)在Alpine上会出现奇怪的bug
2. DNS解析问题:Go程序在Alpine上有时会遇到DNS解析超时,需要特殊配置
3. 时区问题:默认没有时区数据,需要手动安装tzdata包

我的建议:如果你对Alpine不是特别熟悉,用-slim镜像更稳妥。体积可能多几十MB,但少踩坑。

关于Distroless

Distroless是Google推出的最小化镜像,特点是没有shell、没有包管理器,只包含运行时必需的东西。

优点:

• 攻击面极小,黑客进不来(没shell怎么执行命令?)
• 体积小
• 官方维护,定期更新安全补丁

缺点:

• 调试困难,不能docker exec -it进去看
• 需要在构建阶段准备好所有文件

我现在生产环境基本都用Distroless。调试的时候用--target builder进入构建阶段的容器,生产跑的是Distroless。

一个决策树

不知道选哪个?按这个流程:

你的应用是什么语言?
├─ Go
│  ├─ 纯Go代码 → distroless/static 或 scratch
│  └─ 用了CGO → distroless/base 或 alpine
├─ Java
│  ├─ 追求稳定 → openjdk:jre-slim
│  └─ 追求体积 → distroless/java
├─ Rust
│  ├─ 纯Rust → distroless/cc 或 scratch
│  └─ 用了C库 → distroless/cc
└─ 其他
   └─ 先用slim试试,有问题再换

这个决策树是我从实际项目里总结出来的,基本能覆盖90%的场景。

说了这么多,核心就三点

多阶段构建的精髓其实很简单:

1. 构建阶段:用完整镜像编译代码
2. 运行阶段:用精简镜像跑应用
3. COPY —from:只传递必要的产物

就这么简单。但效果真的夸张——体积减少70%-90%,构建缓存优化后速度快2-3倍,安全性大幅提升。

我现在的习惯是:新项目第一件事就是写多阶段Dockerfile。不管是Go、Java还是Rust,默认都用这个模式。已经养成肌肉记忆了。

给你几个行动建议:

今天就能做的:

• 找一个现有项目,试试多阶段构建
• 用docker images看看优化前后的体积对比
• 如果效果好,立刻推广到其他项目

值得深入学习的:

• 看看Docker官方文档的最佳实践
• 试试dive工具分析镜像层(docker run --rm -it wagoodman/dive:latest your-image)
• 研究一下BuildKit的高级特性

长期优化方向:

• 在CI/CD流水线里配置镜像缓存
• 定期更新基础镜像版本,修复安全漏洞
• 用安全扫描工具(如Trivy)检查镜像

最后说点心里话。Docker镜像优化这事,技术上不难,难在意识。很多团队的镜像都是几年前搭建的,一直没人管,越堆越大。直到某天部署慢到受不了,才想起来优化。

别等到那一天。今天就试试多阶段构建,你会发现,原来镜像可以这么小,构建可以这么快。

评论区聊聊:你们项目的镜像有多大?优化后效果如何?遇到什么坑了吗?我都挺感兴趣。

16 分钟阅读 · 发布于: 2025年12月17日 · 修改于: 2025年12月26日

Easton

技术开发