Как использовать 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
WSGIPythonHome /path/to/venv
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-приложения, определенного в этом файле.

Если вы устанавливаете зависимости вашего проекта Python внутри virtualenv, добавьте путь к virtualenv, используя WSGIPythonHome. Подробнее см. в руководстве mod_wsgi по virtualenv.

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

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

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

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

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

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

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

WSGIDaemonProcess example.com python-home=/path/to/venv python-path=/path/to/mysite.com
WSGIProcessGroup example.com

Если вы хотите обслуживать свой проект в подкаталоге (https://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 настроен на корневой URL сайта, но служит 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.