Как использовать 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

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

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

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

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

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

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

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

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

Этот пример настраивает Django на корневом уровне сайта, но обслуживает robots.txt, favicon.ico, и всё в /static/ и /media/ URL-пространствах как статические файлы. Все остальные 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.