008、容器化部署：Docker与Python应用打包
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开始：
# 第一行就踩过坑：别用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。现在我的习惯是多阶段构建：
# 构建阶段 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里加一句：
ENV TZ=Asia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone坑3：日志不输出
Docker默认捕获容器输出，但Python的日志缓冲会导致日志不及时。解决方案：
# 在应用初始化时设置importsys sys.stdout.reconfigure(line_buffering=True)# Python 3.7+五、生产环境的最佳实践
1. 用户权限
别用root运行应用，这是安全基本要求：
RUN groupadd -r appuser && useradd -r -g appuser appuser USER appuser2. 健康检查
Kubernetes等平台依赖这个判断容器状态：
HEALTHCHECK --interval=30s --timeout=3s \ CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:5000/health')"3. 环境配置
敏感信息通过环境变量注入，别写死在镜像里：
ENV FLASK_ENV=production启动时传入：
dockerrun-eDATABASE_URL=postgresql://... your-image六、本地开发与调试技巧
1. 挂载代码实时开发
dockerrun-v$(pwd):/app-p5000:5000 your-image这样本地改代码，容器内立即生效。
2. 进入容器调试
dockerexec-itcontainer_idbashpython-mpdb app.py# 或者直接ipdb3. 查看镜像层
dockerhistoryyour-image --no-trunc这个命令能看出每层的大小，方便优化。
七、个人经验之谈
容器化不是万能药，但确实是Python部署的“基础设施”。我团队现在所有项目都容器化，带来的最大好处不是技术上的，而是流程上的——新同事第一天就能docker-compose up拉起完整环境，再也不用“在我机器上是好的”这种对话。
几个建议：
- 镜像仓库一定要做漏洞扫描，我们吃过
redis镜像带挖矿程序的亏 docker-compose适合开发，生产上K8s是趋势但别过早引入- 日志统一收集到ELK或类似系统，别留在容器里
- 镜像标签用Git commit hash，别用
latest
最后说个真事：有次紧急回滚，因为用了容器，直接拉取旧版本镜像重启，3分钟完成。传统方式可能要半小时。这种时刻，你会觉得之前折腾Docker的所有时间都值了。