Docker多阶段镜像构建实践：CI/CD流水线中的镜像瘦身方案

Docker自动化部署中镜像体积过大是常见痛点。单阶段构建将编译工具链、依赖缓存和运行时全部打包到最终镜像，一个简单的Java应用镜像可能超过1GB。本文通过多阶段构建方案，将Spring Boot应用镜像从1.2GB降至190MB，并介绍层缓存优化和CI/CD集成方法。

单阶段构建的痛点分析

单阶段构建将编译工具链、依赖缓存和运行时全部打包到最终镜像中，Node.js应用镜像动辄800MB以上。镜像过大会导致拉取慢、部署延迟高、存储成本增加。

查看镜像各层大小的命令：

# 查看镜像历史层
docker history myapp:latest

# 查看镜像大小
docker images myapp:latest

常见的镜像膨胀原因包括：基础镜像选择不当（如使用ubuntu而非alpine）、编译工具链未清理、.git目录被打包、测试数据和文档文件残留。

多阶段构建语法与结构

多阶段构建通过FROM指令定义多个构建阶段，最终镜像只包含最后一个阶段的内容。编译阶段可以使用完整的SDK镜像，运行阶段则切换到精简的基础镜像。

以Spring Boot应用为例：

# 阶段1：构建阶段
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /build
COPY pom.xml .
# 先下载依赖（利用层缓存）
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package -DskipTests

# 阶段2：运行阶段
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
# 仅复制构建产物
COPY --from=builder /build/target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

构建阶段使用maven:3.9-eclipse-temurin-17（约800MB），但最终镜像基于eclipse-temurin:17-jre-alpine（约170MB），镜像体积从1.2GB降至约190MB。

层缓存优化策略

Dockerfile中每条指令生成一个镜像层。层缓存机制使得未变更的层可以复用，但指令顺序直接影响缓存命中率。核心原则是：变更频率低的指令放前面，变更频率高的指令放后面。

# 错误写法：COPY src在前，任何代码修改都会使后续层缓存失效
FROM node:18-alpine AS builder
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build

# 正确写法：先COPY package.json，依赖安装层可缓存
FROM node:18-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --production=false
COPY . .
RUN npm run build

对于pnpm项目，使用pnpm fetch命令可以在不复制源码的情况下预获取依赖：

FROM node:18-alpine AS builder
RUN npm install -g pnpm
WORKDIR /app
COPY pnpm-lock.yaml ./
RUN pnpm fetch
COPY . .
RUN pnpm install --offline --frozen-lockfile
RUN pnpm run build

.dockerignore配置

.dockerignore文件的作用类似.gitignore，在构建上下文中排除不需要的文件。合理的.dockerignore配置可以减少构建上下文大小，加速构建过程。

# .dockerignore
.git
.gitignore
node_modules
dist
build
*.md
.env
.env.local
.vscode
.idea
coverage
npm-debug.log
Dockerfile
docker-compose.yml
.test
tests
__pycache__
*.pyc

排除tests和coverage目录不仅能减小构建上下文，还能避免测试数据被意外打包到生产镜像中。.env文件的排除尤为关键，防止敏感配置信息泄露到镜像层中。

CI/CD流水线集成

在GitLab CI中集成多阶段构建，配合BuildKit的缓存挂载功能，可以显著提升构建速度：

# .gitlab-ci.yml
build:
  stage: build
  image: docker:24.0
  services:
    - docker:24.0-dind
  variables:
    DOCKER_BUILDKIT: 1
  script:
    - docker build
        --cache-from type=registry,ref=$CI_REGISTRY_IMAGE:cache
        --cache-to type=registry,ref=$CI_REGISTRY_IMAGE:cache,mode=max
        --build-arg BUILDKIT_INLINE_CACHE=1
        -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
        -t $CI_REGISTRY_IMAGE:latest
        .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
    - docker push $CI_REGISTRY_IMAGE:latest

BuildKit的cache-to和cache-from参数将构建缓存存储在Registry中，不同分支和Pipeline之间可以共享缓存。mode=max表示缓存所有中间层，包括多阶段构建中非最终阶段的层。

镜像构建完成后，使用dive工具分析镜像层组成，定位体积优化空间：

# 安装dive
brew install dive

# 分析镜像
dive myapp:latest

dive会展示每一层的新增文件、删除文件和修改文件，帮助快速发现可优化的层。如果发现某层包含不必要的文件（如apt缓存、临时下载），可以在Dockerfile中对应指令后添加清理命令。对于Alpine基础镜像，在apk add后添加–no-cache参数可避免缓存文件写入镜像层。