Spec-Zone.ru › Django 5.1

Как использовать 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, определённого в этом файле.

Если вы устанавливаете зависимости вашего проекта внутри 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 настроен на корневой сайт, но обслуживает 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/5.1/howto/deployment/wsgi/modwsgi/

Spec-Zone.ru

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