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 的路径

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 优化三步骤：

1. 用slim或alpine替代默认镜像——基础大小从 1GB 降到 120MB。
2. 多阶段构建——构建阶段装编译器，运行阶段只拷贝结果——镜像里没有 gcc。
3. .dockerignore排除venv/、__pycache__/、.git/——这些文件不需要在容器里。

结尾

上篇到这里结束。下篇讲docker-compose.yml编排——Django + MySQL + Redis + Nginx 一站式部署。

源码骑士 — 源码级拆解，从底层看透技术

👀关注：跟博主一起从源码视角深耕底层原理

❤️点赞：让优质内容被更多人看见

⭐收藏：核心知识点存好，随用随查

💬评论：分享你的经验或疑问，一起交流

🔄一键四连：别忘了给博主一键四连！

🗡️寄语：Docker 镜像瘦身不是炫技——小镜像 = 快部署 = 小攻击面。

结语：210MB 的生产镜像，部署从 60 秒降到 8 秒。瘦身是值得的。一键四连！