Spec-Zone.ru › Django 2.0

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

Развертывание Django с Apache и mod_wsgi — проверенный способ запуска Django в рабочей среде.

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

В официальной документации mod_wsgi вы найдете подробную информацию о том, как использовать mod_wsgi. Возможно, вам захочется начать с документации по установке и настройке.

Основные настройки

После установки и активации mod_wsgi отредактируйте файл httpd.conf вашего сервера Apache и добавьте следующее. Если вы используете версию Apache старше 2.4, замените Require all granted на Allow from all и также добавьте строку Order deny,allow выше нее.

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 внутри virtualenv, добавьте путь к virtualenv с помощью WSGIPythonHome. Более подробную информацию см. в руководстве mod_wsgi по virtualenv.

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

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

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

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

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

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

в wsgi.py, на:

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

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

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

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

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

Обычно эту конфигурацию размещают в /etc/apache2/envvars.

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

Использование 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 настроен на корневой URL-адрес, но обслуживает 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>

Если вы используете версию Apache старше 2.4, замените Require all granted на Allow from all и также добавьте строку Order deny,allow выше нее.

Обслуживание файлов админ-панели

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

© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/2.0/howto/deployment/wsgi/modwsgi/

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API