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

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 настроен на корневой 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.