Развертывание Django с Apache и 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 сработает.

The <Directory> piece ensures that Apache can access your wsgi.py file.

Далее следует удостовериться, что файл 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), но есть и несколько иных подходов:

  1. Создание символьной ссылки на статические файлы, которые должны содержаться в корневом каталоге (для этого может потребоваться добавление +FollowSymLinks в конфигурации Apache).
  2. Использование директивы Alias, как было показано выше, для создания псевдонима соответствующего URL-адреса (вероятно это будет STATIC_URL + admin/), указывающего на фактическое расположение файлов.
  3. Копирование директории с административной статикой в корень Apache.

Идентификация пользовательской базы данных с Apache

Django предоставляет возможность идентификации пользователей средствами Apache см. mod_wsgi authentication documentation.