Документация Django 1.8
Развертывание 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 указывает местоположение ваших приложений, ( / обозначает корневую директорию), вторым значением указывается расположение файла “WSGI” – см.ниже – в вашей системе, как правило, в корне проекта. (в примере это mysite ). Эти настройки позволят Apache обрабатывать любой запрос из директории, указанной как базовая с помощью WSGI-приложения, хранящегося в ней.
WSGIPythonPath гарантирует, что ваш проект доступен для импорта; иначе говоря, что команда import mysite сработает.
Значение просто предоставляет Apache доступ к файлу wsgi.py .
Далее следует удостовериться, что файл wsgi.py существует. Начиная с версии Django 1.4 команда startproject создаёт его; в противном случае вы можете создать этот файл самостоятельно. См. Развёртывание с WSGI, чтобы узнать изначальное содержимое файла и то, какие настройки вы можете добавить.
Если несколько сайтов на Django запущены в одном процессе mod_wsgi, они все будут использовать настройки сайта, который первый загрузился. Это можно исправить, поменяв:
или используя mod_wsgi daemon mode при котором каждый сайт запущен в отдельном фоновом процессе.
Использование virtualenv¶
Если вы установили зависимости проекта с помощью virtualenv, вам следует добавить в пути Python путь к директории site-packages , находящейся в вашем виртуальном окружении. Для этого добавьте дополнительный путь к WSGIPythonPath , разделив его двоеточием, если вы используете UNIX-системы, или точкой с запятой, если вы используете Windows. Если путь содержит пробелы, вся строка для WSGIPythonPath должна быть экранирована:
Убедитесь в том, что путь к виртуальному окружению указан верно и замените python3.X на используемую вами версию Python (например, python3.4 ).
Использование mod_wsgi в режиме демона¶
“Режим демона” рекомендуемый режим для запуска mod_wsgi (но не на ОС Windows). Для создания требуемой группы процесса-демона и передачи управления Django вы должны добавить директивы WSGIDaemonProcess и WSGIProcessGroup . Еще одно важное дополнение: при использовании данной конфигурации в режиме демона вы не сможете работать с WSGIPythonPath ; вместо этого укажите опцию python-path , чтобы использовать возможности WSGIDaemonProcess , к примеру:
Чтобы проект был доступен через подкаталог ( http://example.com/mysite в этом примере), вы можете указать в настройках WSGIScriptAlias :
Обратитесь к официальной документации mod_wsgi , чтобы узнать подробнее о настройке в режиме демона.
Обслуживание файлов¶
Django не должен обрабатывать файлы самостоятельно; эта задача передаётся любому выбранному вами веб-серверу.
Мы рекомендуем использовать отдельный веб-сервер – то есть тот, что идёт не в поставке с самим Django – для обслуживания медиа-файлов. Вот несколько неплохих вариантов:
Однако, если у вас нет возможности обслуживать медиа-файлы на том же виртуальном хосте ( VirtualHost ) что и Django, вы можете настроить Apache на обработку некоторых URL-запросов как статических и медиа-файлов, используя интерфейс mod_wsgi.
Это пример настройки Django в корне сайта, где явно указаны пути к robots.txt , favicon.ico , различным CSS-файлам, а также директориям /static/ и /media/ для их обработки как статических файлов. Все прочие URL-адреса будут обработаны при помощи mod_wsgi:
Если вы используете 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 ), но есть и несколько иных подходов:
Создание символьной ссылки на статические файлы, которые должны содержаться в корневом каталоге (для этого может потребоваться добавление +FollowSymLinks в конфигурации Apache).
Использование директивы Alias , как было показано выше, для создания псевдонима соответствующего URL-адреса (вероятно это будет STATIC_URL + admin/ ), указывающего на фактическое расположение файлов.
Копирование директории с административной статикой в корень Apache.
Идентификация пользовательской базы данных с Apache¶
Django предоставляет возможность идентификации пользователей средствами Apache см. mod_wsgi authentication documentation.
Если вы столкнулись с ошибкой UnicodeEncodeError ¶
Если вы воспользовались настройками стандартной интернационализации Django (см. Интернационализация и локализация) и позволили пользователям загружать файлы, то должны убедиться, что среда для запуска Apache настроена для обработки не ASCII символов.Если это не так, будет возбуждено исключение UnicodeEncodeError при вызове функций, подобных os.path с именами файлов, содержащими отличные от ASCII символы.
Чтобы избежать проблем, среда, в которой запущен Apache, должна содержать параметры, аналогичные следующим:
Обратитесь к документации вашей операционной системы, чтобы подобрать соответствующий синтаксис и настроить расположение конфигурационных файлов; /etc/apache2/envvars является общей для Unix-like систем. После внесения соответствующих изменений перезапустите Apache.
Документация Django 3.0
Развертывание Django с Apache и mod_wsgi это испытанный способ установки на «боевой» веб-сервер.
mod_wsgi является модулем веб-сервера Apache, который может взаимодействовать с любым приложением Python, в том числе Django. Django работает с любой версией Apache, поддерживающей mod_wsgi .
Базовая конфигурация¶
После того как вы установите и активируете mod_wsgi отредактируйте файл httpd.conf веб-сервера Apache, изменив его следующим образом. Если вы используете Apache версии ниже чем 2.4, замените Require all granted` на Allow from all и добавьте выше Order deny,allow .
Значение WSGIScriptAlias указывает местоположение ваших приложений, ( / обозначает корневую директорию), вторым значением указывается расположение файла «WSGI» – см.ниже – в вашей системе, как правило, в корне проекта. (в примере это mysite ). Эти настройки позволят Apache обрабатывать любой запрос из директории, указанной как базовая с помощью WSGI-приложения, хранящегося в ней.
Если вы установили Python зависимости проекта в virtualenv, добавьте путь к виртуальному окружению, используя WSGIPythonHome . Смотрите справочник по mod_wsgi virtualenv.
WSGIPythonPath гарантирует, что ваш проект доступен для импорта; иначе говоря, что команда import mysite сработает.
Значение просто предоставляет Apache доступ к файлу wsgi.py .
Далее следует удостовериться, что файл wsgi.py существует. Начиная с версии Django 1.4 команда startproject создаёт его; в противном случае вы можете создать этот файл самостоятельно. См. Развёртывание с WSGI , чтобы узнать изначальное содержимое файла и то, какие настройки вы можете добавить.
Если несколько сайтов на Django запущены в одном процессе mod_wsgi, они все будут использовать настройки сайта, который первый загрузился. Это можно исправить, поменяв:
или используя mod_wsgi daemon mode при котором каждый сайт запущен в отдельном фоновом процессе.
Исправляем UnicodeEncodeError при загрузке файлов
Если вы получили UnicodeEncodeError при загрузке файлов, названия которых содержат не ASCII символы, убедитесь, что Apache настроен для загрузки таких файлов:
Настройки обычно находятся в /etc/apache2/envvars .
Подробности смотрите в разделе Файлы .
Использование mod_wsgi в режиме демона¶
«Режим демона» — рекомендуемый режим для запуска mod_wsgi (но не на ОС Windows). Для создания требуемой группы процесса-демона и передачи управления Django вы должны добавить директивы WSGIDaemonProcess и WSGIProcessGroup . Еще одно важное дополнение: при использовании данной конфигурации в режиме демона вы не сможете работать с WSGIPythonPath ; вместо этого укажите опцию python-path , чтобы использовать возможности WSGIDaemonProcess , к примеру:
Чтобы проект был доступен через подкаталог ( https://example.com/mysite в этом примере), вы можете указать в настройках WSGIScriptAlias :
Обратитесь к официальной документации mod_wsgi , чтобы узнать подробнее о настройке в режиме демона.
Обслуживание файлов¶
Django не должен обрабатывать файлы самостоятельно; эта задача передаётся любому выбранному вами веб-серверу.
Мы рекомендуем использовать отдельный веб-сервер – то есть тот, что идёт не в поставке с самим Django – для обслуживания медиа-файлов. Вот несколько неплохих вариантов:
Однако, если у вас нет возможности обслуживать медиа-файлы на том же виртуальном хосте ( VirtualHost ) что и Django, вы можете настроить Apache на обработку некоторых URL-запросов как статических и медиа-файлов, используя интерфейс mod_wsgi.
Это пример настройки Django в корне сайта, где явно указаны пути к robots.txt , favicon.ico , а также директориям /static/ и /media/ для их обработки как статических файлов. Все прочие URL-адреса будут обработаны при помощи mod_wsgi:
Если вы используете 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 ), но есть и несколько иных подходов:
- Создание символьной ссылки на статические файлы, которые должны содержаться в корневом каталоге (для этого может потребоваться добавление +FollowSymLinks в конфигурации Apache).
- Использование директивы Alias , как было показано выше, для создания псевдонима соответствующего URL-адреса (вероятно это будет STATIC_URL + admin/ ), указывающего на фактическое расположение файлов.
- Копирование директории с административной статикой в корень Apache.
Идентификация пользовательской базы данных с Apache¶
Django предоставляет возможность идентификации пользователей средствами Apache см. mod_wsgi authentication documentation .
Документация Django 1.5.2
Развертывание 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 указывает местоположение ваших приложений, ( / обозначает корневую директорию), вторым значением указывается расположение файла “WSGI” – см.ниже – в вашей системе, как правило, в корне проекта. (в примере это mysite ). Эти настройки позволят Apache обрабатывать любой запрос из директории, указанной как базовая с помощью WSGI-приложения, хранящегося в ней.
WSGIPythonPath гарантрует, что ваш проект доступен для импорта; иначе говоря, что команда import mysite сработает.
Значение просто предоставляет Apache доступ к файлу wsgi.py .
Далее следует удостовериться, что файл wsgi.py существует. Начиная с версии Django 1.4 команда startproject создаёт его; в противном случае вы можете создать этот файл самостоятельно. См. Развёртывание с WSGI, чтобы узнать изначальное содержимое файла и то, какие настройки вы можете добавить.
Если несколько сайтов на Django запащены в одном процессе mod_wsgi, они все будут использовать настройки сайта, который первый загрузился. Это можно исправить поправив « wsgi.py«(смотрите комментарий в файле), или используя mod_wsgi daemon mode при котором каждый сайт запущен в отдельном фоновом процессе.
Использование virtualenv¶
Если вы установили зависимости проекта с помощью virtualenv вам следует добавить путь к директории site-packages , находящейся в вашем виртуальном окружении. Для этого добавьте дополнительный путь к WSGIPythonPath , разделив его двоеточием:
Убедитесь в том, что путь к виртуальному окружению указан верно и замените python2.X на используемую вами версию Python (например, python2.7 ).
Использование mod_wsgi в режиме демона¶
“Режим демона” рекомендуемый режим для запуска mod_wsgi (но не на ОС Windows). Для создания требуемой группы процесса-демона и передачи управления Django вы должны добавить директивы WSGIDaemonProcess и WSGIProcessGroup . Еще одно важное дополнение: при использовании данной конфигурации в режиме демона вы не сможете работать с WSGIPythonPath ; вместо этого укажите сопцию python-path , чтобы использовать возможности WSGIDaemonProcess , к примеру:
Обратитесь к официальной документации mod_wsgi , чтобы узнать подробнее о настройке в режиме демона.
Обслуживание файлов¶
Django не должен обрабатывать файлы самостоятельно; эта задача передаётся любому выбранному вами веб-серверу.
Мы рекомендуем использовать отдельный веб-сервер – то есть тот, что идёт не в поставке с самим Django – для обслуживания медиа-файлов. Вот несколько неплохих вариантов:
Однако, если у вас нет возможности обслуживать медиа-файлы на том же виртуальном хосте ( VirtualHost ) что и Django, вы можете настроить Apache на обработку некоторых URL-запросов как статических и медиа-файлов, используя интерфейс mod_wsgi.
Это пример настройки Django в корне сайта, где явно указаны пути к robots.txt , favicon.ico , различным CSS-файлам, а также директориям /static/ и /media/ для их обработки как статических файлов. Все прочие URL-адреса будут обработаны при помощи mod_wsgi:
Обслуживание административных файлов¶
Заметьте, что сервер разработки Django автоматически обрабатывает административные приложения (и любые другие установленные приложения ), но это не годится для случая с другим сервером разработки. Вы сами несете ответственность за настройку Apache или любого другого сервера при использовании его для обслуживания административных файлов.
Административные файлы находятся по пути ( django/contrib/admin/static/admin ) в директории, где установлен Django.
Мы настоятельно рекомендуем использовать django.contrib.staticfiles для работы со статикой административного раздела (так же, как и в случае с веб-сервером, как это описано выше); это означает использование команды collectstatic для сбора статики в STATIC_ROOT , и настройку веб-сервера для обслуживания STATIC_ROOT в STATIC_URL ), но есть и несколько иных подходов:
Создание символьной ссылки на статические файлы, которые должны содержаться в корневом каталоге (для этого может потребоваться добавление +FollowSymLinks в конфигурации Apache).
Использование директивы Alias , как было показано выше, для создания псевдонима соответсвующего URL-адреса (вероятно это будет STATIC_URL + admin/ ), указывающего на фактическое расположение файлов.
Копирование директории с административной статикой в корень Apache.
Идентификация пользовательской базы данных с Apache¶
Django предоставляет возможность идентификации пользовательей средствами Apache см. mod_wsgi authentication documentation.
Если вы столкнулись с ошибкой UnicodeEncodeError ¶
Если вы воспользовались настройками стандартной интернационализации Django (см. Интернационализация и локализация) и позволили пользователям загружать файлы, то должны убедиться, что среда для запуска Apache настроена для обработки не ASCII символов.Если это не так, будет возбуждено исключение UnicodeEncodeError при вызове функций, подобных os.path() с именами файлов, содержащими отличные от ASCII символы.
Чтобы избежать проблем, среда, в которой запущен Apache, должна содержать параметры, аналогичные следующим:
Обратитесь к документации вашей операционной системы, чтобы подобрать соответствующий синтаксис и настроить расположение конфигурационных файлов; /etc/apache2/envvars является общей для Unix-like систем. После внесения соответствующих изменений перезапустите Apache.