Docker 镜像优化完全指南

为什么镜像会"虚胖"

Docker 镜像是分层构建的（UnionFS），每一行指令（RUN、COPY）生成一个独立层。即使在下一行删除了文件，上一层的文件依然存在。随便写 Dockerfile 很容易让镜像"虚胖"——见过太多团队基础镜像用 ubuntu:latest，一个 RUN 装几十个包不清理缓存，最终镜像 1.2GB。

优化过的 Dockerfile 能把镜像从 1.2GB 压缩到 80MB，构建时间从 15 分钟降到 30 秒（利用缓存后），同时减少 90% 的安全漏洞面。

分层缓存：指令顺序决定构建速度

Docker 构建缓存的规则：从第一条变更的指令开始，后续所有层的缓存全部失效。所以要把变化频率低的指令放前面，变化频率高的放后面。

缓存利用的最佳顺序

1. FROM（基础镜像，几乎不变）
2. 安装系统依赖（apt/apk install，偶尔变）
3. 复制依赖描述文件（package.json / pom.xml / go.mod）
4. 安装应用依赖（npm ci / mvn install / go mod download）
5. 复制源代码（每次提交都变）
6. 构建应用
7. 配置运行参数（CMD / ENTRYPOINT）

正确 vs 错误示例

# ❌ 错误：COPY . . 放在安装依赖之前
# 任何源码文件变更都会导致依赖重新安装
FROM node:20.11-alpine3.19
WORKDIR /app
COPY . .
RUN npm ci --production

# ✅ 正确：先复制依赖文件，安装依赖，再复制源码
# 只有 package.json 变更才会重新安装依赖
FROM node:20.11-alpine3.19
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --production
COPY . .

瘦身"三板斧"

1️⃣ 选用精简基础镜像

原则： 生产环境优先选 alpine 或 slim 版本。完整版本号锁定（如 node:20.11.1-alpine3.19），不用 latest。

⚠️ alpine 使用 musl libc 而非 glibc，部分 C 扩展可能有兼容性问题。遇到段错误换 slim 变体。

2️⃣ 多阶段构建

把"编译环境"和"运行环境"彻底分开。编译环境可能需要 JDK、Maven、gcc 等工具（几百 MB），但运行时只需要 JRE 或一个二进制文件。效果：体积减少 70-90%。

Go 应用 — 从 1.2GB 到 45MB：

# 阶段1：编译（Go SDK ~800MB）
FROM golang:1.22-alpine AS builder
WORKDIR /build
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /app/server .

# 阶段2：运行（scratch，0字节）
FROM scratch
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
COPY --from=builder /app/server /server
EXPOSE 8080
ENTRYPOINT ["/server"]

• -ldflags="-s -w" 去掉调试信息，二进制减小约 30%
• CGO_ENABLED=0 生成静态链接二进制，可在 scratch 上运行
• 详见 go-static-compilation-docker（UPX 压缩 + scratch 极致瘦身）

Java 应用 — Maven 多阶段构建：

# 阶段1：编译（Maven ~800MB）
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /build
COPY pom.xml .
RUN mvn dependency:go-offline -B
COPY src ./src
RUN mvn package -DskipTests -B

# 阶段2：运行（JRE alpine ~180MB）
FROM eclipse-temurin:17-jre-alpine
RUN addgroup -g 1000 app && adduser -u 1000 -G app -s /bin/sh -D app
WORKDIR /app
COPY --from=builder --chown=app:app /build/target/*.jar app.jar
USER app
EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=5s --start-period=60s --retries=3 \
 CMD wget -qO- http://localhost:8080/actuator/health || exit 1
ENTRYPOINT ["java", "-XX:MaxRAMPercentage=75.0", "-jar", "app.jar"]

3️⃣ RUN 指令优化 + .dockerignore

安装和清理必须在同一行 RUN 指令中完成（否则缓存永久保留）：

# ✅ Debian/Ubuntu 正确写法
RUN apt-get update && \
 apt-get install -y --no-install-recommends \
 curl wget ca-certificates \
 && rm -rf /var/lib/apt/lists/*

# ✅ Alpine 正确写法（--no-cache 等价效果）
RUN apk add --no-cache curl tzdata && \
 cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && \
 apk del tzdata

--no-install-recommends 不安装推荐包，能减少 30-50% 的安装体积。rm -rf /var/lib/apt/lists/* 清理 apt 缓存，节省约 30MB。

.dockerignore 排除不需要的文件，构建上下文越小构建越快：

.git/
node_modules/
target/
*.log
.idea/
.vscode/

内网搭建软件包仓库可大幅提升构建速度。将构建依赖（如源码包 tar.gz）存放到内网地址，Dockerfile 中指向内网源下载，避免每次构建从外网拉取。

COPY vs ADD

# ✅ 推荐：COPY 行为明确
COPY app.jar /app/
COPY --chown=app:app config/ /app/config/

# ✅ 需要解压时用 ADD（唯一合理场景）
ADD archive.tar.gz /app/

# ❌ 不推荐：ADD 从 URL 下载（用 curl 更可控）
RUN curl -fsSL https://example.com/file.tar.gz -o /tmp/file.tar.gz && \
 tar xzf /tmp/file.tar.gz -C /app/ && rm /tmp/file.tar.gz

ENTRYPOINT 与 CMD

# ❌ shell形式：sh 是 PID 1，java 是子进程，收不到 SIGTERM
ENTRYPOINT java -jar app.jar

# ✅ exec形式：java 是 PID 1，能正确接收信号
ENTRYPOINT ["java", "-jar", "app.jar"]

组合用法： ENTRYPOINT 定义主进程，CMD 提供默认参数。docker run 后的参数覆盖 CMD 但不会覆盖 ENTRYPOINT。

BuildKit 高级特性

BuildKit（Docker 18.09+）支持三大高级挂载，构建速度提升 2-3 倍：

缓存挂载（type=cache）

持久化包管理器缓存，跨构建保留。即使镜像层缓存失效，依赖缓存仍然有效：

# syntax=docker/dockerfile:1
FROM maven:3.9-eclipse-temurin-17 AS builder
COPY pom.xml .
RUN --mount=type=cache,target=/root/.m2/repository \
 mvn dependency:go-offline -B
COPY src ./src
RUN --mount=type=cache,target=/root/.m2/repository \
 mvn package -DskipTests -B

效果：第一次构建 8 分钟（下载所有依赖），第二次构建（只改源码）→ 40 秒。

密钥挂载（type=secret）

密钥只存在于构建过程，不会写入镜像层：

RUN --mount=type=secret,id=npmrc,target=/root/.npmrc \
 npm ci --production

docker build --secret id=npmrc,src=$HOME/.npmrc -t myapp:1.0.0 .

SSH 转发（type=ssh）

RUN --mount=type=ssh git clone [email protected]:company/private-lib.git

docker build --ssh default -t myapp:1.0.0 .

安全加固

1. 非 root 用户运行：USER app，配合 COPY --chown=app:app
2. 固定版本号：不用 latest，不用 node:20，用 node:20.11.1-alpine3.19
3. 不在镜像中存储密钥：用 BuildKit --mount=type=secret

4. 安全扫描集成 CI：Trivy 阻断 HIGH/CRITICAL 漏洞 bash trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:1.0.0

5. tini 作为 PID 1（Node.js 场景）：处理信号和僵尸进程回收，仅几十 KB dockerfile RUN apk add --no-cache tini ENTRYPOINT ["/sbin/tini", "--"] CMD ["node", "server.js"]

优化效果对比（Go 微服务案例）

CI/CD 集成

生产级构建脚本：

#!/bin/bash
set -euo pipefail

APP_NAME="myapp"
REGISTRY="registry.example.com"
VERSION="${CI_COMMIT_TAG:-$(git rev-parse --short HEAD)}"
IMAGE="${REGISTRY}/${APP_NAME}:${VERSION}"

# 构建（含 OCI 标签）
docker build \
 --label "org.opencontainers.image.version=${VERSION}" \
 --label "org.opencontainers.image.revision=$(git rev-parse HEAD)" \
 -t "${IMAGE}" -t "${REGISTRY}/${APP_NAME}:latest" .

# 安全扫描（阻断高危漏洞）
trivy image --exit-code 1 --severity HIGH,CRITICAL "${IMAGE}"

# 推送
docker push "${IMAGE}"

远程构建缓存（多个 CI Runner 共享）：

docker buildx build \
 --cache-from type=registry,ref=registry.example.com/myapp:buildcache \
 --cache-to type=registry,ref=registry.example.com/myapp:buildcache,mode=max \
 -t myapp:1.0.0 .

常见错误速查

排障工具链

# 镜像分层分析（推荐）
dive myapp:1.0.0

# 查看分层历史（每层大小和指令）
docker history myapp:1.0.0

# 查看构建缓存使用
docker buildx du

# 安全漏洞扫描
trivy image myapp:1.0.0

# 镜像大小趋势
docker images --format "{{.Repository}}:{{.Tag}} {{.Size}}" | sort

监控指标

命令速查表

# 构建
docker build -t name:tag . # 基本构建
docker build --no-cache -t name:tag . # 不使用缓存
docker build --build-arg KEY=VALUE -t name:tag . # 传入构建参数
docker buildx build --platform linux/amd64,linux/arm64 -t name:tag --push . # 多架构

# 分析
docker history name:tag # 分层历史
docker inspect name:tag # 镜像元数据
dive name:tag # 交互式层分析

# 缓存
docker builder prune # 清理构建缓存
docker buildx du # 查看缓存使用量

# 安全
trivy image name:tag # 漏洞扫描
docker scout cves name:tag # Docker 官方扫描

核心原则

生产环境镜像只应该包含运行你的应用所必需的最小文件集，其他的统统不要。

关联页面