chap20.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[
<!ENTITY BASEID "djangobook.chap20">
]>

<chapter lang="ru" id="&BASEID;">

  <title id="&BASEID;.title">
    Развёртывание Django
  </title>

  <para>
    Перевод &copy; Чепиков Александр &lt;achepikau &bull; gmail &bull; com&gt;
  </para>

  <para>
    Редактирование &copy; Попов Руслан &lt;radz &bull; yandex &bull; ru&gt;
  </para>

  <para>
    На протяжении всей книги мы перечислили множество задач, на
    решение которых нацелена разработка Django &mdash; это простота
    использования, дружелюбность к новичкам, освобождение от рутинной
    работы.
  </para>

  <para>
    Однако с самого начала работы над Django существовала еще одна
    важная задача: Django должнен быть по возможности простым в
    развертывании и обрабатывать большой трафик при ограниченных
    требованиях к ресурсам.
  </para>

  <para>
    Причина очевидна, если взглянуть на исходные данные этой задачи:
    небольшая <quote>семейная</quote> газета из Канзаса вряд ли была в
    состоянии приобрести высококлассное серверное оборудование,
    поэтому авторы Django сконцентрировались на выжимании наилучшей
    производительности из доступных им ресурсов. Более того,
    разработчики Django долгое время работали и как системные
    администраторы &mdash; просто потому что имеющегося в наличии
    оборудования <emphasis>не хватало</emphasis> для принятия на
    работу системного администратора на полную ставку &mdash; несмотря
    на то, что их сайты обрабатывали к тому времени десятки миллионов
    обращений в сутки.
  </para>

  <para>
    Когда же Django превратился в проект с открытым исходным кодом,
    нацеленность на производительность и простоту развертывания стала
    важной и по другой причине: у свободных разработчиков аналогичные
    требования. Те из них, кто хотел использовать Django, были рады
    тому, что смогут платить всего 10 долларов за хостинг не очень
    большого (среднего) сайта.
  </para>

  <para>
    Но возможность масштабирования <quote>вниз</quote> &mdash; это
    только половина успеха. Django должен масштабироваться и
    <quote>вверх</quote>, чтобы удовлетворить запросы крупных компаний
    и корпораций. Поэтому Django придерживается общего подхода для
    LAMP-подобных веб приложений, который часто называют
    <quote><emphasis>ничего общего</emphasis></quote>.

    <note>
      <title>
	Как расшифровывается LAMP?
      </title>

      <para>
	Аббревиатура LAMP изначально была придумана для описания
	популярного набора программного обеспечения с открытым кодом,
	который используется в работе многих вебсайтов:
	<itemizedlist>
	  <listitem>
	    <para>
	      Linux (Операционная система);
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      Apache (Веб сервер);
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      MySQL (Сервер базы данных);
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      PHP (Язык программирования).
	    </para>
	  </listitem>
	</itemizedlist>
      </para>

      <para>
	Впоследствии, однако, эта аббревиатура стала скорее
	обозначением каких-то совокупностей общих типов программ с
	открытым кодом, нежели конкретного набора приложений.
	Поэтому, хотя Django использует Python и не привязана к
	конкретной базе данных, философия LAMP сильно влияет на
	умонастроения разработчиков Django.
      </para>

      <para>
	Было даже несколько (в основном юмористических) попыток
	придумать похожую аббревиатуру для описания технологий,
	используемых в Django.  Авторам данной книги пришлись по душе
	сокращения LAPD (Linux, Apache, PostgreSQL и Django), PAID
	(PostgreSQL, Apache, Internet и Django), а так же девиз
	<quote>Use Django and get PAID!</quote>, что буквально
	означает <quote>Применяй Django и получай зарплату!</quote>.
      </para>
    </note>
  </para>

  <section id="&BASEID;.shared-nothing">

    <title id="&BASEID;.shared-nothing.title">
      Ничего общего
    </title>

    <para>
      По своей сути данный подход означает, что приложение использует
      множество программных компонентов, слабо связанных между собой.
      Такая архитектура появилась, как альтернатива на превалирующий
      когда-то подход: монолитный сервер приложений, объединяющий язык
      программирования, базу данных, веб сервер и даже часть
      операционной системы в один процесс (например, Java).
    </para>

    <para>
      И когда приходит время увеличить размеры приложения, это может
      стать основной проблемой: практически невозможно распределить
      монолитный процесс на физически разные компьютеры, поэтому
      монолитным приложениям требуются очень мощные сервера.  Такие
      сервера, естественно, стоят десятки и даже сотни тысяч долларов,
      что препятствует их использованию небольшими компаниями и
      физическими лицами, всегда испытывающими нехватку денег.
    </para>

    <para>
      Сообщество LAMP, однако, обращает внимание на то, что если
      разбить каждую часть веб приложения на отдельные компоненты, то
      вполне можно стартовать с недорогого сервера и просто добавлять
      такие же сервера по мере роста проекта.  Если сервер базы данных
      за 3 тысячи долларов не справляется с нагрузкой, достаточно
      просто купить ещё один (второй, третий или четвертый) столько
      раз, сколько потребуется. Если потребовалось дополнительное
      дисковое пространство, несложно добавить еще один NFS сервер.
    </para>

    <para>
      Для того, чтобы такой подход всё-таки работал, веб приложения не
      должны быть привязаны к одному серверу при обработке запроса,
      или даже части запроса.  В сильно распределенных LAMP (и Django)
      системах по крайней мере полдюжины серверов могут использоваться
      для выдачи одной веб страницы!  Вариантов построения таких
      систем множество, но все они сводятся к следующим принципам:
      <itemizedlist>
	<listitem>
	  <para>
	    <emphasis>Текущее состояние не сохраняется
	    локально.</emphasis> Другими словами, любые общие данные
	    для различных запросов должны храниться в базе данных либо
	    в централизованной кэш-системе.
	  </para>
	</listitem>

	<listitem>
	  <para>
	    <emphasis>Программа не должна быть замкнута на
	    использование локальных ресурсов.</emphasis> Например, веб
	    сервер не должен полагаться на то, что сервер базы данных
	    работает на одном с ним физическом сервере. Он должен
	    поддерживать работу с удаленной базой данных.
	  </para>
	</listitem>

	<listitem>
	  <para>
	    <emphasis>Каждый компонент в приложении должен быть легко
	    заменяем и поддерживать репликацию.</emphasis> Например,
	    если веб сервер Apache по каким-то причинам не подходит
	    для текущего приложения, должна быть возможность без
	    проблем заменить его другим веб сервером. Или в случае
	    выхода из строя компьютера с веб сервером можно заменить
	    его на другой с минимальным временем простоя. Помните,
	    весь этот подход базируется на использовании недорогих,
	    широко распространенных компьютеров. Выход из строя
	    отдельных серверов должен быть предусмотрен заранее.
	  </para>
	</listitem>
      </itemizedlist>
    </para>

    <para>
      Как и следовало ожидать, Django соответствует этим принципам
      более или менее точно &mdash; ни один из компонентов Django не
      нарушает данного подхода &mdash; но знание его основ поможет,
      когда наступит время для увеличения размеров приложения.
    </para>

    <para>
      <note>
	<title>
	  Как это работает?
	</title>

	<para>
	  Такие рассуждения могут выглядеть неплохо на бумаге (или на
	  вашем экране), но как всё это работает на самом деле?
	</para>

	<para>
	  Хорошо, вместо того, чтобы отвечать непосредственно на
	  вопрос, давайте посмотрим на крайне неполный список
	  компаний, которые основали свой бизнес на этой основе. Вы
	  могли уже встречать их названия: Amazon, Blogger,
	  Craigslist, Facebook, Google, LiveJournal, Slashdot,
	  Wikipedia, Yahoo, YouTube.
	</para>

	<para>
	  Перефразируя известную сцену из <quote>Когда Гарри встретил
	  Салли</quote>: <quote>У нас будет всё то же, что и у
	  них!</quote>
	</para>
      </note>
    </para>

  </section>

  <section id="&BASEID;.personal-preferences">

    <title id="&BASEID;.personal-preferences.title">
      Что предпочитают разработчики Django?
    </title>

    <para>
      Перед тем, как погрузиться в детали, сделаем небольшое
      отступление.
    </para>

    <para>
      Сообщество open source знаменито своими так называемыми
      <quote>религиозными войнами</quote>; множество (цифровых) чернил
      пролито в спорах о текстовых редакторах
      (<command>emacs</command> против <command>vi</command>),
      операционных системах (Linux против Windows и против MacOS),
      серверов баз данных (MySQL против PostgreSQL) и, естественно, о
      языках программирования.
    </para>

    <para>
      Мы стараемся оставаться в стороне от всех этих битв. На это
      просто нет времени.
    </para>

    <para>
      Однако существует множество вариантов для развертывания Django и
      нас постоянно спрашивают от том, что же мы сами
      предпочитаем. Практически всегда мы воздерживаемся от
      комментариев, так как это приводит только к разжиганию нового
      витка вышеупомянутых споров. Но ради того, чтобы закончить с
      этим и полностью раскрыть карты, мы указываем наши предпочтения:
      <itemizedlist>
	<listitem>
	  <para>
	    Операционная система &mdash; Linux (Ubuntu, если быть ещё
	    точнее);
	  </para>
	</listitem>

	<listitem>
	  <para>
	    Веб сервер &mdash; Apache с поддержкой mod_python;
	  </para>
	</listitem>

	<listitem>
	  <para>
	     Сервер базы данных &mdash; PostgreSQL.
	  </para>
	</listitem>
      </itemizedlist>
    </para>

    <para>
      Но мы знаем многих пользователей Django, выбравших другие
      варианты развертывания и, тем не менее, достигших больших
      успехов.
    </para>

  </section>

  <section id="&BASEID;.using-apache-mod_python">

    <title id="&BASEID;.using-apache-mod_python.title">
      Использование Django с Apache и mod_python
    </title>

    <para>
      Apache с поддержкой <token>mod_python</token> на текущий момент
      является наиболее стабильной и надёжной средой при развёртывании
      Django на рабочем сервере.
    </para>

    <para>
      <token>mod_python</token> (<ulink
      url="http://www.djangoproject.com/r/mod_python/"/>) &mdash; это
      модуль для Apache, позволяющий встроить Python в ядро Apache и
      загрузить программы на Python в память веб сервера при его
      запуске. Исполняемый код хранится в памяти до конца работы
      процесса Apache, что дает значительный прирост
      производительности.
    </para>

    <para>
      Для работы Django необходим Apache версии 2.x и mod_python
      версии 3.x, в качестве МП-модуля рекомендуется использовать
      Prefork, а не Worker.

      <note>
	<para>
	  Обсуждение настройки Apache выходит
	  <emphasis>далеко</emphasis> за рамки данной книги, поэтому
	  при необходимости мы просто будем делать ссылки на некоторые
	  детали. В сети Интернет есть много хороших ресурсов для тех,
	  кто хочет узнать больше об этом веб сервере. Вот некоторые
	  из них, которые нравятся нам самим:
	  <itemizedlist>
	    <listitem>
	      <para>
		Документация по Apache в свободном онлайн доступе:
		<ulink
		url="http://www.djangoproject.com/r/apache/docs/"/>;
	      </para>
	    </listitem>

	    <listitem>
	      <para>
		Книга <emphasis>Pro Apache, Third Edition</emphasis>
		(Apress, 2004), автор Peter Wainwright: <ulink
		url="http://www.djangoproject.com/r/books/pro-apache/"/>;
	      </para>
	    </listitem>

	    <listitem>
	      <para>
		Книга <emphasis>Apache: The Definitive Guide, Third
		Edition</emphasis> (O’Reilly, 2002), авторы Ben Laurie
		и Peter Laurie: <ulink
		url="http://www.djangoproject.com/r/books/apache-pra/"/>.
	      </para>
	    </listitem>
	  </itemizedlist>
	</para>
      </note>
    </para>

    <section id="&BASEID;.using-apache-mod_python.base-settings">

      <title id="&BASEID;.using-apache-mod_python.base-settings.title">
	Базовые настройки
      </title>

      <para>
	Чтобы настроить Django для использования mod_python, сперва
	необходимо убедиться, что установлен Apache с поддержкой
	mod_python. Обычно это означает, что в конфигурационном файле
	Apache присутствует соответствующая директива
	<token>LoadModule</token>:
	<screen>
	  <![CDATA[
LoadModule python_module /usr/lib/apache2/modules/mod_python.so
	  ]]>
	</screen>
      </para>

      <para>
	Теперь добавим в этот файл следующие строки:
	<screen>
	  <![CDATA[
<Location "/">
    SetHandler mod_python
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE mysite.settings
    PythonDebug On
</Location>
	  ]]>
	</screen>
      </para>

      <para>
	Вместо <token>mysite.settings</token> необходимо вписать имя
	модуля настроек Django для вашего сайта.
      </para>

      <para>
	Такая директива означает, что Apache должен обрабатывать все
	URL, начинающиеся от корня сайта, используя обработчик
	mod_python от Django. Он передает ему значение переменной
	<varname>DJANGO_SETTINGS_MODULE</varname>, чтобы mod_python
	знал, какие настройки использовать.
      </para>

      <para>
	Отметим, что мы использовали директиву
	<token><![CDATA[<Location>]]></token>, а не
	<token><![CDATA[<Directory>]]></token>. Последняя из них
	указывает на путь в файловой системе, тогда как
	<token><![CDATA[<Location>]]></token> используется при
	формировании структуры URL для вебсайта. Использование
	<token><![CDATA[<Directory>]]></token> в таком случае является
	бессмысленным.
      </para>

      <para>
	Обычно Apache запускается от имени специального пользователя,
	которое отличается от вашего логина в систему и имеет другие
	настройки <token>path</token> и
	<token>sys.path</token>. Поэтому необходимо указать для
	mod_python, где искать ваш проект и файлы Django:
	<screen>
	  <![CDATA[
PythonPath "['/путь/к/проекту', '/путь/к/django'] + sys.path"
	  ]]>
	</screen>
      </para>

      <para>
	Вы можете добавить дополнительные директивы, такие, как
	<token>PythonAutoReload Off</token>, для увеличения
	производительности. Полный список опций можно найти в
	документации по mod_python.
      </para>

      <para>
	Рекомендуем отключить опцию <token>PythonDebug</token>
	(<token>PythonDebug Off</token>) для рабочей версии
	приложения. Если оставить ее включенной, ваши пользователи
	увидят некрасивый и избыточный стек ошибок Python, когда
	возникнут проблемы с mod_python.
      </para>

      <para>
	Перегрузите Apache и теперь любой запрос к вашему сайту (либо
	виртуальному хосту, если вы разместили директиву внутри блока
	<token><![CDATA[<VirtualHost>]]></token>) будет обрабатываться
	Django.

	<note>
	  <para>
	    Если разворачивать Django в подкаталоге, то есть глубже
	    корневого URL, то он не сможет обрезать префикс URL из
	    шаблонов URL. Например, если настройки Apache похожи на
	    эти:
	    <screen>
	      <![CDATA[
<Location "/mysite/">
    SetHandler mod_python
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE mysite.settings
    PythonDebug On
</Location>
	      ]]>
	    </screen>
	    то все шаблоны URL должны начинаться с префикса
	    <token>/mysite/</token>. По этой причине мы обычно
	    рекомендуем разворачивать Django в корень домена или
	    виртуального хоста. Либо, как вариант, можно просто
	    <quote>сдвинуть</quote> все URL вниз на один уровень,
	    используя промежуточный файл со схемой URL:
	    <screen>
	      <![CDATA[
urlpatterns = patterns('',
    (r'^mysite/', include('normal.root.urls')),
)
	      ]]>
	    </screen>
	  </para>
	</note>
      </para>

    </section>

    <section id="&BASEID;.using-apache-mod_python.more-one">

      <title id="&BASEID;.using-apache-mod_python.more-one.title">
	Несколько проектов Django на одном сервере Apache
      </title>

      <para>
	Запустить несколько проектов Django на одном сервере Apache
	несложно. Это может понадобится, например, когда у
	независимого веб разработчика есть несколько клиентов и только
	один сервер.
      </para>

      <para>
	Для реализации данного подхода используется блок
	<token>VirtualHost</token>:
	<screen>
	  <![CDATA[
NameVirtualHost *

<VirtualHost *>
    ServerName www.example.com
    # ...
    SetEnv DJANGO_SETTINGS_MODULE mysite.settings
</VirtualHost>

<VirtualHost *>
    ServerName www2.example.com
    # ...
    SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
</VirtualHost>
	  ]]>
	</screen>
      </para>

      <para>
	Если необходимо установить два различных проекта в рамках
	одного и того же виртуального хоста, нужно принять меры, чтобы
	не допустить смешивания двух различных кэш-копий кода
	приложений. Используем директиву
	<token>PythonInterpreter</token>, чтобы указать в каждой
	директиве <token><![CDATA[<Location>]]></token> свой
	обработчик:
	<screen>
	  <![CDATA[
<VirtualHost *>
    ServerName www.example.com
    # ...
    <Location "/something">
        SetEnv DJANGO_SETTINGS_MODULE mysite.settings
        PythonInterpreter mysite
    </Location>

    <Location "/otherthing">
        SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
        PythonInterpreter mysite_other
    </Location>
</VirtualHost>
	  ]]>
	</screen>
      </para>

      <para>
	Значения параметров для директивы
	<token>PythonInterpreter</token> можно установить любые,
	главное, чтобы они отличались между собой для различных блоков
	<token><![CDATA[<Location>]]></token>.
      </para>

    </section>

    <section id="&BASEID;.using-apache-mod_python.dev-server">

      <title id="&BASEID;.using-apache-mod_python.dev-server.title">
	Запуск тестового сервера под mod_python
      </title>

      <para>
	Посколько mod_python кэширует загруженный Python код, то при
	развертывании Django приложений нужно помнить о необходимости
	рестартовать Apache каждый раз, когда в исходный код внесены
	изменения. Это быстро может надоесть, поэтому мы предлагаем
	способ бысто обойти это ограничение: просто добавьте директиву
	<token>MaxRequestsPerChild 1</token> в файл конфигурации,
	чтобы заставить Apache полностью перегружать все при каждом
	запросе. Только не нужно делать этого на рабочем сервере,
	иначе мы запретим вам использовать Django.
      </para>

      <para>
	Если вы относитесь к тем программистам, кто отлаживает код,
	используя беспорядочно разбросанные операторы
	<token>print</token> (как мы), учтите, что оператор
	<token>print</token> не работает в случае использования
	mod_python и результат его работы не появится в логе Apache,
	как, возможно, кое-кто ожидал. Для того, чтобы печатать
	отладочную информацию, рекомендуем использовать стандартный
	Python модуль <token>logging</token>. Более подробную
	информацию можно посмотреть тут: <ulink
	url="http://docs.python.org/lib/module-logging.html"/>. Альтернативным
	вариантом может быть вывод отладочной информации в шаблонах
	страниц сайта.
      </para>

    </section>

    <section id="&BASEID;.using-apache-mod_python.static-content">

      <title id="&BASEID;.using-apache-mod_python.static-content.title">
	Работа с Django и статическим контентом на одном сервере Apache
      </title>

      <para>
	Django не рекомендуется использовать для обслуживания запросов
	к статическим файлам (контенту); эту работу лучше оставить для
	веб сервера. Рекомендуется использовать отдельный веб сервер
	(на котором не работает Django) для обработки запросов к
	статической информации. Более подробная информация см. ниже в
	разделе "Масштабирование FIXME".
      </para>

      <para>
	Однако, если нет других вариантов, кроме работы со статическим
	контентом на том же сервере Apache, где развернут Django,
	необходимо отключить mod_python для отдельных частей сайта:
	<screen>
	  <![CDATA[
<Location "/media/">
    SetHandler None
</Location>
	  ]]>
	</screen>
      </para>

      <para>
	Вместо <token>/media/</token> необходимо указать корневой URL
	для статических файлов на вашем сайте.
      </para>

      <para>
	Можно использовать директиву
	<token><![CDATA[<LocationMatch>]]></token> и работать через
	регулярные выражения. Например, вот такая настройка
	конфигурации позволяет использовать Django от корня сайта, но
	полностью отключает Django для подкаталога
	<filename>media</filename>, а также для любого URL,
	оканчивающегося на <filename>.jpg</filename>,
	<filename>.gif</filename> или <filename>.png</filename>:
	<screen>
	  <![CDATA[
<Location "/">
    SetHandler mod_python
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE mysite.settings
</Location>

<Location "/media/">
    SetHandler None
</Location>

<LocationMatch "\.(jpg|gif|png)$">
    SetHandler None
</LocationMatch>
	  ]]>
	</screen>
      </para>

      <para>
	Во всех случаях необходимо настроить директиву
	<token>DocumentRoot</token>, чтобы Apache знал, где ему искать
	статические файлы.
      </para>

    </section>

    <section id="&BASEID;.using-apache-mod_python.error-handling">

      <title id="&BASEID;.using-apache-mod_python.error-handling.title">
	Обработка ошибок
      </title>

      <para>
	При использовании Apache/mod_python ошибки перехватываются на
	уровне Django &mdash; другими словами, они не передаются на
	уровень Apache и поэтому не появляются в логе ошибок Apache.
      </para>

      <para>
	Исключением тут будет случай, когда что-то серьёзно запорчено
	при установке Django. Тогда в броузере будет выдаваться
	страница с ошибкой <quote>Internal Server Error</quote> (код
	ошибки 500) и полный стек ошибки Python записывается в лог
	ошибок Apache. Такое сообщение занимает несколько строк. (Да,
	это выглядит некрасиво и неудобно для изучения, но так
	работает mod_python).
      </para>

    </section>

    <section id="&BASEID;.using-apache-mod_python.seg-fault">

      <title id="&BASEID;.using-apache-mod_python.seg-fault.title">
	Устранение ошибок, приводящих к падению Apache
      </title>

      <para>
	Иногда Apache падает после установки Django. Если это
	произошло, то практически всегда это результат одного из двух
	возможных случаев, не связанных непосредственно с Django:
	<itemizedlist>
	  <listitem>
	    <para>
	      Возможно, в приложении используется модуль
	      <token>pyexpat</token> (применяется для разбора XML),
	      который может конфликтовать с версией этого же модуля,
	      встроенной непосредственно в Apache. Подробнее
	      см. статью <quote>Expat заставляет Apache сбоить</quote>
	      по адресу <ulink
	      url="http://www.djangoproject.com/r/articles/expat-apache-crash/"/>.
	    </para>
	  </listitem>

	  <listitem>
	    <para>
	      Возможно, в текущей конфигурации одновременно
	      используются mod_python и mod_php на одном и том же
	      сервере Apache, а в качестве базы данных выступает
	      MySQL. В некоторых случаях это может привести к
	      конфликту версий для драйверов MySQL между Python и
	      PHP. Полная информация по данной проблеме доступна в
	      mod_python FAQ по адресу <ulink
	      url="http://www.djangoproject.com/r/articles/php-modpython-faq/"/>.
	    </para>
	  </listitem>
	</itemizedlist>
      </para>

      <para>
	Если после этого проблемы с mod_python продолжаются, следующим
	хорошим ходом будет создание <quote>скелета</quote> сайта под
	mod_python без подлючения библиотек Django. Это самый простой
	способ изолировать проблемы, специфические именно для
	mod_python. В статье <quote>Заставляем mod_python
	работать</quote> эта процедура детально описывается: <ulink
	url="http://www.djangoproject.com/r/articles/getting-modpython-working/"/>.
      </para>

      <para>
	На следующем этапе рекомендуем сделать тестовый скрипт и
	включить в него всё, что вы используете в Django приложении
	&mdash; представления, модели, шаблоны URL, конфигурацию RSS и
	т.п. Включите этот код в тестовую функцию обработчика и
	вызывайте тестовый URL. Если это приводит к проблеме, то
	считаем, что проблема где-то в коде, использующем
	Django. Комментируя одну за одной строки с
	<token>import</token>, мы доберемся до конкретного модуля,
	вызывающего ошибку. Далее то же самое проделываем с кодом
	модуля, пока не локализуем ошибку. Системные утилиты, такие,
	как <command>ldconfig</command> в Linux,
	<command>otool</command> в Mac OS и <token>ListDLLs</token>
	(от SysInternals) в Windows, помогут найти общие зависимости и
	возможные конфликты версий.
      </para>

    </section>

  </section>

  <section id="&BASEID;.using-apache-mod_wsgi">

    <title id="&BASEID;.using-apache-mod_wsgi.title">
      Использование Django с Apache и mod_wsgi
    </title>

    <para>
      Источники: <ulink
      url="http://code.google.com/p/modwsgi/wiki/QuickInstallationGuide"/>,
      <ulink
      url="http://ericholscher.com/blog/2008/jul/8/setting-django-and-mod_wsgi/"/>.
    </para>

    <para>
      Есть несколько причин для перехода с <token>mod_python</token>
      на <token>mod_wsgi</token>:
      <itemizedlist>
	<listitem>
	  <para>
	    <token>mod_python</token> больше не поддерживается разработчиком;
	  </para>
	</listitem>

	<listitem>
	  <para>
	    <token>mod_wsgi</token> требует меньше ресурсов для своей
	    работы и обладает большими возможностями в настройке.
	  </para>
	</listitem>
      </itemizedlist>
    </para>

    <section id="&BASEID;.using-apache-mod_wsgi.apache-reqs">

      <title id="&BASEID;.using-apache-mod_wsgi.apache-reqs.title">
	Поддерживаемые версии Apache
      </title>

      <para>
	Поддерживаются следующие версии Apache &mdash; 1.3, 2.0 и 2.2.
      </para>

      <para>
	При использовании Apache 1.3 можно динамически подгружать его
	модули. В случае, когда модули статически слинкованы с Apache,
	некоторые компоненты <token>mod_wsgi</token> будут работать
	некорректно.
      </para>

      <para>
	При использовании Apache 2.0 и 2.2 нет разницы, работаете вы с
	<token>prefork</token> или <token>worker</token> MPM.
      </para>

      <para>
	Чтобы иметь возможность <token>mod_wsgi</token> в режиме
	сервиса, надо использовать Apache 2.0 и 2.2, также
	соответствующие библиотеки Apache должны быть собраны с
	поддержкой потоков.
      </para>

      <para>
	На Linux, если Apache устанавливается из репозитория, следует
	установить для него пакеты разработчика.
      </para>

      <para>
	Для большинства дистрибутивов Linux, пакет разработчика для
	Apache 2.x называется <token>apache2-dev</token>, сам Apache
	находится в пакете <token>apache2</token>. Тем не менее,
	некоторые дистрибутивы различают пакеты разработчика по типу
	MPM, для которого они собраны. В таком случае, пакет может
	называться как <token>apache2-worker-dev</token> или
	<token>apache2-prefork-dev</token>. При использовании Apache
	2.x не стоит устанавливать пакет <token>apache-dev</token>,
	так как он относится к Apache 1.3.
      </para>

    </section>

    <section id="&BASEID;.using-apache-mod_wsgi.python-reqs">

      <title id="&BASEID;.using-apache-mod_wsgi.python-reqs.title">
	Поддерживаемые версии Python
      </title>

      <para>
	Можно использовать Python версий 2.3-2.5. Используемая версия
	Python должна быть собрана с поддержкой потоков.
      </para>

      <para>
	На Linux, если Python устанавливается из репозитария, следует
	установить для него пакеты разработчика.
      </para>

      <para>
	Желательно, чтобы Python был доступен в виде разделяемой
	библиотеки. Если это не ваш случай, то <token>mod_wsgi</token>
	будет требовать больше памяти и могут возникнуть конфликты с
	<token>mod_python</token> (если оба модуля будут загружены в
	одно время), что может привести к падению Apache.
      </para>

    </section>

    <section id="&BASEID;.using-apache-mod_wsgi.install">

      <title id="&BASEID;.using-apache-mod_wsgi.install.title">
	Установка модуля
      </title>

      <para>
	Пример установки модуля на Ubuntu:
	<screen>
	  <![CDATA[
# wajig search mod_wsgi
libapache2-mod-wsgi - Python WSGI adapter module for Apache

# wajig install libapache2-mod-wsgi
Чтение списков пакетов... Готово
Построение дерева зависимостей
Чтение информации о состоянии... Готово
Предлагаемые пакеты:
  apache2-mpm-worker apache2-mpm-event
НОВЫЕ пакеты, которые будут установлены:
  libapache2-mod-wsgi
Необходимо скачать 113kБ архивов.
Получено:1 http://ru.archive.ubuntu.com intrepid/universe libapache2-mod-wsgi 2.3-1 [113kB]
Получено 113kБ за 1s (111kБ/c)
...
 * Reloading web server config apache2
#
	  ]]>
	</screen>
      </para>

    </section>

    <section id="&BASEID;.using-apache-mod_wsgi.interface">

      <title id="&BASEID;.using-apache-mod_wsgi.interface.title">
	Интерфейс к модулю
      </title>

      <para>
	Создайте внутри вашего проекта каталог, а в каталоге файл
	<filename>django.wsgi</filename>. Например, в моём случае это
	будет так:
	<screen>
	  <![CDATA[
$ cd ~/development/cargo
$ mkdir apache
$ emacs apache/django.wsgi
	  ]]>
	</screen>
      </para>

      <para>
	Скопируйте нижеприведённый код в файл
	<filename>django.wsgi</filename>:
	<screen>
	  <![CDATA[
import os, sys
# место, где лежит джанго
sys.path.append('/home/rad/devel/django-trunk/')
# место, где лежит проект
sys.path.append('/home/rad/devel/')
# файл конфигурации проекта
os.environ['DJANGO_SETTINGS_MODULE'] = 'cargo.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
	  ]]>
	</screen>
      </para>

      <para>
	Вы создали интерфейс между Django и <token>WSGI</token>. Если
	после этого, вы начнёте получать сообщения об ошибках,
	допустим, что недоступен ваш проект или какой-то из его
	модулей, проверьте <token>sys.path</token>.
      </para>

    </section>

    <section id="&BASEID;.using-apache-mod_wsgi.config">

      <title id="&BASEID;.using-apache-mod_wsgi.config.title">
	Конфигурация сервера
      </title>

      <para>
	Откройте конфигурационный файл вашего сервер, например,
	<filename>/etc/apache2/sites-available/cargo.caml.ru</filename>
	и внесите в него изменения:
	<screen>
	  <![CDATA[
<VirtualHost *>
        DocumentRoot /var/www-cargo/
        ServerAdmin ruslаn.pоpоv@gmаil.cоm
        ServerName cargo

        WSGIScriptAlias / /home/rad/devel/cargo/apache/django.wsgi
        WSGIDaemonProcess cargo processes=2 maximum-requests=5 threads=1
        WSGIProcessGroup cargo

        ErrorLog "|/usr/sbin/rotatelogs /var/log/apache2/cargo.error.%Y-%m-%d.log 86400"
        CustomLog "|/usr/sbin/rotatelogs /var/log/apache2/cargo.access.%Y-%m-%d.log 86400" combined
        ServerSignature On

        Alias /css/     "/home/rad/django/cargo/css/"
        Alias /js/      "/home/rad/django/cargo/js/"
        Alias /pics/    "/home/rad/django/cargo/pics/"
        Alias /djangobook/pics/ "/home/rad/django/cargo/djangobook/pics/"
        Alias /media/   "/home/rad/django/cargo/media/"
        Alias /adminmedia/ "/home/rad/devel/django-trunk/django/contrib/admin/media/"
</VirtualHost>
	  ]]>
	</screen>
      </para>

      <para>
	Особое внимание надо уделить трём строкам, которые начинаются
	с <token>WSGI...</token>. Строка с
	<token>WSGIScriptAlias</token> ссылается на файл, который был
	создан ранее. Другие две строки необходимы в случае, когда вы
	размещаете на сервере несколько виртуальных сайтов.
	<note>
	  <para>
	    Следует принять во внимание то, что директива
	    <token>WSGIDaemonProcess</token> и соответствующие
	    элементы не доступны под ОС MS Windows, а также при
	    использовании Apache 1.3. <ulink
	    url="http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives">Подробности...</ulink>
	  </para>
	</note>
      </para>

      <para>
	А самое главное, это не забыть проверить, что в Apache
	подгружается <token>mod_wsgi</token>:
	<screen>
	  <![CDATA[
# ls -l /etc/apache2/mods-enabled/ | grep wsgi
lrwxrwxrwx 1 root root 27 2009-02-18 22:41 wsgi.conf -> ../mods-available/wsgi.conf
lrwxrwxrwx 1 root root 27 2009-02-18 22:41 wsgi.load -> ../mods-available/wsgi.load
	  ]]>
	</screen>
      </para>

    </section>

  </section>

</chapter>