继昨天攻克 Docker 数据卷管理难题后，今天的学习目标锁定在 Docker 镜像的 “瘦身术”——镜像分层构建与优化。在实际部署中，臃肿的镜像会导致传输缓慢、存储占用高，甚至延长容器启动时间。通过今天的实战，我不仅理解了镜像分层的底层逻辑，更掌握了一套可落地的镜像优化方案，将一个原本 500MB 的 Java 应用镜像压缩到了 150MB 以内。
一、镜像分层原理：理解 “写时复制”
Docker 镜像采用分层存储架构，每一条 Dockerfile 指令都会生成一个只读层，容器启动时会在镜像顶层添加一个可写层。这种设计的核心是写时复制（Copy-on-Write） 机制：当容器修改文件时，只会复制该文件到可写层，不会改动底层镜像，既节省存储空间，又提高镜像复用率。
通过docker inspect java-app:v1查看镜像详情，发现其由 12 层组成，其中FROM openjdk:11基础镜像占了 8 层，COPY和RUN指令各生成 2 层。这也解释了为何基础镜像选择至关重要 —— 一个精简的基础镜像能从源头减少分层数量和体积。
二、分层构建实战：多阶段构建的妙用
传统构建方式会将编译、依赖安装等过程全部纳入最终镜像，导致冗余文件堆积。而多阶段构建通过多个FROM指令，只将最终运行所需的文件复制到目标镜像，大幅减少体积。以 Java 应用为例，优化前后的 Dockerfile 对比明显：
优化前（单阶段构建）
FROM openjdk:11
WORKDIR /app
COPY . .
# 编译过程与运行环境混在一起
RUN ./gradlew build
CMD ["java", "-jar", "build/libs/app.jar"]
最终镜像包含 Gradle 依赖、源码等冗余文件，体积达 520MB。
优化后（多阶段构建）
# 第一阶段：编译阶段（仅用于生成jar包）
FROM gradle:7.5-jdk11 AS builder
WORKDIR /app
COPY . .
RUN gradle build --no-daemon # 关闭守护进程减少缓存
# 第二阶段：运行阶段（仅保留运行所需文件）
FROM openjdk:11-jre-slim # 选用精简的jre基础镜像
WORKDIR /app
# 仅复制第一阶段的jar包到当前镜像
COPY --from=builder /app/build/libs/app.jar .
CMD ["java", "-jar", "app.jar"]
优化后镜像体积降至 145MB，去除了所有编译依赖和源码，仅保留运行必需的 JRE 和 jar 包。
三、镜像瘦身的 5 个关键技巧
除多阶段构建外，今天还总结了其他实用优化技巧：
- 选用精简基础镜像：优先选择alpine或slim版本，如nginx:alpine（体积仅 22MB）比nginx（142MB）小 6 倍。
- 合并 RUN 指令减少分层：将多个RUN命令用&&合并，避免生成过多分层。例如：
RUN apt update && apt install -y curl && rm -rf /var/lib/apt/lists/*
同时通过rm -rf清理安装缓存，进一步减少体积。
- 合理使用.dockerignore：排除.git、node_modules、日志文件等无需纳入镜像的文件，避免无效文件占用空间。
- 指定镜像标签而非 latest：使用nginx:1.25-alpine而非nginx:latest，确保构建结果可复现，同时避免拉取不必要的新版本。
- 清理临时文件：在同一RUN指令中完成安装与清理，防止临时文件被纳入分层。例如 Python 应用安装依赖后清理缓存：
RUN pip install -r requirements.txt && rm -rf ~/.cache/pip
四、镜像优化效果验证
为确保优化有效，可通过两个命令验证：
- docker images --format "{{.Repository}}:{{.Tag}} {{.Size}}"：查看镜像体积变化；
- docker history java-app:v2：查看镜像各分层的体积占比，定位仍可优化的环节。
今天优化的 Java 应用镜像，不仅体积减少 72%，传输速度也从原来的 2 分钟缩短至 30 秒，容器启动时间从 15 秒降至 8 秒。这让我意识到，镜像优化不是单纯的 “瘦身”，更是提升部署效率和系统稳定性的关键环节。
明天计划学习 Docker 镜像仓库的搭建与管理，包括私有仓库配置、镜像版本控制和安全扫描，为镜像的全生命周期管理做好准备。
