Как использовать Django с Apache и 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 virtual environment guide.

Строка WSGIPythonPath гарантирует, что пакет вашего проекта доступен для импорта по пути Python; другими словами, что import mysite работает.

Часть <Directory> гарантирует, что Apache сможет получить доступ к вашему файлу wsgi.py.

Далее нам нужно убедиться, что этот wsgi.py с объектом приложения WSGI существует. Начиная с версии Django 1.4, startproject создаст его за вас; в противном случае, вам придется создать его. Смотрите в WSGI overview documentation содержание по умолчанию, которое вы должны поместить в этот файл, и что еще вы можете добавить в него.

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). Чтобы создать необходимую группу процессов daemon и делегировать экземпляр Django для запуска в ней, вам нужно добавить соответствующие директивы WSGIDaemonProcess и WSGIProcessGroup. Еще одно изменение, которое необходимо внести в приведенную выше конфигурацию, если вы используете режим демона, заключается в том, что вы не можете использовать WSGIProcessGroup; вместо этого вы должны использовать опцию WSGIPythonPath, например, python-path:

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 для details on setting up daemon mode.

Служебные файлы¶

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 для работы с файлами администратора (вместе с Web-сервером, как описано в предыдущем разделе; это означает использование команды управления collectstatic для сбора статических файлов в STATIC_ROOT, а затем настройку вашего Web-сервера для обслуживания STATIC_ROOT в STATIC_URL), но вот три других подхода:

1. Создайте символическую ссылку на статические файлы администратора в корне документа (для этого может потребоваться +FollowSymLinks в конфигурации Apache).
2. Используйте директиву Alias, как показано выше, для псевдонима соответствующего URL (возможно STATIC_URL + admin/) для фактического расположения файлов администратора.
3. Скопируйте статические файлы администратора так, чтобы они находились в корне документа Apache.

Аутентификация по базе данных пользователей Django из Apache¶

Django предоставляет обработчик, позволяющий Apache аутентифицировать пользователей непосредственно с помощью бэкендов аутентификации Django. См. раздел mod_wsgi authentication documentation.