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

Эта 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>

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

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