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 своего проекта в один , добавьте путь в . См. Руководство по виртуальной среде mod_wsgi для получения более подробной информации.environnement virtuel WSGIPythonHome

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

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

Затем вы должны убедиться, что этот файл, wsgi.py содержащий приложение WSGI, действительно существует. Начиная с версии 1.4 Django, 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

Если, однако, у вас нет другого выбора, кроме как обслуживать статические файлы в том же VirtualHost Apache, что и Django, вы можете настроить Apache на резервирование определенных URL-адресов для статической файловой службы, а остальные для интерфейса. mod_wsgi из Django.

В этом примере Django устанавливается в качестве корневого сайта, но обслуживает robots.txt , favicon.ico и все URL-адреса, начинающиеся с no /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 ( django/contrib/admin/static/admin ).

Мы настоятельно рекомендуем использовать django.contrib.staticfiles для управления файлами администрирования (вместе с веб-сервером, как обсуждалось в предыдущем разделе; это включает в себя использование команды управления collectstatic для сбора статических файлов STATIC_ROOT , а затем настройку веб-сервер, который будет служить STATIC_ROOT URL-адресом STATIC_URL ), но есть еще три возможных подхода:

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

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

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