10.1 生产环境与服务器配置

10.1 生产环境与服务器配置

本节摘要：从开发到生产，配置要完成一次系统性翻转：关调试、密钥出库、换数据库、收集静态、接入应用服务器与反向代理。本节给出逐项清单并解释每项背后的风险，然后搭建 Gunicorn 加 Nginx 的标准拓扑。配置翻转不是仪式，是把开发期的"便利"逐个换成生产期的"安全"。

配置翻转清单

逐项过，每项都有明确理由：

# 生产配置（节选）
DEBUG = False                    # 调试页暴露源码与配置，绝不带上生产
ALLOWED_HOSTS = ["moji.example.com"]   # 关闭调试后必须显式声明域名
SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]   # 密钥来自环境变量
SECURE_SSL_REDIRECT = True       # 全站跳 HTTPS
SESSION_COOKIE_SECURE = True     # 会话 Cookie 仅走 HTTPS
CSRF_COOKIE_SECURE = True
​

DEBUG 是最大的开关。 它为 True 时报错页会展示配置项、已装应用甚至源码片段，等于把钥匙插在门上；它还为 True 时静态文件由应用服务。关掉它就必须同时做两件事：ALLOWED_HOSTS 显式列出域名（否则所有请求 400），静态文件改为收集后由 Nginx 服务。

SECRET_KEY 出库。它参与会话签名与密码重置令牌，泄漏等于会话可伪造。做法是环境变量注入，进程管理器或托管平台的密钥管理都行，就是不能再躺在代码仓库里——第 1 章埋的那颗雷在此拆除。

数据库换 PostgreSQL。开发常用的 SQLite 单文件并发写入能力有限，生产并发场景下锁等待会放大延迟。切换只改配置里的引擎与连接参数，ORM 屏蔽了方言差异——第 2、3 章的代码一行不动，这是抽象层的真实回报。换库后第一次迁移建表，开发库的数据用导出导入工具搬迁。

Gunicorn：应用服务器

开发服务器单线程、自动重载，生产环境的对位替代是 WSGI 应用服务器。Gunicorn 管理一组 worker 进程，每个 worker 加载一份 Django 应用处理请求：

# 典型启动方式（进程管理器托管，崩溃自动拉起）
gunicorn moji_project.wsgi:application \
    --workers 3 --bind 127.0.0.1:8000
​

worker 数的经验公式：CPU 核数乘二加一。Gunicorn 只监听本机回环地址——它不需要也不应该直接面对公网，面向公网的是下一层。

Nginx：反向代理

Nginx 在 Gunicorn 前面承担三件事：TLS 终结（HTTPS 证书挂在它这）、静态文件直接服务（不劳应用进程）、把动态请求转发给 Gunicorn 并缓冲慢客户端：

server {
    listen 443 ssl;
    server_name moji.example.com;

    location /static/ {
        alias /srv/moji/staticfiles/;    # 收集命令的产物目录
    }
    location /media/ {
        alias /srv/moji/media/;          # 用户上传 第5章的媒体线
    }
    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
​

静态收集一条命令（第 5 章的伏笔在此兑现）：

python manage.py collectstatic --noinput
​

生产拓扑全景

分工总结成一句：Nginx 会说互联网的语言（TLS、缓冲、静态），Gunicorn 会说 Python 的语言（进程、WSGI 协议），中间用本地回环握手。少任何一层都能跑，但少 Nginx 应用进程要自己扛 TLS 与慢客户端，少 Gunicorn 就得让 Nginx 直连一个单进程应用——各有各的痛。

进程管理

Gunicorn 本身也可能倒，进程管理器负责把它扶起来、开机自启、崩溃重启。配置要点三个：工作目录指向项目、环境变量注入密钥与数据库连接、日志路径固定便于排查。体系内用进程管理器（如 systemd 单元）或容器编排均可，原则一致：应用的生死不由人的终端会话决定。

⚠️ 首发排错第一现场：改完配置 502。九成是 Gunicorn 没起来（密钥环境变量缺失、依赖没装全、worker 秒退），先看应用服务器日志再看 Nginx 日志，顺序别反。

配置漂移与基础设施即代码

生产环境稳定运行后，一个隐性威胁会慢慢生长：配置漂移。半年里为了排查各种问题，有人在服务器上临时改过一处参数，有人手工装过一个包，这些变更没有记录、不在版本库里，服务器成了一台只有它自己知道自己状态的机器——直到某天磁盘损坏需要重建，才发现无人能复现当前环境。对付漂移的思路是把环境当代码管理：依赖清单锁版本是第一步，服务器上的安装与配置步骤写成可重复执行的脚本是第二步，团队规模再大可引入配置管理工具。检验标准很简单：随机挑一台服务器，问能否在一台全新机器上用库里的东西把它复刻出来，答不上来就说明漂移已经发生。墨迹博客吃过一次亏——一次磁盘故障后的重建花了一整天，其中大半时间在回忆当时改过什么。此后配置脚本成了和代码同级的受管资产。

本节要点回顾

• 配置翻转四件套：DEBUG 关、HOSTS 声明、密钥出库、静态收集。
• 换 PostgreSQL 只改配置，ORM 屏蔽方言，代码零改动。
• Gunicorn 管进程、Nginx 管边界，回环地址内部握手。
• 进程管理器保证应用常驻，502 先查应用日志。

服务器配好，下一章把"发布一次"固化成可重复的流程，并准备随时回滚。