Как использовать Django с Apache и mod_wsgi

Развертывание Django с помощью Apache и mod_wsgi - это проверенный и испытанный способ запустить Django в производство.

mod_wsgi - это модуль Apache, который может разместить любое приложение Python WSGI, включая Django. Django будет работать с любой версией Apache, которая поддерживает mod_wsgi.

official mod_wsgi documentation - это ваш источник всех подробностей о том, как использовать mod_wsgi. Скорее всего, вы захотите начать с installation and configuration documentation.

Базовая конфигурация

После установки и активации 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 содержание по умолчанию, которое вы должны поместить в этот файл, и что еще вы можете добавить в него.

Предупреждение

Если несколько сайтов Django запущены в одном процессе mod_wsgi, все они будут использовать настройки того из них, который будет запущен первым. Это можно решить, изменив:

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name }}.settings")

в wsgi.py, до:

os.environ["DJANGO_SETTINGS_MODULE"] = "{{ project_name }}.settings"

или по using mod_wsgi daemon mode и обеспечить, чтобы каждый сайт запускался в собственном процессе демона.

Исправление UnicodeEncodeError для загрузки файлов

Если вы получаете ошибку UnicodeEncodeError при загрузке файлов с именами файлов, содержащими символы, отличные от ASCII, убедитесь, что Apache настроен на прием имен файлов, отличных от ASCII:

export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'

Обычное место для размещения этой конфигурации - /etc/apache2/envvars.

Подробности см. в разделе Файлы справочного руководства Unicode.

Использование режима демона 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 - для обслуживания медиа. Вот несколько хороших вариантов:

Однако если у вас нет другого выбора, кроме как обслуживать медиафайлы на том же 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.

Вернуться на верх