文章目录
- Docker 部署 Django（上）：从"这个镜像为什么这么大"到多阶段构建
- 导入语
- 1 ~> 镜像大小对比——从 2GB 到 180MB 的路径
- 2 ~> 版本一：从基础镜像开始——1100MB 起步
- 3 ~> 版本二：换成 `slim` 镜像——450MB
- 4 ~> 版本三：清理 pip 缓存——350MB
- 5 ~> 版本四：多阶段构建——210MB（质变）
- 6 ~> `alpine` 的陷阱——pycryptodome 和其他 musl 不兼容问题
- 思考 && 总结
- 结尾
Docker 部署 Django（上）：从"这个镜像为什么这么大"到多阶段构建
📖文章简介：把 Django 项目 Docker 化的第一步——写 Dockerfile。但大多数人第一次构建出来的镜像都在 800MB-1.2GB 之间。原因很简单：基础镜像选了python:3.11而不是python:3.11-slim，构建依赖和运行依赖混在一起，pip install的缓存文件没清理。上篇聚焦 Dockerfile 的优化——从单阶段构建到多阶段构建、从pip install到--no-cache-dir、从盲目选镜像到理解slim和alpine的 musl libc 兼容性。配有一个 Django 项目从 950MB 瘦身到 180MB 的完整优化过程。
🎬 个人主页：源码骑士
❄专栏传送门：《Android开发基础》《python基础课程》
⭐️热衷从源码视角拆解技术底层原理，将复杂架构讲得通俗易懂
🎬 源码骑士的简介：
5年Android Framework系统开发经验，曾主导多项系统级性能优化专项
技术栈覆盖Android系统全链路（Binder/Handler/AMS/WMS/启动流程）及Java后端全家桶（Spring + MyBatis + Redis + Oracle）
累计产出原创技术文章100+篇，文章以源码拆解为特色，被读者评价为"看一篇胜过啃一周文档"
导入语
第一次把 Django 项目 Docker 化，我写了这样一个 Dockerfile：
FROM python:3.11 WORKDIR /app COPY . . RUN pip install -r requirements.txt CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]构建完后docker images显示 2.1GB。我以为是 Docker 的问题，查了之后才发现python:3.11基础镜像就 1GB——它包含了完整的 Debian 系统加 Python 加编译工具链，全塞进一个镜像。而我的 Django 项目本身只有 8MB。
上篇带你从 2.1GB 的巨型镜像一路优化到 180MB。下篇讲 docker-compose 编排 Django + MySQL + Redis。
1 ~> 镜像大小对比——从 2GB 到 180MB 的路径
| Dockerfile 版本 | 镜像大小 | 改进点 |
|---|---|---|
FROM python:3.11 | 2.1 GB | 基础镜像 |
FROM python:3.11-slim | 450 MB | 换成 slim 版（去掉编译工具） |
+pip --no-cache-dir | 350 MB | 清理缓存 |
| + 多阶段构建 | 210 MB | 分离构建工具和运行依赖 |
+.dockerignore | 180 MB | 排除不必要的文件 |
2 ~> 版本一：从基础镜像开始——1100MB 起步
FROM python:3.11 # 1GB 的基础镜像 WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt # pip 缓存又加几百兆 COPY . . CMD ["gunicorn", "myproject.wsgi:application", "--bind", "0.0.0.0:8000"]问题：python:3.11包含编译器、开发库、deb 包管理、git、curl…… Django 运行起来只需要 Python 解释器和你的代码。你不需要 gcc。
3 ~> 版本二：换成slim镜像——450MB
FROM python:3.11-slim # 只有 120MB 的基础镜像slim= 去掉开发工具的 Debian 精简版。它不装 gcc、不装 git，但仍然保留了apt-get和足够多的系统库能装 Python 包。
4 ~> 版本三：清理 pip 缓存——350MB
RUN pip install --no-cache-dir -r requirements.txt加上--no-cache-dir，pip 不会在镜像里保存下载的 wheel 文件。又省几十 MB。
5 ~> 版本四：多阶段构建——210MB（质变）
# 第一阶段：构建——有编译器 FROM python:3.11-slim AS builder WORKDIR /app RUN apt-get update && apt-get install -y --no-install-recommends gcc RUN pip install --user --no-cache-dir -r requirements.txt # 第二阶段：运行——只有必需的东西 FROM python:3.11-slim WORKDIR /app COPY --from=builder /root/.local /root/.local COPY . . ENV PATH=/root/.local/bin:$PATH CMD ["gunicorn", "myproject.wsgi:application", "--bind", "0.0.0.0:8000"]核心思想：用第一阶段装 gcc、编译 C 扩展（如 mysqlclient），但第二阶段不包含 gcc——只拷贝运行所需的东西。最后镜像里没有编译器。
6 ~>alpine的陷阱——pycryptodome 和其他 musl 不兼容问题
很多教程推荐python:3.11-alpine（只有 50MB）。但它使用 musl libc 而非 glibc。某些 Python 包（尤其是 C 扩展的 wheel 只提供 glibc 版本）无法在 Alpine 上跑：
ImportError: Error loading shared library ld-linux-x86-64.so.2除非你确认所有依赖有 musl 兼容的 wheel，否则先用slim。slim基于 Debian + glibc，兼容性最高。
思考 && 总结
Dockerfile 优化三步骤：
- 用
slim或alpine替代默认镜像——基础大小从 1GB 降到 120MB。 - 多阶段构建——构建阶段装编译器，运行阶段只拷贝结果——镜像里没有 gcc。
.dockerignore排除venv/、__pycache__/、.git/——这些文件不需要在容器里。
结尾
上篇到这里结束。下篇讲docker-compose.yml编排——Django + MySQL + Redis + Nginx 一站式部署。
源码骑士 — 源码级拆解，从底层看透技术
👀关注：跟博主一起从源码视角深耕底层原理
❤️点赞：让优质内容被更多人看见
⭐收藏：核心知识点存好，随用随查
💬评论：分享你的经验或疑问，一起交流
🔄一键四连：别忘了给博主一键四连！
🗡️寄语：Docker 镜像瘦身不是炫技——小镜像 = 快部署 = 小攻击面。
结语：210MB 的生产镜像，部署从 60 秒降到 8 秒。瘦身是值得的。一键四连！
