Spec-Zone.ru › Django 4.2

Как использовать 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 и добавьте следующее.

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.

Строка 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 настроен на поддержку кодировки UTF-8:

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

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

В качестве альтернативы, если вы используете режим демона mod_wsgi, вы можете добавить параметры lang и locale к директиве WSGIDaemonProcess:

WSGIDaemonProcess example.com lang='en_US.UTF-8' locale='en_US.UTF-8'

Подробности см. в разделе «Файлы» справочного руководства по 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, и всё, что находится в пространстве 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 для обработки файлов админ-панели (в сочетании с веб-сервером, как описано в предыдущем разделе; это означает использование команды управления 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/4.2/howto/deployment/wsgi/modwsgi/

Spec-Zone.ru

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