Документация Django 1.6
Развертывание 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.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 1.9
Развертывание 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 при котором каждый сайт запущен в отдельном фоновом процессе.
Исправляем UnicodeEncodeError при загрузке файлов
Если вы получили UnicodeEncodeError при загрузке файлов, названия которых содержат не ASCII символы, убедитесь, что Apache настроен для загрузки таких файлов:
Настройки обычно находятся в /etc/apache2/envvars .
Подробности смотрите в разделе Файлы .
Использование 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 , к примеру:
Чтобы проект был доступен через подкаталог ( https://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.
Введение в WSGI-серверы: Часть первая
Данная статья является переводом статьи Кевина Голдберга «An Introduction to Python WSGI Servers: Part 1» blog.appdynamics.com/engineering/an-introduction-to-python-wsgi-servers-part-1 с небольшими дополнениями от переводчика
Краткая история серверов WSGI Python
WSGI-серверы появились потому, что веб-серверы в то время не умели взаимодействовать с приложениями, написанными на языке Python. WSGI (произносится как «whiz-gee» с твердым «g») был разработан Филиппом Дж. Эби (вместе с Ян Бикинг и др.) В начале 2000-х годов. Модуль Apache, известный как mod_python, разработанный Григорием Трубецким в конце 90-х годов, на тот момент обрабатывал большую часть Python-приложений. Однако mod_python не был официальной спецификацией. Он был просто создан, чтобы разработчики могли запускать код Python на сервере. К сожалению, такой подход был небезопасным и разработчики начали искать новое решение.
WSGI(Web-Server Gateway Interface) является потомком CGI(Common Gateway Interface). Когда веб начал развиваться, CGI разрастался из-за поддержки огромного количества языков и из-за отсутствия других решений. Однако, такое решение было медленным и ограниченным. WSGI был разработан как интерфейс для маршрутизации запросов от веб-серверов(Apache, Nginx и т.д.) на веб-приложения.
Сервер и веб-приложение
В простейшем случае WSGI состоит из двух основных сущностей:
- Веб-сервер (Nginx, Apache и т. д.);
- Веб-приложение, написанное на языке Python.
Принцип работы:
Веб-сервер исполняет код и отправляет связанную с http-запросом информацию и callback-функцию в веб-приложение. Затем запрос на стороне приложения обрабатывается и высылается ответ на веб-сервер.
Периодически между веб-сервером и веб-приложением существуют одна или несколько промежуточных прослоек. Такие прослойки позволяют осуществить, например, балансировку между несколькими веб-приложениеми или предпроцессинг(предобработку) отдаваемого контента.
Вот примеры фреймворков, поддерживающих WSGI:
Почему именно WSGI?
Возможно Вы спросите «Хорошо, но почему именно WSGI?». На это есть несколько причин:
- WSGI-сервера были разработаны чтобы обрабатывать множество запросов одновременно. А фреймворки не предназначены для обработки тысяч запросов и не дают решения того, как наилучшим образом маршрутизировать их(запросы) с веб-сервера.
- WSGI ускоряет разработку веб-приложений написанных на языке Python. Если в разработке веб-приложения Вы используете фреймворк(Django или что-то ещё) Вам не нужно беспокоиться о том, как Ваша конкретная инфраструктура использует стандарт WSGI.
- WSGI дает Вам гибкость в изменении компонентов веб-стека без изменения приложения, которое работает с WSGI.
WSGI-серверы выпускаются в различных вариациях. Одни нацелены на fullstack-решение, в то время как другие хорошо подходят для конкретных фреймворков. Например, Gunicorn работает с Django прямо из коробки. Вот более пристальный взгляд на шесть WSGI-серверов на рынке сегодня: Bjoern, uWSGI, mod_wsgi, Meinheld, CherryPy и Gunicorn.
Bjoern
Bjoern — это асинхронный WSGI-сервер, написанный на C. Написанный с нуля, чтобы быть небольшим и быстрым, он был разработан с использованием http_parser от Райана Даля (создателя Node.js) и цикла событий Libev от Марка Леманна.
С размером загрузки всего 18 КБ он состоит из менее 800 строк кода. Он занимает менее 1 МБ оперативной памяти и не использует корутины или потоки. Bjoern полностью совместим с WSGI и считается одним из самых высокопроизводительных WSGI-серверов.
Bjoern поддерживает постоянные соединения и может привязываться к Unix-сокетам или TCP-адресам. Bjoern считается более быстрым, чем Gunicorn, и менее раздутым, чем uWSGI и Meinheld. Один из недостатков данного сервера — отсутствие нормальной документации с понятными примерами.
uWSGI
uWSGI был разработан компанией Unbit(Италия) с целью стать fullstack-решением, способным создавать услуги хостинга. Он назван в честь стандарта WSGI и создавался как плагин для одного из проектов компании.
Широкий и постоянно развивающийся проект, uWSGI позволяет делать гораздо больше, чем веб-приложения для хостинга. Многие находят uWSGI мощным инструментом, в то время как другие считают его несколько раздутым. Начиная с версии 2.0 uWSGI поддерживает также запуск веб-приложений на языках Lua, Perl, Ruby и других.
mod_wsgi
mod_wsgi — модуль HTTP-сервера Apache, разработанный Грэмом Дамплтоном (ранее, один из разработчиков mod_python), предоставляет интерфейс WSGI для веб-приложений. Совместим с версиями языка Python2 и Python3. Создан в качестве альтернативы другим решениям для интеграции веб-приложений, таких как CGI, FastCGI и mod_python. Может быть установлен как модуль Apache или через mod_wsgi express. Второй способ упрощает установку для разработчиков Python, которые не так хорошо знакомы с Apache. Другие преимущества:
• Вы не нуждаетесь в root-правах при полной установке.
• Создается локальная среда, что снижает риск негативного воздействия на существующие настройки.
Развитие mod_wsgi как проекта может показаться медленным из-за того, что модуль разрабатывается одним разработчиком. Другим недостатком является то, что документация в настоящее время плохо организована и может быть устаревшей.
В настоящее время основное внимание уделяется упрощению реализации Apache с использованием mod_wsgi в средах с использованием Docker.
Meinheld
Созданный Ютака Мацубара, Meinheld является сервером, совместимым с WSGI, который использует мощь picoev и greenlet для выполнения асинхронных операций ввода-вывода. Он может использоваться с автономным HTTP-сервером или через Gunicorn.
Meinheld имеет зависимость от стороннего компонента, называемого greenlet.
Репозиторий с исходным кодом расположен на GitHub. Meinheld поддерживает веб-сокеты и включает в себя несколько monkeypatches над другими модулями для расширения функциональности.
CherryPy
CherryPy — более известен как минималистичный Python-фреймворк для написания веб-приложений, CherryPy также поставляется с WSGI thread-pooled веб-сервером и поддержкой протокола HTTP / 1.1. Команда разработчиков CherryPy описывает свой веб-сервер как production-ready, высокоскоростной, thread-pooled HTTP-сервер. Он имеет:
• Быструю, простую настройку;
• Возможность масштабирования;
• Небольшое и простое в использовании решение для ваших приложений Python;
• Поддержка SSL.
CherryPy отличает себя от более известных WSGI-серверов из-за простоты использования и удобства для разработчиков. Вы можете написать небольшое веб-приложение в течении нескольких минут, запустив его в несколько процессов и создав только один файл с именем server.py. Объединив CherryPy с Nginx в качестве прокси-сервера, Вы получите надежный способ обслуживания своих веб-приложений. CherryPy был создан Реми Делоном. Он хотел создать структуру, которая была бы максимально близка к главным принципам разработки на языке Python.
Gunicorn
Gunicorn — это WSGI-сервер, созданный для использования в UNIX-системах. Название — сокращенная и комбинированная версия слов «Green Unicorn». На самом сайте проекта есть зеленый единорог. Gunicorn был перенесен из проекта «Unicorn» из языка Ruby. Он относительно быстрый, ресурсоёмкий, легко запускается и работает с широким спектром веб-фреймворков.
Команда разработчиков рекомендует использовать Gunicorn в связке с Nginx, где Nginx используется в качестве прокси-сервера.