Развертывание 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.

WSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py
WSGIPythonPath /path/to/mysite.com

<Directory /path/to/mysite.com/mysite>
<Files wsgi.py>
Order deny,allow
Require all granted
</Files>
</Directory>

Значение WSGIScriptAlias указывает местоположение ваших приложений, (/ обозначает корневую директорию), вторым значением указывается расположение файла “WSGI” – см.ниже – в вашей системе, как правило, в корне проекта. (в примере это mysite). Эти настройки позволят Apache обрабатывать любой запрос из директории, указанной как базовая с помощью WSGI-приложения, хранящегося в ней.

WSGIPythonPath гарантрует, что ваш проект доступен для импорта; иначе говоря, что команда import mysite сработает.

Значение <Directory> просто предоставляет Apache доступ к файлу wsgi.py.

Далее следует удостовериться, что файл wsgi.py существует. Начиная с версии Django 1.4 команда startproject создаёт его; в противном случае вы можете создать этот файл самостоятельно. См. Развёртывание с WSGI, чтобы узнать изначальное содержимое файла и то, какие настройки вы можете добавить.

Предупреждение

Если несколько сайтов на Django запащены в одном процессе mod_wsgi, они все будут использовать настройки сайта, который первый загрузился. Это можно исправить поправив ``wsgi.py``(смотрите комментарий в файле), или используя mod_wsgi daemon mode при котором каждый сайт запущен в отдельном фоновом процессе.

Использование virtualenv

Если вы установили зависимости проекта с помощью virtualenv вам следует добавить путь к директории site-packages, находящейся в вашем виртуальном окружении. Для этого добавьте дополнительный путь к WSGIPythonPath, разделив его двоеточием:

WSGIPythonPath /path/to/mysite.com:/path/to/your/venv/lib/python2.X/site-packages

Убедитесь в том, что путь к виртуальному окружению указан верно и замените python2.X на используемую вами версию Python (например, python2.7).

Использование mod_wsgi в режиме демона

“Режим демона” рекомендуемый режим для запуска mod_wsgi (но не на ОС Windows). Для создания требуемой группы процесса-демона и передачи управления Django вы должны добавить директивы WSGIDaemonProcess и WSGIProcessGroup. Еще одно важное дополнение: при использовании данной конфигурации в режиме демона вы не сможете работать с WSGIPythonPath; вместо этого укажите сопцию python-path , чтобы использовать возможности WSGIDaemonProcess, к примеру:

WSGIDaemonProcess example.com python-path=/path/to/mysite.com:/path/to/venv/lib/python2.7/site-packages
WSGIProcessGroup example.com

Обратитесь к официальной документации mod_wsgi, чтобы узнать подробнее о настройке в режиме демона.

Обслуживание файлов

Django не должен обрабатывать файлы самостоятельно; эта задача передаётся любому выбранному вами веб-серверу.

Мы рекомендуем использовать отдельный веб-сервер – то есть тот, что идёт не в поставке с самим Django – для обслуживания медиа-файлов. Вот несколько неплохих вариантов:

Однако, если у вас нет возможности обслуживать медиа-файлы на том же виртуальном хосте (VirtualHost) что и Django, вы можете настроить Apache на обработку некоторых URL-запросов как статических и медиа-файлов, используя интерфейс mod_wsgi.

Это пример настройки Django в корне сайта, где явно указаны пути к robots.txt, favicon.ico, различным CSS-файлам, а также директориям /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

AliasMatch ^/([^/]*\.css) /path/to/mysite.com/static/styles/$1

Alias /media/ /path/to/mysite.com/media/
Alias /static/ /path/to/mysite.com/static/

<Directory /path/to/mysite.com/static>
Order deny,allow
Allow from all
</Directory>

<Directory /path/to/mysite.com/media>
Order deny,allow
Allow from all
</Directory>

WSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py

<Directory /path/to/mysite.com/mysite>
<Files wsgi.py>
Order allow,deny
Allow from all
</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.

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

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

Если вы столкнулись с ошибкой UnicodeEncodeError

Если вы воспользовались настройками стандартной интернационализации Django (см. Интернационализация и локализация) и позволили пользователям загружать файлы, то должны убедиться, что среда для запуска Apache настроена для обработки не ASCII символов.Если это не так, будет возбуждено исключение UnicodeEncodeError при вызове функций, подобных os.path() с именами файлов, содержащими отличные от ASCII символы.

Чтобы избежать проблем, среда, в которой запущен Apache, должна содержать параметры, аналогичные следующим:

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

Обратитесь к документации вашей операционной системы, чтобы подобрать соответствующий синтаксис и настроить расположение конфигурационных файлов; /etc/apache2/envvars является общей для Unix-like систем. После внесения соответствующих изменений перезапустите Apache.