Для Django разработано немало серверов, потому трудно понять, какая установка подходит именно вам. Каждый из серверов имеет свои преимущества и недостатки. В этой статье мы рассмотрим наиболее распространенные серверы Django.
1: Сервер разработки Django
Сервер разработки Django поставляется в комплекте с Django и запускается с помощью следующей команды:
django-admin.py runserver
Эта команда запускает легкий веб-сервер, работающий по умолчанию через localhost по порту 8000. Чтобы изменить IP и порт, передайте новые значения в качестве аргументов:
django-admin.py runserver 10.0.0.150:8001
После запуска этой команды веб-сервер будет обслуживать приложение Django по IP-адресу 10.0.0.150 и порту 8001.
Сервер разработки Django предназначен исключительно для среды разработки. Он не подходит для производственной среды, как сказано в официальной документации Django. Сервер разработки предлагает вам простой способ протестировать приложение в среде разработки, не тратя время и ресурсы на установку и настройку полноценного веб-сервера.
Сервер разработки Django выгодно отличается от остальных своей легкостью и простотой в использовании. Он обслуживает статические файлы приложения, не собирая их в каком-то конкретном месте. Сервер разработки перезапускается при каждом сохранении файлов. Это полезно, потому что большинство веб-серверов для Python кэшируют приложение, но требуют перезагрузки для кэширования новой версии кода.
Очевидным недостатком сервера разработки Django является его непригодность в среде производства. Он не предназначен для обработки большого количества запросов.
В целом же, сервер разработки – отличный вариант для тех, кто хочет быстро начать работу с Django.
2: mod_wsgi
mod_wsgi – самый популярный модуль адаптера WSGI Python для Apache. Его рекомендуется использовать, если приложение обслуживается веб-сервером Apache.
После установки mod_wsgi его довольно просто внедрить. Просто добавьте следующую строку в виртуальный хост Apache:
WSGIScriptAlias /yourapp /opt/yourenv/yourapp.wsgi
Первый аргумент директивы WSGIScriptAlias – точка монтирования URL. К примеру, если виртуальный хост предназначен для домена mydomain.com, приложение будет отображаться по адресу http://mydomain.com/yourapp.
Если приложение Django находится вне каталогов, в которых Apache ищет файлы, вам также нужно добавить в виртуальный хост следующее:
<Directory /opt/yourenv>
Order allow,deny
Allow from all
</Directory>
Обратите внимание: если вы хотите установить приложение WSGI в корень домена, вы можете использовать «/», но тут есть нюанс. В таком случае все статические файлы, найденные в DocumentRoot, будут обслуживаться не Apache, а скорее приложением WSGI. Чтобы обойти это, просто укажите статические файлы с помощью директивы Alias:
Alias /static/ /opt/yourenv/static/
Как и в случае с директивой WSGIScriptAlias, первым аргументом является точка монтирования. Второй аргумент – путь к каталогу, в котором хранятся все статические файлы.
Преимуществом mod_wsgi является его простая интеграция с Apache. Это отлично подходит для всех, кто использует Apache в качестве основного веб-сервера.
Недостаток mod_wsgi заключается в том, что он может работать только с Apache. Поэтому, если вы используете другой веб-сервер – NGINX, Lighttpd, Cherokee – вы не сможете работать с этим модулем. Кроме того, mod_wsgi немного тяжелее других серверов.
3: uWSGI
uWSGI – это сервер, который реализует протокол WSGI для связи с другими веб-серверами (Nginx, Apache, Cherokee и т. д.). Его цель – интерпретация кода Python, пока веб-сервер обрабатывает статические файлы и другие запросы. uWSGI был написан специально для Python, поэтому установить его можно с помощью следующей команды:
sudo pip install uwsgi
Внедрить uWSGI в приложение Django довольно просто. На сайте проекта Django есть отличная документация по этой теме (вы можете найти ее здесь).
Как только вы установите и запустите uWSGI, как показано в документации Django, останется только проксировать на uWSGI запросы с основного веб-сервера. Метод будет зависеть от вашего веб-сервера, но, как правило, очень это просто.
Плюсом uWSGI является то, что он очень легкий, работает отдельно от веб-сервера (чтобы не перегружать его процессы) и его относительно легко настроить.
Некоторые из недостатков – это расходы, связанные с необходимостью создания отдельного сервера, и необходимость проксирования запросов на uWSGI. Если вы готовы покопаться в конфигурации, uWSGI – отличный вариант.
4: Gunicorn
Gunicorn – это HTTP-сервер Python WSGI, очень похожий на uWSGI. Сервер Gunicorn прост в настройке и легко интегрируется с Django. Он устанавливается так:
sudo pip install gunicorn
Читайте также: Установка и настройка Django с Postgres, Nginx и Gunicorn
Как и uWSGI, Gunicorn проксирует запросы основного веб-сервера. Настройка проксирования в Gunicorn не легче, чем в uWSGI.
Сервер Gunicorn также очень легкий. Быстрее ли он, чем uWSGI? Это спорный вопрос. Во многом результат зависит от настройки серверов. Оба они могут предоставить впечатляющую производительность, хотя некоторые пользователи отмечают, что Gunicorn лучше справляется с высокой нагрузкой.
Недостатки Gunicorn такие же, как и у uWSGI (хотя некоторые считают, что Gunicorn легче настраивается, чем uWSGI).
Заключение
Данная статья охватывает только самые базовые серверы Django. С остальными серверами – Flup, FastCGI, mod_python и т.п. – вы можете ознакомиться самостоятельно.
Flup не очень широко используется, поэтому его устанавливать не рекомендуется. Модуль mod_python для Apache работает нормально, но в большинстве документаций рекомендуется использовать modwsgi.
Итак, какой же сервер лучше? Ответ на этот вопрос зависит исключительно от вашей среды и вашего приложения. Если вы любите работать с Apache и не хотите долго возиться с настройкой и интеграцией, используйте mod_wsgi. Если приложение обслуживается другим веб-сервером, выберите uWSGI или Gunicorn. Оба сервера отлично справятся с обслуживанием приложения Django. В среде разработки обязательно используйте встроенный сервер Django для тестирования работы приложения.
Читайте также: