Python应用容器化需用Docker Compose编排多服务（Flask+PostgreSQL+Redis+Nginx），通过docker-compose.yml管理网络、依赖、配置；采用Alpine多阶段构建轻量化镜像；挂载命名卷保障数据持久化；统一stdout日志；设置资源限制与真实依赖的健康检查。
Python 应用容器化不只是把代码塞进一个镜像里，真正落地时往往需要多个服务协同工作——比如 Flask API + PostgreSQL + Redis + Nginx，还要考虑启动顺序、网络互通、配置隔离、资源限制和日志统一。这些靠单个 docker run 无法解决，必须借助 Docker Compose 编排，并配合合理的设计与调优。
用 Docker Compose 管理多容器依赖关系
Docker Compose 是 Python 多服务项目最实用的编排工具。它用 docker-compose.yml 声明服务拓扑，自动处理网络、卷挂载和依赖顺序。
- 用
depends_on控制启动先后（仅控制容器创建顺序，不保证服务就绪）；真正等 DB 可连需在应用层加重试逻辑，例如用psycopg2.connect(..., connect_timeout=5)配合循环尝试 - 所有服务默认加入同一用户定义网络（
default网络），容器名即 DNS 名：Flask 容器里直接用postgres://db:5432/myapp - 敏感配置通过
environment或.env文件注入，避免硬编码；数据库密码建议用secrets（Docker Swarm 场景）或环境变量 +docker-compose --env-file
Python 应用镜像轻量化与启动优化
基础镜像选 Alpine + 多阶段构建，能显著减小体积并提升安全性；启动脚本要兼顾开发调试与生产健壮性。
- 第一阶段用
python:3.11-slim构建依赖，第二阶段用python:3.11-alpine运行，pip install --no-cache-dir -r requirements.txt减少层数 - 禁用 PIP 缓存、删除
__pycache__和文档（pip install --no-cache-dir --no-deps --no-compile后手动清理） - 入口脚本（
entrypoint.sh）检查$DATABASE_URL是否合法，预热连接池，再执行gunicorn --bind :8000 app:app；失败时输出明确错误并退出，便于健康检查识别
容器间通信与数据持久化设计要点
网络和存储是多容器协作的底层支柱，配置不当会导致连接超时、数据丢失或性能瓶颈。
立即学习“Python免费学习笔记（深入）”；
- PostgreSQL 数据目录必须挂载为命名卷（
volumes: [db_data:/var/lib/postgresql/data]），而非绑定宿主机路径，避免权限冲突和 Windows/macOS 共享文件系统性能问题 - Redis 使用
redis:alpine镜像，默认开启 AOF 持久化，但高写入场景建议关掉（appendonly no）或改用 RDB，避免 I/O 延迟影响 Python 应用响应 - Python 日志统一输出到 stdout/stderr（如用
logging.basicConfig(level=logging.INFO, format="%(message)s")），由 Docker 收集；不要写文件再挂载日志卷，增加复杂度且不利于日志轮转
资源限制与健康检查实战配置
生产环境中不限制资源等于裸奔；没健康检查，Kubernetes 或 Swarm 就无法判断服务是否真“活着”。
- 在
docker-compose.yml中为每个服务设mem_limit: 512m、cpus: "0.5"，防止 Python 内存泄漏拖垮整台宿主机 - 添加
healthcheck：对 Flask 服务，用curl -f http://localhost:8000/health || exit 1，间隔 30s，超时 5s，失败 3 次后标记为 unhealthy - Python 应用内实现
/health接口，检查数据库连接、Redis ping、关键缓存命中率等真实依赖项，不是只返回{"status": "ok"}
