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

WSGIDaemonProcess example.com lang='en_US.UTF-8' locale='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 doesn’t serve files itself; it leaves that job to whichever web server you choose.

We recommend using a separate web server – i.e., one that’s not also running Django – for serving media. Here are some good choices:

• 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>

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

When django.contrib.staticfiles is in INSTALLED_APPS, the Django development server automatically serves the static files of the admin app (and any other installed apps). This is however not the case when you use any other server arrangement. You’re responsible for setting up Apache, or whichever web server you’re using, to serve the admin files.

The admin files live in (django/contrib/admin/static/admin) of the Django distribution.

We strongly recommend using django.contrib.staticfiles to handle the admin files (along with a web server as outlined in the previous section; this means using the collectstatic management command to collect the static files in STATIC_ROOT, and then configuring your web server to serve STATIC_ROOT at STATIC_URL), but here are three other approaches:

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

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

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