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