Как использовать 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 — для обслуживания медиафайлов. Вот несколько хороших вариантов:
Однако, если у вас нет другого варианта, кроме как обслуживать медиафайлы на том же сервере 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), но вот три других подхода:
- Создайте символическую ссылку на статические файлы админ-панели изнутри корня вашего документа (для этого может потребоваться
+FollowSymLinksв вашей конфигурации Apache). - Используйте директиву
Aliasкак показано выше, чтобы сделать алиас соответствующего URL-адреса (вероятно,STATIC_URL+admin/для фактического расположения файлов админ-панели). - Скопируйте статические файлы админ-панели так, чтобы они находились внутри корня документа 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/