docker-compose.yml中depends_on仅控制启动顺序而非服务就绪,需配合healthcheck与service_healthy或应用层重试;依赖应构建时安装;源码用volumes挂载但排除venv;环境变量需显式透传或容器内加载;gunicorn worker数应据内存限制调整;日志须输出到stdout/stderr。

docker-compose.yml 里 services 下的 depends_on 不等于“等它启动完”
它只控制容器启动顺序,不检查服务是否真正就绪。比如 depends_on 写了 db,但 postgres 容器可能刚跑起来、还在初始化,你的 Python 应用就去连,结果抛出 ConnectionRefusedError 或超时。
- 真正要等数据库就绪,得在应用侧加重试逻辑(比如用
tenacity库轮询psycopg2.connect)或用健康检查 +healthcheck配合condition: service_healthy -
depends_on的condition: service_started(默认值)只是看容器是否running,不是ready - Docker Compose v2.15+ 支持
service_healthy,但前提是目标服务定义了healthcheck,否则会报错
Python 应用镜像别用 pip install -r requirements.txt 在运行时装依赖
每次 docker-compose up 都重装,既慢又破坏镜像分层缓存。更糟的是,如果网络波动或 PyPI 暂不可用,构建直接失败。
- 把
requirements.txtCOPY 到镜像里,再 RUNpip install -r requirements.txt,确保依赖在构建阶段固化 - 开发时想快速改代码?用
volumes挂载源码目录,但别挂载venv或__pycache__,否则可能和容器内 Python 解释器冲突 - 避免在 Dockerfile 里写
RUN pip install flask gunicorn psycopg2-binary这种硬编码——版本不一致、难审计、无法复现
环境变量从 .env 文件漏进容器,但 Python 读不到
docker-compose.yml 支持 env_file,但那只是把变量注入容器环境;Python 默认不自动加载 .env 文件,os.getenv("DB_URL") 为空不是 Docker 的锅,是应用没处理。
- 要么在 Python 启动前用
env_file+environment显式透传关键变量,比如:environment: - DATABASE_URL=${DATABASE_URL} - 要么在 Python 里用
python-decouple或dotenv加载.env——但注意:这个.env是容器内的文件,得 COPY 进去,不能靠宿主机挂载(否则 dev/prod 环境混了) -
.env文件里的变量不会自动覆盖environment中已声明的值,后者优先级更高
gunicorn 和 Flask 的 workers 数设成 CPU 核数 × 2 是错的
这是 Web 服务器通用建议,但对容器化 Python 应用不适用。Kubernetes 或 Docker 的资源限制(mem_limit, cpus)是硬边界,而 gunicorn 的 worker 进程吃内存很猛,设多反而触发 OOM Kill。
- 先用
docker stats观察单个实例实际内存占用,再按容器mem_limit反推合理 worker 数,通常 1–4 个足够 - 用
--preload参数让 gunicorn 预加载应用,避免每个 worker 单独 import,减少内存重复占用 - 别在
command里写死gunicorn --workers 4,改成环境变量驱动,比如command: gunicorn --workers ${WEB_CONCURRENCY:-2},方便不同环境调整
最常被跳过的其实是日志——容器里 stdout/stderr 必须干净输出,别 redirect 到文件,否则 docker-compose logs 就抓不到;还有健康检查路径,别写成 /healthz 却在 Flask 里没注册路由,一查就失败。
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!











