Как использовать 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 настроен на корневой сайт, но обслуживает 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.