mod_wsgi¶Развертывание Django с Apache и mod_wsgi это испытанный способ установки на «боевой» веб-сервер.
mod_wsgi является модулем веб-сервера Apache, который может взаимодействовать с любым приложением Python, в том числе 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 указывает местоположение ваших приложений, (/ обозначает корневую директорию), вторым значением указывается расположение файла «WSGI» – см.ниже – в вашей системе, как правило, в корне проекта. (в примере это mysite). Эти настройки позволят Apache обрабатывать любой запрос из директории, указанной как базовая с помощью WSGI-приложения, хранящегося в ней.
Если вы установили Python зависимости проекта в virtualenv, добавьте путь к виртуальному окружению, используя WSGIPythonHome. Смотрите справочник по mod_wsgi virtualenv.
WSGIPythonPath гарантирует, что ваш проект доступен для импорта; иначе говоря, что команда import mysite сработает.
Значение <Directory> просто предоставляет Apache доступ к файлу wsgi.py.
Далее следует удостовериться, что файл wsgi.py существует. Начиная с версии 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 daemon mode при котором каждый сайт запущен в отдельном фоновом процессе.
Исправляем UnicodeEncodeError при загрузке файлов
Если вы получили UnicodeEncodeError при загрузке файлов, названия которых содержат не ASCII символы, убедитесь, что Apache настроен для загрузки таких файлов:
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
Настройки обычно находятся в /etc/apache2/envvars.
Подробности смотрите в разделе Файлы.
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 – для обслуживания медиа-файлов. Вот несколько неплохих вариантов:
Однако, если у вас нет возможности обслуживать медиа-файлы на том же виртуальном хосте (VirtualHost) что и Django, вы можете настроить Apache на обработку некоторых URL-запросов как статических и медиа-файлов, используя интерфейс mod_wsgi.
Это пример настройки Django в корне сайта, где явно указаны пути к robots.txt, favicon.ico, а также директориям /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>
Если вы используете 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/), указывающего на фактическое расположение файлов.Django предоставляет возможность идентификации пользователей средствами Apache см. mod_wsgi authentication documentation.
июн. 04, 2020