Использование Django совместно с Apache и mod_python
Веб-сервер Apache с модулем mod_python исторически всегда считался основной рабочей средой для Django.
mod_python (http://www.djangoproject.eom/r/mod_python/) - это подключаемый к Apache модуль, который реализует интерпретатор языка Python внутри веб-сервера и загружает написанный на Python код в момент запуска сервера. Код остается в памяти все время, пока процесс Apache работает, что дает существенный выигрыш в производительности по сравнению с другими конфигурациями.
Для работы Django необходимы версии Apache 2.x и mod_python 3.x.
Примечание —————————————————————————-
Настройка сервера Apache выходит далеко за рамки этой книги, поэтому мы лишь вскользь коснемся некоторых деталей. Впрочем, для тех, кто хочет узнать об Apache подробнее, в Сети есть множество прекрасных ресурсов. Ниже перечислены те, которые больше всего нам нравятся.
• Бесплатную электронную документацию о сервере Apache можно найти на странице http://www.djang0pr0ject.c0m/r/apache/d0cs/.
• На странице http://www.djang0pr0ject.c0m/r/b00ks/pr0-apache/ вы сможете приобрести третье издание книги Питера Уэйнрайта (Peter Wainwright) «Pro Apache» (Apress, 2004).
• На странице http://oreilly.com/catalog/9780596002039/ вы сможете приобрести третье издание книги Бена Лаури (Ben Laurie) и Питера Лаури (Peter Laurie) «Apache: The Definitive Guide», третье издание (O’Reilly, 2002).
Базовая конфигурация
Прежде чем настраивать Django для работы с mod_python, убедитесь, что этот модуль установлен и подключен к Apache. Обычно это означает, что в конфигурационном файле Apache присутствует директива LoadModule, которая выглядит примерно так:
LoadModule pythonjnodule /usr/lib/apache2/modules/mod_python.so
Затем откройте конфигурационный файл Apache в редакторе и добавьте директиву <Location>, которая свяжет вашу инсталляцию Django с URL-адресом:
<Location "/">
SetHandler python-program PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE mysite.settings PythonDebug Off </Location>
Вместо mysite.settings присвойте переменной DJANGO_SETTINGS_MODULE значение, соответствующее вашему сайту.
Тем самым вы сообщите серверу Apache: «использовать модуль mod_ python для любого URL, начинающегося с ‘/’, применяя обработчик Django». Модулю mod_python будет передаваться переменная окружения DJANGO_SETTINGS_MODULE, благодаря чему он будет знать, где находится файл с параметрами.
Обратите внимание, что мы использовали директиву <Location>, а не <Directoгу>. Последняя служит для указания местоположения в файловой системе, тогда как <Location> связана со структурой URL веб-сайта. В данном случае директива <Directory> не имела бы смысла.
Скорее всего, Apache работает от имени пользователя, у которого путь и параметр sys. path установлены не так, как у вас. Поэтому необходимо сообщить mod_python, как найти проект и сам фреймворк Django.
PythonPath "[‘/путь/к/проекту’, ‘/путь/к/django’] + sys.path"
Для повышения производительности можно добавить такие директивы, как PythonAutoReload Off. Полный перечень параметров см. в документации по модулю mod_python.
На действующем сервере следует отключить отладку директивой PythonDebug Off. Если оставить ее включенной, то в случае ошибок в mod python пользователи увидят безобразную (и предательскую) трассировку Python.
После перезапуска Apache любой запрос к вашему сайту (или виртуальному хосту, если вы поместили директиву внутрь блока <VirtualHost>) будет обслуживаться Django.
Использование нескольких инсталляций Django на одном экземпляре Apache
Имеется возможность использовать несколько инсталляций Django на одном экземпляре Apache. Это может понадобиться, если вы независимый веб-разработчик, у которого есть несколько клиентов, но всего один сервер.
Для организации такой конфигурации воспользуйтесь директивой
VirtualHost:
NameVirtualHost *
<VirtualHost *>
ServerName www.example.com ft …
SetEnv DJANGO_SETTINGS_MODULE mysite.settings </Vi rtualHost>
<VirtualHost *>
ServerName www2.example.com tt . ..
SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings </VirtualHost>
Если необходимо поместить две инсталляции Django в один блок VirtualHost, то позаботьтесь о том, чтобы предотвратить неразбериху из-за кэширования кода внутри mod_python. С помощью директивы Pythonlnterpreter назначьте разным директивам <Location> разные интерпретаторы.
<VirtualHost *>
ServerName www.example.com tt . ..
<Location "/something">
SetEnv DJANGO_SETTINGS_MODULE mysite.settings Pythonlnterpreter mysite </Location>
<Location "/otherthing">
SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings Pythonlnterpreter mysite_other </Location> </VirtualHost>
Конкретные значения Pythonlnterpreter не важны, главное, чтобы они отличались в разных блоках Location.
Запуск сервера разработки с модулем mod_python
Поскольку mod_python кэширует загруженный код на Python, то при развертывании Django-сайтов в этой среде любое изменение кода требует перезапуска Apache. Это может быстро надоесть, но есть простой способ исправить ситуацию: включите в конфигурационный файл Apache директиву MaxRequestsPerChild 1, и тогда код будет заново загружаться после каждого запроса. Однако не следует так поступать на действующем сервере, если не хотите, чтобы вас отлучили от Django.
Если вы принадлежите к программистам, которые предпочитают отлаживаться, размещая в разных местах инструкции print (как мы, например), то имейте в виду, что при работе с mod_python эти инструкции бесполезны; сообщения, которые они выводят, не появляются в журнале Apache. Если вам все-таки потребуется вывести отладочную информацию, воспользуйтесь стандартным пакетом протоколирования для Python. Дополнительные сведения см. на странице http://docs.python. org/lib/module-logging.html.
Обслуживание Django и мультимедийных файлов с одного экземпляра Apache
Сам фреймворк Django не должен использоваться для обслуживания мультимедийных файлов, оставьте эту задачу веб-серверу. Мы рекомендуем применять для этой цели отдельный веб-сервер (не тот, на котором работает Django). Дополнительные сведения см. в разделе «Масштабирование».
Однако если нет другого выхода, кроме как обслуживать мультимедийные файлы тем же виртуальным хостом, что и Django, то можно отключить mod_python для отдельных частей сайта, например:
<Location "/media/"> SetHandler None </Location>
Вместо /media/ укажите в директиве Location начальный URL области размещения мультимедийных файлов.
Можно также использовать директиву <LocationMatch> с регулярным выражением. Так, в следующем примере мы говорим, что весь сайт будет обслуживаться Django, но явно исключаем подкаталог media и все URL, оканчивающиеся на .jрд, .gif или .рпд:
<Location "/">
SetHandler python-program PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE mysite.settings </Location>
<Location "/media/"> SetHandler None </Location>
<LocationMatch (jpgIgifIpng)$">
SetHandler None </LocationMatch>
В любом случае вам потребуется определить директиву DocumentRoot, чтобы Apache знал, где искать статические файлы.
Обработка ошибок
При использовании комбинации Apache/mod_python ошибки будут обрабатываться Django, то есть они не будут доходить до уровня Apache и не попадут в журнал ошибок error_log.
Это не относится к ошибкам в самой конфигурации Django. Если возникнет такая ошибка, в броузере появится зловещее сообщение «Internal Server Error» (Внутренняя ошибка сервера), а в файле еггог_ log останется полная трассировка ошибки, сгенерированная интерпретатором Python. Трассировка занимает несколько строк. (Согласны, она выглядит безобразно и читать ее довольно трудно, то так уж работает mod_python.)
Обработка ошибок сегментации
Иногда после установки Django сервер Apache сообщает об ошибках сегментации. Почти всегда это вызвано одной из двух причин, не относящихся к Django:
• Вы могли импортировать в своем коде модуль pyexpat (применяемый для разбора XML), который конфликтует с версией, встроенной в Apache. Дополнительную информацию см. в статье «Expat Causing Apache Crash» на странице http://www.djangoproject.eom/r/articles/ expat-apache-crash/.
• Возможно, причина в том, что в одном экземпляре Apache работают модули mod_python и mod_php, причем в качестве СУБД используется MySQL. Иногда это приводит к известной ошибке в mod_python из-за конфликта между версиями библиотек доступа к MySQL в РНР и Python. Дополнительную информацию см. на странице FAQ по mod_python по адресу http://www.djangoproject.eom/r/articles/php-mod~ python-faq/.
Если от проблем с mod_python никак не удается избавиться, мы рекомендуем сначала добиться нормальной работы mod_python без Django. Так вы сможете изолировать проблемы, относящиеся к самому mod_python. Подробности приведены в статье «Getting mod_python Working» по адресу http://www.djangoproject.eom/r/articles/getting-mod’ python-working/.
Следующий шаг - добавить в тестовую программу импорт кода, имеющего отношение к Django: ваши представления, модели, конфигурацию URL, конфигурацию RSS и т. д. Поместите все инструкции импорта в тестовое представление и попробуйте обратиться к нему из броузера. Если сервер «упадет», можно считать доказанным, что причина в Django. Убирайте одну за другой инструкции импорта, пока «падения» не прекратятся; так вы найдете конкретный модуль, приводящий к ошибке. Посмотрите, что импортирует этот модуль. Чтобы найти зависимости от динамически загружаемых библиотек и выявить потенциальные конфликты версий, можно воспользоваться программами ldconfig в Linux, otool в Mac или ListDLLs (от компании Syslnternals) в Windows.
Альтернатива: модуль mod_wsgi
В качестве альтернативы mod_python можно воспользоваться модулем mod_wsgi (ihttp://code.google.eom/p/modwsgi/), который был разработан позже mod_python и вызывает некоторый интерес в сообществе Django. Подробное его описание выходит за рамки настоящей книги, но кое- какая информация имеется в официальной документации по Django.
Источник: Головатый А., Каплан-Мосс Дж. Django. Подробное руководство, 2-е издание. - Пер. с англ. - СПб.: Символ- Плюс, 2010. - 560 е., ил.