生产环境Django应用Docker化部署最佳实践及方案咨询

生产环境能否直接运行manage.py启动服务 #

绝对不要在生产环境直接使用manage.py runserver提供服务。
Django自带的runserver是仅面向开发调试场景设计的工具，默认单线程运行，没有做高并发适配、安全加固，性能上限极低，Django官方也明确禁止在生产场景使用该命令。
在Docker中部署的标准方案是：Django应用容器内仅运行gunicorn进程，遵循单容器单主进程的设计原则，不要将nginx和gunicorn、Django打包到同一个容器内，否则会提升扩缩容、日志排查、版本迭代的复杂度。

多套Django应用的gunicorn、nginx部署方案 #

gunicorn部署规则 #

• 必须为每套Django应用单独配置专属的gunicorn，不要多应用共享同一个gunicorn实例。不同Django应用的依赖版本、运行参数（worker数量、超时阈值、启动钩子）、代码版本完全独立，混布会出现依赖冲突、资源争抢、单应用故障影响全量业务的问题。
• 可以将gunicorn配置直接打包到对应Django应用的镜像中，容器启动命令直接指定gunicorn启动即可，参考启动命令：
  gunicorn --workers=4 --bind=0.0.0.0:8000 your_project.wsgi:application

nginx部署规则 #

• 建议做独立的公共nginx部署，不要给每个Django应用单独配nginx。公共nginx统一作为所有Django应用的反向代理入口，仅需要维护一套SSL证书、限流策略、静态资源缓存规则，大幅降低运维成本。
• Django的静态资源不要交由gunicorn处理，生产环境提前执行python manage.py collectstatic汇总静态资源后，直接交给公共nginx代理返回即可，性能远高于应用进程处理静态资源的方案。

内容的提问来源于stack exchange，提问作者Gaurav Piyush