Django/docs/2.2.x/howto/deployment/checklist

部署清单

互联网是一个充满敌意的环境。 在部署 Django 项目之前，您应该花一些时间检查您的设置，并考虑到安全性、性能和操作。

Django 包括许多 安全特性 。 有些是内置的并且始终启用。 其他是可选的，因为它们并不总是合适的，或者因为它们不便于开发。 例如，强制HTTPS可能并不适合所有网站，对于本地开发是不切实际的。

性能优化是另一类与便利性的权衡。 例如，缓存在生产中很有用，而在本地开发中则不然。 错误报告需求也大不相同。

以下清单包括以下配置：

• 必须正确地设置 Django 以提供预期的安全级别；
• 期望在每个环境中都是不同的；
• 启用可选的安全功能；
• 启用性能优化；
• 提供错误报告功能。

其中许多设置是敏感的，应视为机密。 如果您要发布项目的源代码，通常的做法是发布合适的开发设置，并使用私有设置模块进行生产。

运行 manage.py check --deploy

下面描述的一些检查可以使用 check --deploy 选项自动进行。 请务必按照选项文档中的说明针对您的生产设置文件运行它。

关键配置

:setting:`SECRET_KEY`

密钥必须是一个很大的随机值，并且必须保密。

确保生产中使用的密钥未在其他任何地方使用，并避免将其提交给源代码控制。 这减少了攻击者可以从中获取密钥的向量的数量。

与其在设置模块中对密钥进行硬编码，不如考虑从环境变量中加载它：

import os
SECRET_KEY = os.environ['SECRET_KEY']

Copy

或从文件：

with open('/etc/secret_key.txt') as f:
    SECRET_KEY = f.read().strip()

Copy

:setting:`DEBUG`

您绝不能在生产中启用调试。

你肯定正在开发你的项目 ：设置：`调试=真 ` ，因为这可以启用浏览器中的完整追溯等方便的功能。

不过，对于生产环境来说，这真是一个坏主意，因为这会泄露很多超出预期的信息：代码摘要，本地变量，配置项，使用的库，等等。

特定于环境的配置

:setting:`ALLOWED_HOSTS`

什么时候 ：设置：`调试=假 ` , 如果没有合适的值，Django 根本无法工作 ：设置：`ALLOWED_HOSTS` .

需要此设置来保护您的站点免受某些 CSRF 攻击。 如果您使用通配符，您必须自己验证 Host HTTP 标头，否则确保您不易受到此类攻击。

您还应该配置位于 Django 前面的 Web 服务器来验证主机。 它应该以静态错误页面响应或忽略对不正确主机的请求，而不是将请求转发给 Django。 通过这种方式，您将避免 Django 日志（或电子邮件，如果您以这种方式配置错误报告）中的虚假错误。 例如，在 nginx 上，您可能会设置一个默认服务器以在无法识别的主机上返回“444 No Response”：

server {
    listen 80 default_server;
    return 444;
}

Copy

:setting:`CACHES`

如果您使用缓存，则开发和生产中的连接参数可能不同。 Django 默认为每个进程 本地内存缓存 这可能是不可取的。

缓存服务器通常具有弱身份验证。 确保它们只接受来自您的应用程序服务器的连接。

如果您使用的是 Memcached，请考虑使用 缓存会话 来提高性能。

:setting:`DATABASES`

生产环境与开发环境的数据库连接参数可能是不同的。

数据库密码非常敏感。 你应该像 :setting:`SECRET_KEY` 一样保护它们。

为了最大限度的安全，确保数据库只为来自你应用的连接提供服务。

如果您尚未为数据库设置备份，请立即进行！

:setting:`EMAIL_BACKEND` 及相关设置

如果你的站点发送邮件，以下值需要被正确地配置。

默认情况下，Django 从 webmaster@localhost 和 root@localhost 发送电子邮件。 但是，某些邮件提供商拒绝来自这些地址的电子邮件。 要使用不同的发件人地址，请修改 :setting:`DEFAULT_FROM_EMAIL` 和 :setting:`SERVER_EMAIL` 设置。

:setting:`STATIC_ROOT` 和 :setting:`STATIC_URL`

静态文件由开发服务器自动提供。 在生产中，您必须定义一个 :setting:`STATIC_ROOT` 目录，其中 :djadmin:`collectstatic` 将复制它们。

看管理静态文件（例如 图片、JavaScript、CSS） 想要查询更多的信息。

:setting:`MEDIA_ROOT` 和 :setting:`MEDIA_URL`

媒体文件由您的用户上传。 他们不受信任！ 确保您的 Web 服务器从不尝试解释它们。 例如，如果用户上传 .php 文件，Web 服务器不应执行它。

现在是检查这些文件的备份策略的好时机。

:setting:`FILE_UPLOAD_PERMISSIONS`

使用默认文件上传设置，小于 :setting:`FILE_UPLOAD_MAX_MEMORY_SIZE` 的文件可能以不同于 :setting:`FILE_UPLOAD_PERMISSIONS` 中所述的较大文件的模式存储。

设置 :setting:`FILE_UPLOAD_PERMISSIONS` 确保所有文件都以相同的权限上传。

HTTPS

任何允许用户登录的网站都应强制执行站点范围的 HTTPS，以避免以明文形式传输访问令牌。 在 Django 中，访问令牌包括登录名/密码、会话 cookie 和密码重置令牌。 （如果您通过电子邮件发送密码重置令牌，您将无能为力。）

保护用户帐户或管理员等敏感区域是不够的，因为 HTTP 和 HTTPS 使用相同的会话 cookie。 您的 Web 服务器必须将所有 HTTP 流量重定向到 HTTPS，并且只将 HTTPS 请求传输到 Django。

设置 HTTPS 后，请启用以下设置。

:setting:`CSRF_COOKIE_SECURE`

将此设置为 True 以避免意外通过 HTTP 传输 CSRF cookie。

:setting:`SESSION_COOKIE_SECURE`

将此设置为 True 以避免意外通过 HTTP 传输会话 cookie。

性能优化

环境 ：设置：`调试=假 ` 禁用仅在开发中有用的几个功能。 此外，您可以调整以下设置。

:setting:`CONN_MAX_AGE`

当连接到数据库占请求处理时间的很大一部分时，启用 持久数据库连接 可以导致很好的加速。

这对带宽有限的虚拟主机帮助极大。

:setting:`TEMPLATES`

启用缓存模板加载器通常会显着提高性能，因为它避免了每次需要渲染时都编译每个模板。 有关更多信息，请参阅 模板加载器文档 。

发送错误

当您将代码投入生产时，它有望变得健壮，但您不能排除意外错误。 幸运的是，Django 可以捕获错误并相应地通知您。

:setting:`LOGGING`

在将网站放入生产环境前，检查 logging 配置项。在你收到某些信息后，查看其是否按预期运行。

有关日志记录的详细信息，请参阅 日志记录 。

:setting:`ADMINS` 和 :setting:`MANAGERS`

:setting:`ADMINS` 将通过电子邮件通知 500 个错误。

:setting:`MANAGERS` 将收到 404 错误通知。 :setting:`IGNORABLE_404_URLS` 可以帮助过滤掉虚假报告。

有关通过电子邮件报告错误的详细信息，请参阅 错误报告 。

通过电子邮件报告错误不能很好地扩展

在您的收件箱被报告淹没之前，请考虑使用错误监控系统，例如 Sentry。 Sentry 还可以聚合日志。

自定义默认错误视图

Django 包括几个 HTTP 错误代码的默认视图和模板。 您可能希望通过在根模板目录中创建以下模板来覆盖默认模板：404.html、500.html、403.html 和 400.html。 使用这些模板的 默认错误视图 应该足以满足 99% of Web 应用程序的需求，但您也可以 自定义它们 。