Как использовать 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 и добавьте следующее. Если вы используете версию Apache старше 2.4, замените Require all granted на Allow from all и также добавьте строку Order deny,allow выше неё.

WSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py
WSGIPythonPath /path/to/mysite.com

<Directory /path/to/mysite.com/mysite>
<Files wsgi.py>
Require all granted
</Files>
</Directory>

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

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

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

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

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name }}.settings")

os.environ["DJANGO_SETTINGS_MODULE"] = "{{ project_name }}.settings"

export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'

Использование virtualenv

Если вы устанавливаете зависимости вашего проекта Python внутри virtualenv, вам нужно добавить путь к каталогу site-packages этого virtualenv в ваш путь Python. Для этого добавьте дополнительный путь к директиве WSGIPythonPath, используя двоеточие (:) для разделителя путей при использовании системы на основе UNIX или точку с запятой (;) для Windows. Если какая-либо часть пути каталога содержит пробел, вся строка аргумента для WSGIPythonPath должна быть заключена в кавычки:

WSGIPythonPath /path/to/mysite.com:/path/to/your/venv/lib/python3.X/site-packages

Убедитесь, что вы указали правильный путь к вашему virtualenv, и замените python3.X на правильную версию Python (например, python3.4).

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

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

WSGIDaemonProcess example.com python-path=/path/to/mysite.com:/path/to/venv/lib/python2.7/site-packages
WSGIProcessGroup example.com

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

WSGIScriptAlias /mysite /path/to/mysite.com/mysite/wsgi.py process-group=example.com

Подробности по настройке режима демона см. в официальной документации mod_wsgi по адресу https://modwsgi.readthedocs.io/en/develop/user-guides/quick-configuration-guide.html#delegation-to-daemon-process.

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

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

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

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

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

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

Alias /robots.txt /path/to/mysite.com/static/robots.txt
Alias /favicon.ico /path/to/mysite.com/static/favicon.ico

Alias /media/ /path/to/mysite.com/media/
Alias /static/ /path/to/mysite.com/static/

<Directory /path/to/mysite.com/static>
Require all granted
</Directory>

<Directory /path/to/mysite.com/media>
Require all granted
</Directory>

WSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py

<Directory /path/to/mysite.com/mysite>
<Files wsgi.py>
Require all granted
</Files>
</Directory>

Если вы используете версию Apache старше 2.4, замените Require all granted на Allow from all и также добавьте строку Order deny,allow выше её.

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

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

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

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

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

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

Django предоставляет обработчик, позволяющий Apache напрямую авторизовать пользователей против механизмов аутентификации Django. См. документацию по аутентификации mod_wsgi.