Как использовать Django с Apache и mod_wsgi

Развертывание Django с Apache и mod_wsgi — проверенный способ запустить Django в рабочей среде.

mod_wsgi — это модуль Apache, который может принимать любые Python-приложения WSGI, включая Django. Django будет работать с любой версией Apache, которая поддерживает mod_wsgi.

В официальной документации mod_wsgi вы найдете все подробности о том, как использовать mod_wsgi. Вероятно, вы захотите начать с инструкций по установке и настройке.

Базовая настройка

После установки и активации mod_wsgi отредактируйте файл httpd.conf вашего сервера Apache и добавьте следующее.

Первая часть в строке WSGIScriptAlias — это базовый URL-путь, по которому вы хотите обслуживать ваше приложение (/ указывает корневой URL), а вторая — расположение файла «WSGI» на вашем компьютере, обычно внутри пакета вашего проекта (mysite в этом примере). Это указывает Apache на то, что любые запросы ниже указанного URL-адреса должны обрабатываться приложением WSGI, определённым в этом файле.

Если вы устанавливаете зависимости вашего проекта внутри virtual environment, добавьте путь, используя WSGIPythonHome. Более подробную информацию смотрите в руководстве по виртуальным окружениям mod_wsgi.

Строка WSGIPythonPath гарантирует, что пакет вашего проекта будет доступен для импорта в пути Python; другими словами, что import mysite работает.

Часть <Directory> гарантирует, что Apache может получить доступ к вашему файлу wsgi.py.

Далее нам нужно убедиться, что этот wsgi.py с объектом приложения WSGI существует. С версии Django 1.4, startproject уже создаст его; в противном случае вам нужно его создать. См. документацию по обзору WSGI для содержимого по умолчанию, которое вы должны поместить в этот файл, и что ещё вы можете добавить.

Предупреждение

Если несколько сайтов Django работают в одном процессе mod_wsgi, все они будут использовать настройки того, который запустится первым. Это можно исправить, изменив:

в wsgi.py, на:

или используя режим демона mod_wsgi и гарантируя, что каждый сайт работает в своём процессе демона.

Решение проблемы UnicodeEncodeError для загрузки файлов

Если вы получаете UnicodeEncodeError при загрузке или записи файлов с именами файлов или содержимым, содержащим не-ASCII символы, убедитесь, что Apache настроен на поддержку кодировки UTF-8:

Общее место для размещения этой конфигурации — /etc/apache2/envvars.

В качестве альтернативы, если вы используете режим демона mod_wsgi, вы можете добавить параметры lang и locale к директиве WSGIDaemonProcess:

См. раздел Файлы справочника по Unicode для получения дополнительной информации.

Использование режима демона `mod_wsgi`

«Режим демона» — рекомендуемый режим запуска mod_wsgi (на платформах, не Windows). Чтобы создать необходимую группу процессов демона и делегировать экземпляр Django для работы в ней, вам нужно добавить соответствующие директивы WSGIDaemonProcess и WSGIProcessGroup. Ещё одно изменение, необходимое в вышеупомянутой конфигурации, если вы используете режим демона, заключается в том, что вы не можете использовать WSGIPythonPath; вместо этого вы должны использовать параметр python-path для директивы WSGIDaemonProcess, например:

Если вы хотите обслуживать ваш проект в подкаталоге (https://example.com/mysite в этом примере), вы можете добавить WSGIScriptAlias в вышеприведенную конфигурацию:

См. официальную документацию mod_wsgi для подробностей по настройке режима демона.

Обслуживание файлов

Django не обслуживает файлы сам по себе; он делегирует эту задачу выбранному веб-серверу.

Рекомендуется использовать отдельный веб-сервер — то есть веб-сервер, который не выполняет Django — для обслуживания медиафайлов. Вот несколько хороших вариантов:

Nginx
Упрощенная версия Apache

Однако, если у вас нет другого выбора, кроме как обслуживать медиафайлы на том же сервере Apache VirtualHost, что и Django, вы можете настроить Apache для обслуживания некоторых URL-адресов как статических медиафайлов, а другие — с помощью интерфейса mod_wsgi для Django.

В этом примере Django настроен на корневой URL, но обслуживаются robots.txt, favicon.ico и все в URL-пространстве /static/ и /media/ как статические файлы. Все остальные URL-адреса будут обслуживаться с помощью mod_wsgi:

Обслуживание файлов админки

Когда django.contrib.staticfiles находится в INSTALLED_APPS, сервер разработки Django автоматически обслуживает статические файлы приложения админки (и любых других установленных приложений). Однако это не так, когда вы используете другую конфигурацию сервера. Вы ответственны за настройку Apache или другого используемого веб-сервера для обслуживания файлов админки.

Файлы админки находятся в (django/contrib/admin/static/admin) в дистрибутиве Django.

Мы настоятельно рекомендуем использовать django.contrib.staticfiles для обработки файлов админки (вместе с веб-сервером, как описано в предыдущем разделе; это означает использование команды управления collectstatic для сбора статических файлов в STATIC_ROOT, а затем настройку веб-сервера для обслуживания STATIC_ROOT по адресу STATIC_URL), но вот три других подхода:

Создайте символическую ссылку на статические файлы админки из корня документа (это может потребовать +FollowSymLinks в вашей конфигурации Apache).
Используйте директиву Alias, как показано выше, для алиасирования соответствующего URL-адреса (вероятно, STATIC_URL + admin/) до фактического местоположения файлов админки.
Скопируйте статические файлы админки так, чтобы они находились в корне документа Apache.

Авторизация через базу данных пользователей Django с Apache