"容器化部署很简单，写个Dockerfile不就完事了？"

这是我在产品经理提出“我们要上Docker”时说的原话。三天后运维同事老张拿着监控数据找我。镜像个数没增加多少，磁盘倒是快满了建立队列排到天涯海角。

"你这个镜像 2.3GB。" 老张指着我写的 Dockerfile，"Python 官方镜像本身就快 1GB 了你还在里面装了 vim、git、build 工具链。这是生产环境，不是你的开发机。"

我低头看了看自己的 Dockerfile，确实有点离谱。但实际来说，我当时并不觉得有什么问题。代码能跑起来服务能正常响应请求，功能测试也通过了。对于一个第一次写 Dockerfile 的人我觉得自己做得还行。

老张显然不这么想。他把我的 Dockerfile 打印出来用红笔圈了五个地方，接下来把纸拍在我桌上。

"。你在镜像里装了 vim 和 git，你是打算在生产环境里改代码吗？第四，你的 requirements.txt 里混了开发依赖。pytest 和 black 在生产环境里跑什么？怎么说呢，第五，你的建立时间八分钟。CI 流水线每次跑都要等八分钟，十个人同时提交代码，排队排到明天。"

五连问，让我哑口无言。我这才意识到，写 Dockerfile 不是“能跑就行”的事。它和写代码一样，有常用方法、有性能考量、有安全要求。

说到第一版，能跑就行的心态

当时的需求是把一个 Python Web 服务容器化。我的思路非常直接：用官方 Python 镜像。把项目代码 COPY 进去，装依赖，跑起来完事。

# 第一版 Dockerfile —— 灾难的开始
FROM python:
# 把整个项目目录 COPY 进去
COPY . /app
WORKDIR /app
# 安装所有依赖，包括开发环境的
RUN pip install -r requirements.txt
# 顺手装了几个 “方便调试” 的工具
RUN apt-get update && apt-get install -y vim git curl wget
# 暴露端口
EXPOSE
# 启动命令
CMD

这东西确实能跑。说到但问题一大堆，

# 建立一下看看镜像大小
docker build -t myapp:v1 .
docker images myapp:v1
# REPOSITORY TAG IMAGE ID SIZE
# myapp v1 a1b2c3d4e5f6 .3GB
# 建立时间
time docker build -t myapp:v1 .
# real 8m37s

.3GB 的镜像。建立一次要八分半钟，老张说我们有三台建立机器，按这个大小跑一轮 CI，磁盘 I/O 就满了。其实，更要命的是推送和拉取——我们的镜像仓库在另一台机器上。推送一个 2.3GB 的镜像要四分多钟；部署时从仓库拉取又是四分多钟。一次部署光传镜像就要八九分钟，产品经理在旁边等着看效果，脸色比我还难看。

从还有一个痛点来看，镜像里包含完整的开发工具链。vim、git、curl 在开发机上很方便，但在生产环境里就是安全隐患。如果有人拿到了容器的 shell，他可以用 vim 看你的代码。用 git 把代码推到自己的仓库，用 curl 探测内网服务。攻击面越大，被入侵的风险越高。按理说，

再看问题诊断。镜像为什么这么大

东西占了这么多空间。

docker history myapp:v1 --no-trunc
# IMAGE CREATED SIZE COMMENT
# a1b2c3d4e5f6 hours ago 0B CMD python manage.py runserver
# b2c3d4e5f6a7 hours ago 0B EXPOSE #
# c3d4e5f6a7b8 hours ago 85MB RUN apt-get install vim git curl wget
# d4e5f6a7b8c9 hours ago 320MB RUN pip install -r requirements.txt
# e5f6a7b8c9d0 hours ago .2GB COPY . /app
# f6a7b8c9d0e1 hours ago 0B WORKDIR /app
# 07b8c9d0e1f2 hours ago 0B FROM python:

• 基础镜像python: 本身接近 1GB。
• COPY 整个目录把 .git、测试数据、文档、虚拟环境全拷进去了一共约 1.2GB。
• 调试工具apt 安装 vim/git/curl/wget 占约 85MB。
• 混入开发依赖: requirements.txt 中包括 pytest、black 等，占约 150MB。 其实，
• Apt 缓存未清理: 再加约40MB。

调整第一步先这方面。.dockerignore 和分离依赖

Pain point： 每次建立都把无关文件带进来导致体积爆炸，而且泄露源码历史。

第一件事，新建 .dockerignore

# .dockerignore 示例
.git
node_modules
__pycache__
*.pyc
pytest_cache
.venv
venv/
docs/
tests/*.md
*.log
.env*
docker-compose*.yml
Dockerfile*
*.dockerignore

光这一步。就把 COPY . /app` 从 1.2GB 降到了不到 50MB。

第二件事，把依赖拆分：

# requirements.txt
Django==4.2.*
gunicorn==21.*
psycopg2-binary==2.9.*
redis==5.*
# requirements-dev.txt
-r requirements.txt
pytest==8.*
pytest-django==4.*
ipython==8.*
black==24.*
flake8==7.*

# 第二版 Dockerfile —— 加入 .dockerignore + 分离依赖
FROM python:slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . /app
EXPOSE 8000
CMD

docker build -t myapp:v2 .
docker images myapp:v2
# REPOSITORY TAG SIZE
# myapp v2 480MB
time docker build -t myapp:v2 .
# real 3m12s

从 2.3GB 降到 480MB 已经让老张点头。话说回来，说到但他仍指出，“基础镜像占太多。而且层缓存策略还有问题——每次改代码都会重新走 pip install 那层。”于是进入下一轮调整，

再看调整接下来，多阶段建立

Pain point： 编译工具链和运行时混杂导致最终镜像臃肿；每次改动都会触发耗时重装依赖。

# 第三版：多阶段建立
## ===== 阶段一：建立 ======
FROM python:slim AS builder
WORKDIR /build
COPY requirements.txt .
RUN pip install --no-cache-dir --user -r requirements.txt
## ===== 阶段二：运行 ======
FROM python:alpine # 极小基础镜像
WORKDIR /app
# 从 builder 阶段拷贝已安装好的包
COPY --from=builder /root/.local /root/.local
COPY . /app
ENV PATH=/root/.local/bin:$PATH \
PYTHONPATH=/app
EXPOSE 8000
CMD

docker build -t myapp:v3 .
docker images myapp:v3
# REPOSITORY TAG SIZE
# myapp v3 95MB
time docker build -t myapp:v3 .
# real 1m28s

Apline 虽小。但部分 Python 包需要编译，所以我们在 builder 阶段额外安装 gcc 与 postgresql-dev，接下来只把编译产物复制到运行阶段。对了别忘记设置时区，否则日志会出现 UTC 偏差：

RUN apk add --no-cache tzdata \
&& cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \
&& echo "Asia/Shanghai"> /etc/timezone \
&& apk del tzdata # 清理临时包以保持体积小巧

至于调整然后。层缓存精细化 & BuildKit 缓存挂载

Pain point： 每改一领域务代码，都导致 pip install 重跑，即使依赖未变，也浪费数十秒甚至几分钟。

• 指令顺序原则： 先装程序依赖 → 再装 Python 包 → 最终 COPY 源码，这样源码改动只影响最终一层缓存。
• Simplified Dockerfile 示例：

FROM python:alpine AS base
## 程序依赖
RUN apk add --no-cache libpq5
## Python 包
COPY requirements.txt .
RUN --mount=type=cache。target=/root/.cache/pip \
pip install --no-cache-dir -r requirements.txt
## 应用源码
COPY . /app
WORKDIR /app
CMD

A 使用 BuildKit 时只需在 CI 环境里打开它：

export DOCKER_BUILDKIT=1
docker build -t myapp:v4 .

If dependencies haven't changed,subsequent builds drop to ~22 seconds.

健康检查这方面，让容器自报状态 ✅

Pain point：“容器卡住却不知道”。使用 Docker 原生 HEALTHCHECK` 提供可观测性。

HEALTHCHECK --interval=30s --timeout=5s \
--start-period=10s --retries=3 \
CMD curl -f http://localhost:8000/health/ || exit 1

d​ocker‑compose 中结合健康检查防止服务提前启动 🚀

version: '3.9'
services:
说到web，build: .
ports的观点是，- "8000:8000"
dependson:
再看db，condition: servicehealthy # 等待 DB 健康后再启动
再看redis，condition: service_healthy
healthcheck:
再看test，interval: 30s
timeout: 5s
retries:  3 

至于db，image: postgres:alpine environment: POSTGRESDB: mydb POSTGRESPASSWORD:${DBPASSWORD} healthcheck: 说到test，interval:10s timeout 5s retries 5

PASSWORD=mySuperSecretPassword123
ENV REDISPASSWORD=redispasswordhere
ENV SECRET_KEY=django-insecure-xxxxxxxxxxxx
``

为什么不能这样做？
- docker inspect 能直接看到所有 ENV 内容；任何有权限读取仓库或节点的人都能获取。- 镜像一旦推送，即使后来删除，也无法保证已经被拉取者彻底清除。- 离职员工或误操作导致公开仓库，都可能造成 供应链泄露。