008、容器化部署：Docker与Python应用打包

一、从一次深夜告警说起

上周三凌晨两点，手机突然狂震。线上某个Python数据分析服务CPU飙到98%，响应时间从200ms直接跳到15秒。爬起来连上服务器，top一看，某个子进程僵死了。习惯性地执行pip list想看看依赖版本，结果发现测试环境的pandas版本居然比生产环境新了两个小版本------问题就出在这儿，某个API在新版里行为变了。

这种事经历过几次后，我彻底放弃了"在服务器上直接pip install"的部署方式。今天要聊的容器化，就是解决这类环境一致性问题的银弹。

二、为什么Python项目特别需要Docker？

Python的灵活有时是双刃剑。全局的site-packages、PYTHONPATH的魔法、virtualenv与系统Python的纠缠......这些在开发机上可能只是小麻烦，上了生产就是定时炸弹。

记得有次调试一个numpy的段错误，最后发现是因为某台机器上同时存在Intel MKL和OpenBLAS两个加速库，运行时随机加载其中一个。这种问题用Docker镜像固化环境，就能彻底避免。

三、手把手打包一个Flask应用

先看一个最简单的例子，从Dockerfile开始：

dockerfile 复制代码

# 第一行就踩过坑：别用latest标签，否则今天能跑明天可能就崩了
FROM python:3.9-slim

# 系统依赖往往被忽略，比如某些Python包需要gcc编译
RUN apt-get update && apt-get install -y \
    gcc \
    libpq-dev \
    && rm -rf /var/lib/apt/lists/*  # 清理缓存，减小镜像体积

# 工作目录设成/app是行业惯例
WORKDIR /app

# 先单独拷贝requirements，利用Docker缓存层
# 这样改代码时不需要重新下载依赖
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt \
    && pip list  # 这里打印一下，方便后续排查版本

# 再拷贝应用代码
COPY . .

# 暴露端口要和应用里的一致
EXPOSE 5000

# 这里有个细节：用gunicorn代替python直接启动
# 生产环境别用Flask自带的服务器
CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"]

这个文件有几个关键点：

slim镜像比完整版小很多，但保留了包管理工具
系统依赖单独安装，避免污染Python层
依赖安装和代码拷贝分开，充分利用缓存

四、那些容易踩的坑

坑1：镜像体积膨胀

早期我做镜像时，一个简单的Web应用居然做到1.8GB。后来发现是没清理apt缓存，pip也没用--no-cache-dir。现在我的习惯是多阶段构建：

dockerfile 复制代码

# 构建阶段
FROM python:3.9 as builder
COPY requirements.txt .
RUN pip wheel --no-cache-dir --wheel-dir /wheels -r requirements.txt

# 运行阶段
FROM python:3.9-slim
COPY --from=builder /wheels /wheels
RUN pip install --no-index --find-links=/wheels -r requirements.txt

这样最终镜像里只有运行时依赖，没有编译工具链。

坑2：时区问题

容器默认是UTC时间，国内应用经常出问题。我一般在Dockerfile里加一句：

dockerfile 复制代码

ENV TZ=Asia/Shanghai
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

坑3：日志不输出

Docker默认捕获容器输出，但Python的日志缓冲会导致日志不及时。解决方案：

python 复制代码

# 在应用初始化时设置
import sys
sys.stdout.reconfigure(line_buffering=True)  # Python 3.7+

五、生产环境的最佳实践

1. 用户权限

别用root运行应用，这是安全基本要求：

dockerfile 复制代码

RUN groupadd -r appuser && useradd -r -g appuser appuser
USER appuser

2. 健康检查

Kubernetes等平台依赖这个判断容器状态：

dockerfile 复制代码

HEALTHCHECK --interval=30s --timeout=3s \
  CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:5000/health')"

3. 环境配置

敏感信息通过环境变量注入，别写死在镜像里：

dockerfile 复制代码

ENV FLASK_ENV=production

启动时传入：

bash 复制代码

docker run -e DATABASE_URL=postgresql://... your-image

六、本地开发与调试技巧

1. 挂载代码实时开发

bash 复制代码

docker run -v $(pwd):/app -p 5000:5000 your-image

这样本地改代码，容器内立即生效。

2. 进入容器调试

bash 复制代码

docker exec -it container_id bash
python -m pdb app.py  # 或者直接ipdb

3. 查看镜像层

bash 复制代码

docker history your-image --no-trunc

这个命令能看出每层的大小，方便优化。

七、个人经验之谈

容器化不是万能药，但确实是Python部署的"基础设施"。我团队现在所有项目都容器化，带来的最大好处不是技术上的，而是流程上的------新同事第一天就能docker-compose up拉起完整环境，再也不用"在我机器上是好的"这种对话。

几个建议：

镜像仓库一定要做漏洞扫描，我们吃过redis镜像带挖矿程序的亏
docker-compose适合开发，生产上K8s是趋势但别过早引入
日志统一收集到ELK或类似系统，别留在容器里
镜像标签用Git commit hash，别用latest

最后说个真事：有次紧急回滚，因为用了容器，直接拉取旧版本镜像重启，3分钟完成。传统方式可能要半小时。这种时刻，你会觉得之前折腾Docker的所有时间都值了。