企业官网建设流程全解析

Docker 镜像体积优化实战：从 1GB 到 100MB

适用人群：已经使用 Docker，有镜像体积焦虑的开发者 / 运维工程师
阅读目标：掌握一套可复用的镜像瘦身方法论，而不是零散技巧

一、为什么 Docker 镜像会变得这么大？

很多人第一次docker images时，都会被一个现象震惊：

REPOSITORY TAG SIZE my-app latest 1.2GB

而冷静分析后会发现：

• 实际业务代码：可能只有几十 MB
• 但镜像体积：却轻松上 GB

镜像变大的常见原因

1. 选择了过于“臃肿”的基础镜像
2. 把构建工具、编译产物一并打进了镜像
3. Dockerfile 层设计不合理
4. 构建缓存、临时文件未清理
5. 把无关文件一起 COPY 进镜像

镜像体积问题，本质是 Dockerfile 工程质量问题。

二、先建立一个“正确的认知”

在动手优化前，必须明确两点：

1. 镜像不是越小越好，而是“在可维护前提下尽量小”

2. 优化的目标不是炫技，而是：

   • 更快的构建
   • 更快的拉取
   • 更低的存储和网络成本

三、第一步：选对基础镜像（最重要的一步）

1. 错误示例（新手最常见）

FROM ubuntu:22.04

然后在里面手动安装 Python、Node、JDK……

问题：

• 系统层本身就很大
• 维护成本高

2. 正确思路：使用官方语言镜像

FROM python:3.11

但这一步还远远不够。

3. 更进一步：使用 slim 版本

FROM python:3.11-slim

体积对比（大致）：

仅这一行，就可能减少 700MB。

四、第二步：多阶段构建（瘦身的核心武器）

为什么多阶段构建如此重要？

因为：

• 构建阶段 ≠ 运行阶段
• 编译器、构建工具在运行时是“垃圾”

示例：没有优化前（典型 1GB 镜像）

FROM python:3.11 RUN apt update && apt install -y build-essential COPY . /app WORKDIR /app RUN pip install -r requirements.txt CMD ["python", "app.py"]

问题：

• 编译工具被永久保留
• 镜像层污染严重

优化后：多阶段构建

# 构建阶段 FROM python:3.11-slim AS builder RUN apt update && apt install -y build-essential WORKDIR /build COPY requirements.txt . RUN pip install --prefix=/install -r requirements.txt # 运行阶段 FROM python:3.11-slim WORKDIR /app COPY --from=builder /install /usr/local COPY . . CMD ["python", "app.py"]

效果：

• 构建工具不进入最终镜像
• 体积大幅下降

五、第三步：减少无意义的镜像层

错误示例

RUN apt update RUN apt install -y curl RUN rm -rf /var/lib/apt/lists/*

正确示例

RUN apt update \ && apt install -y curl \ && rm -rf /var/lib/apt/lists/*

原则：

一次 RUN，完成一个逻辑闭环。

六、第四步：使用 .dockerignore（被严重低估）

如果没有 .dockerignore，会发生什么？

COPY . .

这会把以下内容全部打包：

• .git
• 虚拟环境
• 本地缓存
• 日志文件

示例 .dockerignore

.git __pycache__ .env venv node_modules logs

效果：

• 镜像体积直接下降
• 构建速度显著提升

七、第五步：清理缓存与临时文件

Python 依赖安装

RUN pip install --no-cache-dir -r requirements.txt

APT 安装

RUN apt update \ && apt install -y xxx \ && rm -rf /var/lib/apt/lists/*

八、第六步：不要滥用 COPY . .

推荐顺序：

COPY requirements.txt . RUN pip install -r requirements.txt COPY src/ src/

好处：

• 最大化利用缓存
• 减少不必要重建

九、真实案例：从 1GB 到 100MB 的变化

不是魔法，是工程细节。

十、一些“不要做”的反模式

1. 为了省事用 ubuntu + 手装一切
2. 在运行容器里做环境调整
3. 所有镜像统一 latest
4. 为了小体积牺牲可维护性

十一、镜像体积优化的正确姿势总结

可以总结为一句话：

只把“运行时真正需要的东西”放进最终镜像。

优化顺序建议：

1. 基础镜像选择
2. 多阶段构建
3. 层合并与缓存清理
4. .dockerignore

十二、结语

Docker 镜像体积优化，并不是高深技巧，而是：

工程意识 + 正确方法论的自然结果。

当你能稳定地把镜像控制在合理体积范围内时，说明你已经具备了：

• 生产级 Dockerfile 设计能力
• 成熟的工程化思维