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

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

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

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 для проекта в virtual environment, добавьте путь с помощью WSGIPythonHome. Подробнее см. в руководстве по виртуальным окружениям mod_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'

WSGIDaemonProcess example.com lang='en_US.UTF-8' locale='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 размещается в корне сайта, а 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>

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

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