Чек-лист для развертывания проекта¶
Интернет — враждебная среда. Перед развертыванием проекта Django, вы должны потратить некоторое время на проверку настроек, принимая во внимание безопасность и производительность»
Django включает в себя множество функций безопасности. Некоторые из них встроены и всегда включены. Другие являются необязательными, поскольку они не всегда подходят или неудобны для разработки. Например, принудительное использование HTTPS может не подходить для всех веб-сайтов, и это непрактично для локальной разработки.
Оптимизация производительности — это еще одна причина для компромиссов. Например, кэширование полезно в продакшене, но усложняет работупри работе в локальной среде. Потребности в отчетах об ошибках также сильно различаются.
Следующий чек-лист включает в себя настройки, которые:
необходимо правильно указать Django, чтобы обеспечить ожидаемый уровень безопасности;
ожидается, что они будут разными в каждой среде;
включают дополнительные опции безопаносности;
активируют оптимизацию производительности;
обеспечивают логирование ошибок.
Многие из этих настроек являются конфиденциальными.»Если вы публикуете исходный код своего проекта, общепринятой практикой является публикация подходящих настроек для разработки и использование закрытого модуля настроек для производства.
Запустите manage.py check --deploy¶
Некоторые из проверок, описанных ниже, можно автоматизировать с помощью параметра check --deploy. Обязательно запустите его для файла настроек производства, как описано в документации к параметру.
Откажитесь от manage.py runserver¶
Команда runserver не предназначена для использования в продакшене. Обязательно пользуйтесь тем или иным WSGI или ASGI сервером. Некоторые распространенные серверы см. в Серверы WSGI или Серверы ASGI.
Критические настройки¶
SECRET_KEY¶
Секретный ключ должен представлять собой большое случайное значение и должен храниться в секрете.
Убедитесь, что ключ, используемый в продакшене, не используется где-либо еще, и избегайте передачи его в систему контроля версий.
Вместо того, чтобы хардкодить секретный ключ в модуле настроек, рассмотрите возможность его загрузки из переменной среды:
import os
SECRET_KEY = os.environ["SECRET_KEY"]
или из файла:
with open("/etc/secret_key.txt") as f:
SECRET_KEY = f.read().strip()
При ротации секретных ключей можно использовать SECRET_KEY_FALLBACKS:
import os
SECRET_KEY = os.environ["CURRENT_SECRET_KEY"]
SECRET_KEY_FALLBACKS = [
os.environ["OLD_SECRET_KEY"],
]
Убедитесь, что старые секретные ключи удалены из SECRET_KEY_FALLBACKS своевременно.
DEBUG¶
Никогда не включайте отладку в продакшене.
Вы, скорее всего, разрабатываете свой проект с DEBUG = True, поскольку это включает удобные функции, такие как полная трассировка, которую вы можете видеть вашем браузере в случае возникновения ошибки.
Для продакшена, однако, это действительно плохая идея, потому что это утечка большого количества информации о вашем проекте: фрагменты вашего исходного кода, локальные переменные, настройки, используемые библиотеки и т. д.
Настройки, зависящие от среды¶
ALLOWED_HOSTS¶
Когда DEBUG = False, Django вообще не работает без подходящего значения для ALLOWED_HOSTS.
Эта настройка необходима для защиты вашего сайта от некоторых атак CSRF. Если вы используете *, вы должны выполнить собственную проверку заголовка Host HTTP или иным образом убедиться, что вы не уязвимы для этой категории атак.
Вы также должны настроить веб-сервер, который находится перед Django, для проверки хоста. Он должен отвечать статической страницей ошибки или игнорировать запросы на неверные хосты вместо пересылки запроса в Django. Таким образом вы избежите ложных ошибок в своих журналах Django (или в электронных письмах, если у вас есть настроенные таким образом отчеты об ошибках). Например, в nginx вы можете настроить сервер по умолчанию для возврата «444 No Response» на нераспознанном хосте:
server {
listen 80 default_server;
return 444;
}
CACHES¶
Если вы используете кэш, параметры подключения могут отличаться в среде разработки и в продакшене. Django по умолчанию использует кэширование памяти local- для каждого процесса, что может быть нежелательным.
Кэш-серверы часто имеют слабую аутентификацию. Убедитесь, что они принимают только подключения от ваших серверов приложений.
DATABASES¶
Параметры подключения к базе данных, вероятно, различаются при разработке и в продакшене.
Пароли баз данных очень чувствительны. Вы должны защищать их точно так же, как SECRET_KEY.
Для максимальной безопасности убедитесь, что серверы баз данных принимают соединения только от ваших серверов приложений.
Если вы еще не настроили резервное копирование своей базы данных, сделайте это прямо сейчас!
STATIC_ROOT and STATIC_URL¶
Статические файлы автоматически обслуживаются сервером разработки. В производстве необходимо определить каталог STATIC_ROOT, куда collectstatic будет их копировать.
Более подробную информацию смотрите в Как управлять статическими файлами (изображениями, скриптами JS, CSS и т.д.).
MEDIA_ROOT и MEDIA_URL¶
Медиафайлы загружаются вашими пользователями. Они ненадежны! Убедитесь, что ваш веб-сервер никогда не пытается их интерпретировать. Например, если пользователь загружает файл .php, веб-сервер не должен его выполнять»
Сейчас самое время проверить вашу стратегию резервного копирования этих файлов.
HTTPS¶
Любой веб-сайт, позволяющий пользователям входить в систему, должен применять HTTPS на всем сайте, чтобы избегать передачи токенов доступа в открытом виде. В Django токены доступа включают логин/пароль, cookie-файл сеанса и токены сброса пароля. (Вы мало что можете сделать для защиты токенов сброса пароля, если отправляете их по электронной почте.)
Защита конфиденциальных областей, таких как учетная запись пользователя или администратора, не является достаточной, поскольку для HTTP и HTTPS используется один и тот же сеансовый cookie. Ваш веб-сервер должен перенаправлять весь HTTP-трафик на HTTPS и передавать только HTTPS-запросы в Django.
После настройки HTTPS включите следующие параметры.
Оптимизация производительности¶
Настройка DEBUG = False отключает несколько функций, которые полезны только при разработке. Кроме того, вы можете настроить следующие параметры.
Сессии¶
Рассмотрите возможность использования кэшированных сессий для улучшения производительности.
Если вы используете сеансы, информация о которых хранится в базе данных, регулярно очищайте старые сеансы, чтобы избежать сохранения ненужных данных.
CONN_MAX_AGE¶
Включение постоянных подключений к базе данных может привести к значительному ускорению при подключении к базе данных составляет значительную часть времени обработки запроса.
Это очень помогает на виртуальных хостах с ограниченной производительностью сети.»
TEMPLATES¶
Включение загрузчика кэшированных шаблонов часто значительно повышает производительность, поскольку позволяет избежать компиляции каждого шаблона каждый раз, когда его нужно отрисовать. Когда DEBUG = False, загрузчик кэшированных шаблонов включается автоматически. См. django.template.loaders.cached.Loader для получения дополнительной информации.
Сообщения об ошибке¶
К тому времени, как вы запустите свой код в продакшен, он, как мы надеемся, будет надежным, но вы не сможете исключить непредвиденные ошибки. К счастью, Django может перехватывать ошибки и соответствующим образом уведомлять вас.
LOGGING¶
Перед запуском веб-сайта в продакшен проверьте конфигурацию ведения журнала, и убедитесь, что он работает так, как и ожидалось, как только вы получите трафик.
Подробную информацию о ведении журнала см. в Логгирование.
ADMINS и MANAGERS¶
ADMINS будут уведомлены по электронной почте о 500 ошибках.
MANAGERS будут уведомлены об ошибках 404. IGNORABLE_404_URLS может помочь отфильтровать поддельные отчеты.
Подробную информацию об отправке сообщений об ошибках по электронной почте см. в Как управлять сообщениями об ошибках.
Сообщения об ошибках по электронной почте не очень хорошо масштабируются
Рассмотрите возможность использования системы мониторинга ошибок, такой как Sentry, прежде чем ваш почтовый ящик заполнится отчетами. Sentry также может объединять журналы.
Настройте отображение ошибок по умолчанию¶
Django включает представления и шаблоны по умолчанию для нескольких кодов ошибок HTTP. Вы можете переопределить шаблоны по умолчанию, создав следующие шаблоны в корневом каталоге шаблонов: 404.html, 500.html, 403.html и 400.html. Представления ошибок по умолчанию, которые используют эти шаблоны, должны быть достаточны для 99% веб-приложений, но вы можете также настроить их.