Как использовать 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, и всё, что находится в /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>

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

Когда 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.