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

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