Базовая конфигурация¶

После установки и активации 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 указывает местоположение ваших приложений, (/ обозначает корневую директорию), вторым значением указывается расположение файла «WSGI» – см.ниже – в вашей системе, как правило, в корне проекта. (в примере это mysite). Эти настройки позволят Apache обрабатывать любой запрос из директории, указанной как базовая с помощью WSGI-приложения, хранящегося в ней.

Если вы установили Python зависимости проекта в virtualenv, добавьте путь к виртуальному окружению, используя WSGIPythonHome. Смотрите справочник по mod_wsgi virtualenv.

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

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

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

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name }}.settings")

os.environ["DJANGO_SETTINGS_MODULE"] = "{{ project_name }}.settings"

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

WSGIDaemonProcess example.com lang='en_US.UTF-8' locale='en_US.UTF-8'

Использование 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

Однако, если у вас нет возможности обслуживать медиа-файлы на том же виртуальном хосте (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>

Файлы админки¶

Если добавить приложение 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 аутентифицировать пользователей напрямую через бэкэнды аутентификации Django. См. mod_wsgi документацию по аутентификации.