wsgi django что это
Введение в 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 состоит из двух основных сущностей:
Принцип работы:
Веб-сервер исполняет код и отправляет связанную с http-запросом информацию и callback-функцию в веб-приложение. Затем запрос на стороне приложения обрабатывается и высылается ответ на веб-сервер.
Периодически между веб-сервером и веб-приложением существуют одна или несколько промежуточных прослоек. Такие прослойки позволяют осуществить, например, балансировку между несколькими веб-приложениеми или предпроцессинг(предобработку) отдаваемого контента.
Вот примеры фреймворков, поддерживающих WSGI:
Почему именно WSGI?
Возможно Вы спросите «Хорошо, но почему именно WSGI?». На это есть несколько причин:
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 используется в качестве прокси-сервера.
Django на production. uWSGI + nginx. Подробное руководство
Перед вами руководство по настройке production окружения для Django. Здесь будут описаны необходимые шаги по настройке Django, uWSGI и nginx. Руководство охватывает все три компонента — полный стек серверного ПО для веб-приложений.
Подразумевается, что вы используете Unix-подобную операционную систему и менеджер пакетов, эквивалентный aptitude. Найти эквивалент aptitude почти для любой операционной системы, в том числе и для Mac OS X, для вас не составит никакого труда.
Руководство написно для версий Django 1.4 или выше. Если вы используете более раннюю версию, то вам придется самостоятельно найти wsgi модуль для нее. Также вы заметите, что файловая структура проекта будет немного отличаться от представленной здесь.
Общая идея
Веб-сервер может по запросу отдавать пользователям файлы из своей файловой системы, однако он не может напрямую работать с Djangо приложениями. Веб-серверу нужен интерфейс, который будет запускать Django приложение, передавать ему запрос от пользователя и возвращать ответ.
Для выполнения этих задач был разработан Web Server Gateway Interface — WSGI — стандарт взаимодействия Python программ и веб-сервра.
uWSGI — одна из реализаций WSGI. В этом руководстве мы установим и настроим uWSGI для создания Unix сокета и взаимодействия с веб-сервером по протоколу WSGI.
Полный стек компонентов будет выглядеть следующим образом:
Перед установкой uWSGI
virtualenv
Создадаем и активируем виртуальное окружение для софта, который нам будет необходим (ниже я расскажу, как установить uwsgi глобально):
Django
Устонавливаем Django в наше виртуальное окружение:
Создаем новый проект и переходим в его корневую папку:
Домен и порт
В этом руководстве мы будем использовать для нашего учебного проекта домен yourserver.com. Вам нужно будет заменить его на собственное доменное имя или IP адрес вашего сервера.
Для получения запросов от пользователей мы будем использовать порт 8000. Вы можете использовать любой другой порт. Я выбрал именно 8000, потому что его использование не приведет к конфликтам с другими задачами, выполняемыми сервером.
Установка и базовая настройка uWSGI
Установка uWSGI в виртуальное окружение
Один из хороших способов установить uWSGI:
Нам понадобятся Python development пакеты. Если вы используете Debian или основнную на Debian операционную систему (например, Ubuntu или Mint), вам нужно установить пакет pythonX.Y-dev, где X.Y — нужная вам версия Python.
Проверка
Создаем файл test.py:
Проверка работы Django приложения
Теперь сделаем так, чтобы uWSGI работал с Django приложением, а не с файлом test.py.
Проверим, что только что созданный проект mysite запускается на сервере для разработки:
Если проект запустился, останавливаем сервер для разработки и запускаем uWSGI следующим образом:
Это нехорошо, что комьютер пользователя на прямую обращается к uWSGI. Между пользователем и uWSGI должен находиться веб-сервер.
Устновка и базовая настройка nginx
Установка и запуск nginx
Если у вас занят восьмидесятый порт, измените конфигурацию nginx так, чтобы он использовал какой-нибудь другой (в этом руководстве nginx будет использовать порт 8000).
Конфигурация nginx для работы с Django
Нам понадобится файл uwsgi_params, который можно взять здесь: github.com/nginx/nginx/blob/master/conf/uwsgi_params.
Скачиваем его в корневую папку нашего проекта.
Создаем файл mysite_nginx.conf:
Этот конфигурационный файл указывает nginx, что он должен отдавать пользователям медиа и статик файлы из файловой системы, а все остальные запросы перенаправлять в Django приложение. В больших проектах лучше использовать два сервера: один для обслуживания статик и медиа файлов, а другой для Django приложения. С небольшими, и тем более с учебными проектами, справится и один сервер.
Статика в одном месте
Перед запуском nginx поместим всю статику в папку static. Для этого добавляем в файл mysite/settings.py следующую строку:
И выполняем команду:
Проверка осблуживания статики и медиа
В браузере переходим по адресу yourserver.com:8000/media/media.png и, если видим наш файл, значит мы все сделали правильно.
nginx + uWSGI + test.py
Настраиваем взаимодействие nginx и test.py через uSWGI.
Unix сокеты вместо веб-портов
До этого мометна мы использовали сокет, привязанный к TCP порту (я называл его веб-порт), потому что так было проще, но на деле рекомендуется использовать Unix-сокет из-за преимущества в производительности.
Редактируем mysite_nginx.conf следующим образом:
И перезапускаем nginx:
На этот раз опция socket указывает на файл.
Открываем в браузере yourserver.com:8000/
Если не заработало
Проверьте лог ошибок nginx, скорее всего он находится в файле var/log/nginx/error.log
Если найдете там что-то похожее на
значит есть проблема с правами доступа к файлу mysite.sock. Необходимо сделать так, чтобы nginx имел разрешение на использование этого файла.
Попробуйте запустить uWSGI так:
Чтобы проблем с доступом в будущем не было, добавьте вашего пользователя в группу www-data.
Информация, которую uWSGI выводит в терминал, полезна при поиске и исправлении возможных ошибок или неисправностей.
nginx + uWSGI + Django
В браузере переходим на yourserver.com:8000/ и видим стартовую страницу Django.
Мы собрали всю цепочку, но настройка еще не закончена, идем дальше.
Конфигурация uWSGI через ini файл
Очень удобно все опции, с которыми мы запускаем uWSGI, указать в ini файле, а при запуске передавать только путь к этому файлу.
Создаем файл mysite_uwsgi.ini :
Проверяем. Все работает? Дальше.
Устанавливаем uWSGI глобально
До сих пор uWSGI был установлен в виртуальном окружении. Чтобы была возможность автоматически запускать uWSGI при старте операционной системы, мы установим его глобально.
Деактивируем виртуальное окружение:
На вики странице uWSGI описано несколько вариантов установки. Перед тем, как установить uWSGI глобально, вам не помешает определиться с выбором версии и методом установки.
Запусить uWSGI можно той же командой, что и раньше:
Режим Emperor
Если сервер обслуживает несколько проектов, каждый из которых использует uWSGI, то нужно исползовать режим Emperor. В этом режиме uWSGI просматривает папку с конфигурационными файлами и для каждого файла запускает отдельный процесс (вассал).
Если один из конфигурационных файлов будет изменен, uWSGI перезапустит соответствующего вассала.
Как использовать Django с Apache и mod_wsgi ¶
Базовая конфигурация ¶
После того, как вы установили и активировали mod_wsgi, отредактируйте файл httpd.conf вашего сервера Apache и добавьте следующее.
Эта WSGIPythonPath строка гарантирует, что ваш пакет проекта доступен для импорта по пути Python; другими словами, это работает. import mysite
Эта часть гарантирует, что Apache может получить доступ к вашему wsgi.py файлу.
Затем нам нужно убедиться, wsgi.py что объект приложения WSGI существует. Начиная с Django версии 1.4, он startproject будет создан для вас; в противном случае вам нужно будет его создать. См. В обзорной документации WSGI содержимое по умолчанию, которое вы должны поместить в этот файл, и что еще вы можете добавить к нему.
Если несколько сайтов Django запускаются в одном процессе mod_wsgi, все они будут использовать настройки того, какой из них запускается первым. Это можно решить, изменив:
или с помощью режима демона mod_wsgi и обеспечения того, чтобы каждый сайт работал в собственном процессе демона.
Исправление UnicodeEncodeError загрузки файлов
См. Подробности в разделе « Файлы » справочного руководства по Unicode.
Использование mod_wsgi режима демона ¶
Если вы хотите обслуживать свой проект в подкаталоге ( https://example.com/mysite в этом примере), вы можете добавить WSGIScriptAlias в конфигурацию выше:
Раздача файлов ¶
Django не обслуживает файлы сам по себе; он оставляет эту работу любому веб-серверу, который вы выберете.
Мы рекомендуем использовать отдельный веб-сервер, т. Е. Тот, на котором еще не работает Django, для обслуживания мультимедиа. Вот несколько хороших вариантов:
Обслуживание файлов администратора ¶
Когда django.contrib.staticfiles он INSTALLED_APPS включен, сервер разработки Django автоматически обслуживает статические файлы приложения администратора (и любых других установленных приложений). Однако это не тот случай, когда вы используете любую другую схему сервера. Вы несете ответственность за настройку Apache или любого другого веб-сервера, который вы используете, для обслуживания файлов администратора.
Файлы администратора находятся в ( django/contrib/admin/static/admin ) дистрибутива Django.
Аутентификация по базе данных пользователей Django из Apache ¶
Как развертывать с помощью WSGI¶
Основной платформой для развертывания Django является WSGI, стандарт Python для веб-серверов и приложений.
Команда управления Django startproject устанавливает для вас минимальную конфигурацию WSGI по умолчанию, которую вы можете настроить по мере необходимости для вашего проекта и направить на использование любого WSGI-совместимого сервера приложений.
Django включает документацию по началу работы для следующих серверов WSGI:
Объект application ¶
Команда startproject создает файл
Он используется как на сервере разработки Django, так и в производственных развертываниях WSGI.
Конфигурирование модуля настроек¶
Django использует переменную окружения DJANGO_SETTINGS_MODULE для поиска соответствующего модуля настроек. Она должна содержать точечный путь к модулю настроек. Вы можете использовать разные значения для разработки и производства; все зависит от того, как вы организуете свои настройки.
Поскольку переменные окружения относятся ко всему процессу, это не работает, когда вы запускаете несколько сайтов Django в одном процессе. Это происходит с mod_wsgi.
Применение промежуточного программного обеспечения WSGI¶
Чтобы применить WSGI middleware, вы можете обернуть объект приложения. Например, вы можете добавить эти строки в нижней части wsgi.py :
Вы также можете заменить WSGI-приложение Django на пользовательское WSGI-приложение, которое впоследствии делегируется WSGI-приложению Django, если вы хотите объединить Django-приложение с WSGI-приложением другого фреймворка.
Развертывание приложения на Django с uWSGI и nginx в производственной среде
Это небольшое руководство предназначено для пользователя Django, который хочет настроить приложение Django c веб-сервером в производственной среде. В нем описаны шаги, необходимые для настройки приложения на Django, чтобы оно хорошо работало с uWSGI и nginx.
Концепция
Веб-сервер может обслуживать статичные файлы (HTML, изображения, CSS и т. д.) напрямую из файловой системы. Но он не может напрямую общаться с приложением на Django. Для этого ему нужно что-то, что будет запускать приложение, отправлять запросы от веб-клиентов (браузеров) и возвращать ответы. Для этого создан Web Server Gateway Interface — WSGI. WSGI — это спецификация, которая описывает, как веб-сервер взаимодействует с веб-приложениями и как веб-приложения могут быть объединены в цепочку для обработки одного запроса.
uWSGI — это одна из реализаций WSGI в Python. В этом руководстве мы настроим uWSGI таким образом, чтобы он создавал сокет или порт и обслуживал запросы/ответы веб-сервера по протоколу uwsgi. В итоге наш полный стек компонентов будет выглядеть так:
Прежде чем начать настройку uWSGI
virtualenv
Убедитесь, что вы используете virtualenv, если нет его нужно установить (позже мы опишем, как установить общесистемный uwsgi):
Django
Установите Django в свой virtualenv, создайте новый проект и перейдите в проект:
О домене и о порте
В этом статье мы назовем наш домен example.com. Замените это доменное имя на свое полное доменное имя или IP-адрес.
Повсеместно, мы будем использовать порт 8000 для публикации на веб-сервере, так же, как сервер запуска Django делает это по умолчанию. Конечно, вы можете использовать любой порт, который хотите, но я выбрал этот, чтобы он не конфликтовал с тем, что веб-сервер уже может делать.
Базовая установка и настройка uWSGI
Установите uWSGI в свой virtualenv
Конечно, есть и другие способы установки uWSGI, но этот так же хорош, как и любой другой. Помните, что вам нужно будет установить пакеты разработки Python. В случае Debian или систем, производных от Debian, таких как Ubuntu, вам нужно установить pythonX.Y-dev, где X.Y — ваша версия Python.
Базовый тест
Создайте файл с названием test.py:
Примечание
Учтите, что Python 3 требует bytes().
Запуск uWSGI:
Эти опции означают:
При обращение через браузере к http://example.com:8000 вы должны сообщение «Hello World».
Теперь наш стек компонентов выглядит следующим образом:
Протестируем проект Django
Теперь мы хотим, чтобы uWSGI делал то же самое, но вместо приложения test.py запускал сайт на Django.
Если вы еще этого не сделали, убедитесь, что ваш проект на Django действительно работает:
И далее запустите его с помощью uWSGI:
Если теперь зайти через браузер на сервер должно отобразиться приложение а наш стек компонентом будет таким:
Но как правило, браузер не должен напрямую обращаться к uWSGI. Это работа для веб-сервера, который будет действовать как посредник.
Основы nginx
Установка nginx
После установки проверьте, работает ли nginx, посетив страницу по умолчанию в веб-браузере по порту 80 — вы должны получить сообщение от nginx: «Welcome to nginx!». В этом случае наш стек будет таким:
Настройте nginx для своего сайта
Далее вы можете использовать файл uwsgi_params, который доступен в каталоге nginx дистрибутива uWSGI или по адресу https://github.com/nginx/nginx/blob/master/conf/uwsgi_params
Скопируйте его в каталог вашего проекта. Далее мы укажем nginx как его использовать.
Теперь создайте файл с именем mysite_nginx.conf со следующим содержимым:
В этом файле мы указали nginx обслуживать мультимедийные и статические файлы из файловой системы, а также обрабатывать запросы, предназначенные для Django. При развертывание больших систем считается хорошей практикой разрешать одному серверу обрабатывать статические/мультимедийные файлы, а другому — приложения Django.
Создайте ссылку на этот файл в /etc/nginx/sites-enabled, чтобы nginx смог его увидеть:
Развертывание статических файлов
Перед запуском nginx вы должны собрать все статические файлы Django в папке со статикой. Для этого вы должны отредактировать mysite/settings.py, добавив в него:
Базовый тест nginx
Чтобы проверить, что медиа-файлы обслуживаются правильно, добавьте изображение с именем media.png в каталог /path/to/your/project/project/media, а затем посетите http://example.com:8000/media/media.png — если это работает, вы будете знать, по крайней мере, что nginx правильно обслуживает файлы.
nginx и uWSGI и test.py
Давайте еще раз запустим приложение «hello world» test.py.
Это почти так же, как и раньше, за исключением того, что один из вариантов отличается:
В то же время nginx настроен на связь с uWSGI через этот порт и с внешним миром через порт 8000. Посетите:
Теперь наш стек будет следующим:
Между тем, вы можете попытаться взглянуть на вывод uswgi по адресу http://example.com:8001 — но вполне вероятно, что он не будет работать, потому что ваш браузер работает по протоколу http, а не через протокол uWSGI, хотя вы должны увидеть вывод uWSGI в терминале.
Использование Unix-сокетов вместо портов
До сих пор мы использовали порты TCP, потому что это проще, но на самом деле лучше использовать сокеты Unix, — так как в этом случае будет меньше накладных расходов.
Отредактируйте mysite_nginx.conf, изменив следующее:
и перезапустите nginx.
Запустите uWSGI снова:
На этот раз опция socket сообщает uWSGI, какой файл сокетов использовать.
Если это не работает
Проверьте ваш журнал ошибок nginx (/var/log/nginx/error.log). Если вы видите что-то вроде:
тогда, вероятно, вам нужно управлять разрешениями для сокета, чтобы nginx мог использовать его.
В этом случае попробуйте следующую команду:
Возможно, вам также придется добавить своего пользователя в группу nginx (которая, вероятно, относится к www-data) или наоборот, чтобы nginx мог правильно читать и записывать в ваш сокет.
Запуск приложения Django с помощью uwsgi и nginx
Давайте теперь запустим наше приложение Django:
Теперь uWSGI и nginx должны обслуживать не просто модуль «Hello World», а ваш проект Django.
Настройка uWSGI для работы с INI-файлом
Мы можем поместить в файл те же параметры, которые мы использовали с uWSGI, а затем попросить uWSGI запуститься с этим файлом.
Создайте файл с именем mysite_uwsgi.ini:
И запустите uwsgi, используя этот файл:
Еще раз, проверьте, что сайт Django работает, как ожидалось.
Установите uWSGI для всей системы
Пока у нас uWSGI был установлен только в нашей виртуальной среде; иногда может возникнуть, чтобы он был установлен в масштабе всей системы.
и установите uWSGI для всей системы:
Вики uWSGI описывает несколько процедур установки (installation procedures). Перед установкой uWSGI для всей системы стоит подумать, какую версию выбрать и какой подходящий способ ее установки.
Проверьте еще раз, что вы все еще можете запускать uWSGI так же, как и раньше:
Режим Emperor
uWSGI может работать в режиме «emperor». В этом режиме он следит за каталогом конфигурационных файлов uWSGI и порождает экземпляры («vassals») для каждого найденного файла.
Всякий раз, когда в конфигурационный файл вносятся изменения, emperor автоматически перезапускает vassal.
Вам может потребоваться запустить uWSGI с помощью sudo:
Эти опции означают:
Запуск uWSGI при загрузке системы
Последний шаг — это сделать автоматический запуск uWSGI во время запуска системы.