Что такое wsgi сервер

Впервые было опубликовано в журнале «Системный администратор» #12 за 2008 год

Если вы разрабатываете Web-приложение, каркас для разработки Web-приложений, или даже Web-сервер на Python вам просто необходимо знание основ протокола WSGI — стандартного способа связи Web-сервера и Web-приложения.

Описание протокола

WSGI (расшифровывается как Web Server Gateway Interface — интерфейс шлюза Web-сервера) — это простой и универсальный интерфейс взаимодействия между Web-сервером и Web-приложением, впервые описанный в PEP-333 (http://www.python.org/dev/peps/pep-0333/). Под простотой в данном случае подразумевается лишь простота подключения приложения, но не простота реализации Web-приложений для авторов. Надо заметить, что основной целью разработки WSGI была разработка простого протокола, который бы мог разделить выбор каркасов для разработки Web-приложений от выбора Web-серверов. Это, в частности, позволяет разработчикам приложений (каркасов) и серверов концентрироваться на своей области специализации и отличает WSGI от более общих протоколов связи приложений с Web-серверами, таких как CGI, или FastCGI. С точки зрения WSGI цельное Web-приложение делится на две части: сервер (или шлюз) и непосредственно приложение (или каркас для построения приложений). Для обращения к приложению серверная часть использует вызываемый объект (это может быть функция, метод, класс, или экземпляр класса с методом __call__). WSGI также позволяет создавать приложения-посредники которые являются приложением для Web-сервера и сервером для Web-приложения. Такие посредники могут использоваться для предварительной обработки запросов к приложению, или последующей обработки его ответов. Ниже мы рассмотрим несколько примеров использования WSGI и затем обратимся к деталям протокола.

Сторона приложения

Как уже говорилось выше приложение — это просто вызываемый объект, который принимает два аргумента. Приложения должны допускать возможность многократных вызовов, что является обычной ситуацией практически для всех серверов (исключая вызовы с помощью CGI). Ниже представлены два примера приложения. Первое приложение реализовано в виде функции:

Здесь функция использует второй аргумент для передачи статуса и заголовков ответа и затем возвращает тело ответа в виде списка строк. Второе приложение реализовано в виде класса:

В данном случае объект класса будет представлять из себя итератор который на первом шаге итерации использует второй аргумент для передачи статуса и заголовков ответа и затем вернет тело ответа.

Надо отметить, что приложение с точки зрения WSGI — это всего лишь точка входа через которую сервер получает доступ к Web-приложению, или каркасу для построения Web-приложений.

Сторона сервера

Сервер (или шлюз) будет вызывать приложение для каждого HTTP запроса который ему предназначен. Для примера ниже представлен упрощенный шлюз CGI — WSGI. Пример использует упрощенную обработку ошибок т.к. по умолчанию ошибки будут выдаваться на sys.stderr и затем записываться в лог Web-сервера. Вызываемый объект приложения в данном случае передается как параметр функции:

Посредник: сервер и приложение в одном

Как уже было замечено выше некоторые объекты могут играть сразу две роли — быть сервером для какого-либо приложения и приложением для сервера. Вот примеры некоторых ситуаций для которых могут быть полезны WSGI-посредники:

Присутствие посредника в большинстве случае прозрачно и для сервера и для приложения, более того, посредники можно располагать один за другим, составляя таким образом «стек посредников».

Детали протокола

Как мы уже видели приложение должно принимать два аргумента, которые были названы environ и start_response, но могут иметь любые другие имена.

Первый параметр (environ) должен быть объектом словаря (dict) Python и содержит переменные среды похожие на переменные CGI. Этот объект также должен содержать обязательные для WSGI параметры, которые мы подробнее рассмотрим ниже, и может содержать переменные специфичные для конкретного Web-сервера.

Второй параметр (start_response) — это вызываемый объект которым приложение предваряет возвращение тела ответа и принимающий два обязательных параметра и один необязательный. Первый параметр (status) — статус ответа в виде строки, например «200 Ok». Второй параметр (response_headers в примере выше) — список кортежей (tuples) вида (имя_заголовка, значение_заголовка). Третий, необязательный параметр (exc_info) должен использоваться только при обработке ошибок и должен быть кортежем который возвращает функция sys.exc_info(). Надо заметить, что start_response не посылает заголовки сразу, а откладывает их до получения первой части тела ответа, что бы в случае ошибки их можно было заменить на заголовки сопутствующие ошибке. При этом start_response можно вызывать несколько раз только если передается третий параметр (exc_info).

После вызова сервером вызываемый объект приложения должен вернуть итерируемый объект возвращающий ноль, или несколько строк. Как мы видели в примерах выше этого можно достичь несколькими способами, например вернув список строк, или объект-итератор. При получении очередной части ответа сервер посылает ее клиенту без буферизации, но приложения могут осуществлять буферизацию ответа собственными силами.

В случае если итерируемый объект имеет метод close() он будет вызван по окончании обработки ответа сервером, даже в случае ошибки. Таким образом метод close() может использоваться для закрытия всех ресурсов приложения которые могли быть задействованы при создании ответа.

Переменные словаря environ

Словарь environ может содержать следующие CGI переменные: (Переменные которые может содержать словарь environ)

Также словарь environ должен содержать следующие, обязательные для WSGI переменные: (Обязательные для WSGI переменные в словаре environ)

Плюс environ может содержать специфичные для конкретного сервера переменные и переменные среды. Что бы увидеть набор переменных передаваемых приложению можно использовать, например, следующее простое WSGI приложение:

Обработка ошибок

В общем случае приложение должно обрабатывать внутренние ошибки и выводить соответствующее сообщение клиенту. Конечно, прежде чем выводить сообщение об ошибке приложение не должно начинать выводить нормальный ответ. Что бы обойти эту ситуацию используется третий параметр start_response — exc_info:

Если приложение еще не начало вывод тела ответа когда произошло исключение, то вызов start_response в обработчике будет нормальным и клиенту вернется ответ об ошибке. В случае если на момент ошибки уже был начат вывод ответа start_response выкинет переданное исключение. Это исключение не должно обрабатываться обработчиком, а будет обработано сервером и записано в журнал ошибок.

Пакет wsgiref

В стандартной библиотеке Python 2.5 появился новый пакет wsgiref, предоставляющий различные утилиты для упрощения работы с WSGI. Рассмотрим кратко его содержимое:

Источник

Введение в 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 используется в качестве прокси-сервера.

Источник

От Python скрипта до WSGI приложения

Появилась задача написать веб интерфейс управления устройством. Управлять устройством будет Raspberry Pi. Логика управления — python, соответственно и интерфейс хотелось бы python. Хочу поделится своим опытом.

теперь localhost/index.py отвечал бодрым «Hello World!»

2. Решено было поэкспериментировать с веб фреймворками.
Под руку попался wep.py, простенький и маловесный.
code.py:

Минимальный код и на порту 8080 висит наше веб приложение
Казалось бы пробросить алиас на порт 8080, организовать авто запуск скрипта и все готово.
Да но нет, эксперименты на слабеньком компьютере показали что присутствие нашего скрипта заставляет машинку изрядно «дуться». Кроме того есть lighttpd с mod_cgi.

Как же связать простой скрипт и веб приложение.

3. Согласно описанию WSGI, для его реализации необходим интерфейс такого вида

Ничего военного, но и что-то не работает, чего-то не хватает.
Момент который был неясным после прочтения вики и других статей, что же все таки запустит наш интерфейс.

4. Для запуска WSGI приложения нужен сервер. Пример скрипта который может выступать в роли простого сервера WSGI:
wsgi.py:

Теперь добавив к нашему интерфейсу его запуск получим скрипт который ответит уже на нашем lighttpd или apache, по адресу localhost/app.py
/var/www/app.py:

5. Для python 2.7 доступен модуль wsgiref который может реализовать WSGI сервер

6. Реализация WSGI c помощью flup:
установим flup

7. Простое web.py приложение с использованием flup:
/var/www/app.py:

приложение станет доступным по адресу localhost/app.py

8. По умолчанию web.py использует flup, но можно обойтись и без него.
Для запуска web.py на wsgiref необходимо:

B ссылках на скрипты web.py в конце не забывать ставить ‘/’ (app.py/), иначе ответом будет «not found». По-хорошему необходимо создать rewrite правило:

Для отладки в скриптов полезно добавить:

тогда будут видны ошибки.

Остается опробовать:
modwsgi
paste
pylons

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

WSGI (Web Server Gateway Interface)

Содержание

Обзор

История

Традиционный веб-сервер не имеет возможности запускать приложения Python. В конце 1990-х был предложен модуль Apache mod_python для выполнения произвольного кода Python. В течение нескольких лет в конце 1990-х и начале 2000-х годов Apache, настроенный с помощью mod_python, запускал большинство веб-приложений Python. Тем не менее, mod_python не был стандартной спецификацией. Это была просто реализация, которая позволяла запускать код Python на сервере. Когда разработка mod_python зашла в тупик и были обнаружены уязвимости безопасности, сообщество признало, что необходим последовательный способ выполнения кода Python для веб-приложений. Поэтому сообщество Python разработало WSGI в качестве стандартного интерфейса, который могут реализовывать модули и контейнеры. WSGI теперь является общепринятым подходом для запуска веб-приложений Python.

Описание

WSGI отличается гибкостью: разработчики приложений могут заменять компоненты веб-стека другими. Например, разработчик может перейти с Green Unicorn на WSGI без изменения приложения или инфраструктуры, реализующей WSGI. Согласно PEP 333: «Доступность и широкое использование такого API в веб-серверах для Python [. ] отделяет выбор среды от выбора веб-сервера, [. ] позволяя разработчикам сосредоточиться на их предпочтительной области специализации». [Источник 1]

Серверы WSGI обрабатывают запросы от веб-сервера и решают, как передать эти запросы процессу платформы приложения. Используя разделение обязанностей, WSGI обрабатывает тысячи запросов одновременно.

Согласно спецификации PEP 333 [Источник 2] :

Приложение WSGI

Объект приложения должен принимать два позиционных аргумента: environment и start_response. Сервер или шлюз должны вызывать объект приложения, используя позиционные (не ключевые) аргументы.

Параметр environment является объектом словаря, содержащим переменные среды в стиле CGI. Этот объект должен быть встроенным словарем Python (не подклассом, UserDict или другой эмуляцией словаря), и приложению разрешается изменять словарь любым способом, который он пожелает. Словарь также должен включать определенные переменные, необходимые для WSGI (описанные в следующем разделе), и может также включать переменные расширения, специфичные для сервера, названные в соответствии с соглашением, которое будет описано ниже.

Вызываемый элемент start_response должен возвращать вызываемый объект write (body_data), который принимает один позиционный параметр: строку, которая должна быть записана как часть тела ответа HTTP.

При вызове сервером объект приложения должен возвращать итерацию, дающую ноль или более строк. Это может быть достигнуто различными способами, например, путем возврата списка строк, или с помощью приложения, являющегося функцией-генератором, который возвращает строки, или с помощью приложения, являющегося классом, экземпляры которого являются итеративными. Независимо от того, как это выполняется, объект приложения должен всегда возвращать итеративный результат, дающий ноль или более строк.

Сервер или шлюз должны передать полученные строки клиенту без буферизации, завершив передачу каждой строки перед запросом другой.

Сервер или шлюз должен обрабатывать полученные строки как двоичные байтовые последовательности: в частности, он должен гарантировать, что окончания строк не изменяются. Приложение отвечает за то, чтобы записываемая строка (строки) была в формате, подходящем для клиента. (Сервер или шлюз могут применять кодировки передачи HTTP или выполнять другие преобразования с целью реализации таких функций HTTP, как передача в байтовом диапазоне).

Пример WSGI-совместимого приложения:

Приложение возвращает итератор с телом ответа, проще говоря – массив строк, которые будут склеены и отправлены в браузер. [Источник 3]

Промежуточное программное обеспечение WSGI

Как уже говорилось, один объект может играть роль сервера по отношению к некоторым приложениям, а также выполнять роль приложения по отношению к некоторым серверам. Такие «промежуточные» компоненты могут выполнять такие функции как:

Наличие промежуточного программного обеспечения в целом прозрачно как для стороны «сервер / шлюз», так и для «приложения / фреймворк» интерфейса, и не требует специальной поддержки. Пользователь, который хочет встроить промежуточное программное обеспечение в приложение, просто предоставляет компонент промежуточного программного обеспечения серверу, как если бы это было приложение, и настраивает компонент промежуточного программного обеспечения для вызова приложения, как если бы компонент промежуточного программного обеспечения был сервером. Конечно, «приложение», которое связывает промежуточное программное обеспечение, может фактически быть другим компонентом промежуточного программного обеспечения, обертывающим другое приложение, и так далее, создавая так называемый «стек промежуточного программного обеспечения».

Чтобы лучше поддерживать асинхронные приложения и серверы, компоненты промежуточного программного обеспечения не должны блокировать итерацию в ожидании нескольких значений из итерируемого приложения. Если промежуточному программному обеспечению необходимо накопить больше данных из приложения, прежде чем оно сможет произвести какие-либо выходные данные, оно должно привести к пустой строке.

Другими словами, компонент промежуточного программного обеспечения должен выдавать как минимум одно значение каждый раз, когда его базовое приложение возвращает значение. Если промежуточное программное обеспечение не может дать никакого другого значения, оно должно привести к пустой строке.

Это требование гарантирует, что асинхронные приложения и серверы могут сговориться, чтобы уменьшить количество потоков, необходимых для одновременного запуска определенного количества экземпляров приложения.

Источник

WSGI, Paste, Pylons — передовые веб-технологии

WSGI (Web Server Gateway Interface) – интерфейс для взаимодействия веб-сервера и работающих на нём веб-приложений, написанных на Python. WSGI является стандартом Python и описан в PEP 333. Это очень молодая технология. Детище Phillip J. Eby, изначально называвшееся Python Web Container
Interface, было отправлено в качестве претендента на PEP в Python Web-SIG 7 декабря 2003 года. А в августе 2004 получило своё современное название и отправилось в большое плавание. Несколько слов об этой технологии.
Современное многообразие языков программирования и фреймворков для веба наверняка приводит в ужас начинающих программистов. А более опытных поражает тем, что даже приложения, написанные на одном языке, являются сильно несовместимыми и неспособствующими повторному использованию кода. Перенос проекта из-под одного сервера под другой нередко становится сильной головной болью. Поэтому появление объединяющих стандартов является закономерым шагом развития технологий.
WSGI – это интерфейс (а говоря другими словами – прослойка) между веб-сервером и веб-приложением. Поэтому со стороны приложения это выглядит как веб-сервер, а со стороны сервера – как приложение. Это важная концепция. Она говорит о том, что для вашего проекта, написанного под WSGI, абсолютно всё равно, запущен ли он, скажем, на mod_python под Apache или как FastCGI где-то ещё. И вы можете заниматься написанием приложения, а не изучением API или окружения в выбранной связке.

Hello world!

Выглядит на практике это очень вкусно (пример WSGI-совместимого приложения):

В игру вступает Paste

Хотите проверить, как работает ваше приложение, прямо сейчас, добавив 3 строчки кода?

Концепция: стек приложений

Вернёмся к WSGI. Представьте себе, что будет, если внутри WSGI-приложения сделать предварительную обработку запроса (скажем, по идентификатору сессии в куках восстановить пользователя из базы данных), вызвать другое WSGI-приложение и вернуть результат работы последнего? Получится почти что схема для поддержки аутентификации. А если первое приложение вызывает второе, а к результатам его деятельности применяет XSL transformations?
Тут проявляется ещё одна важная концепция. Первое приложение в этих примерах выступает в роли прослойки, или middleware. А совокупность всех middleware образует стек приложения. Таким образом получается очень модульная система, в которой компоненты можно даже не подключать, а просто класть в нужном порядке на WSGI-основу (не забыв сверху свою аппликацию).

С помощью такой системы можно подключить SQLAlchemy – «the Python SQL toolkit and Object Relational Mapper that gives application developers the full power and flexibility of SQL», AuthKit – универсальный и гибкий фреймворк для авторизации пользователей, и не только, проверьте. И конечно же – middleware для ловли исключений и преобразования их в страницы «упс» и «ой-ой-ой». Надо сказать, что Paste поощряет обёртываение в middleware даже таких невебовских частей, как конфигурирование. Получается простая, очевидная и безусловно гибкая структура приложения.

Всё вместе и кое-что ещё — Pylons

Итак, WSGI обеспечивает связь веб-сервера с многослойной middleware-структурой. Paste поможет решить типичные задачи – тестирование, отлов исключений, внутренние редиректы запросов и даже индикатор загрузки файла (Upload Progress Monitor). Авторизация, аутентификация и работа с базой данных без единой строчки SQL были приведены как пример middleware чуть выше.
Теперь добавим сюда маршрутизацию запросов с помощью Routes, серверную часть AJAX – WebHelpers (оба компонента полностью портированы с RoR), шаблоны Mako – элегантные, с уникальными возможностями и невероятной скоростью, поддержку Unicode и I18N, соберём всё это вместе в полноценную Model-View-Controller-структуру и получим Pylons – передовой WSGI-совместимый веб-фреймворк для Python, вобравший всё лучшее из Python, RoR и других фреймворков и проектов.
Справедливости и критики ради стоит отметить, что указанные технологии очень молоды, например, Pylons ещё в версии 0.9.5, а AuthKit в разработке и пока не рекомендован для использования в продакшене. Тем не менее, я надеюсь, что мне получилось убедить вас в том, что WSGI перспективен, а наполненный библиотеками Paste и другими представляет собой почти идеальный (или канонический?) веб-фреймворк. Хотя применять технологию WSGI можно и в TurboGears, CherryPy, Django и других фреймворках.
Конечно для хоть сколько-нибудь объективного их сравнения мне не хватит опыта, но написание одного и того же приложения под Pylons и Django позволяет мне сделать вывод о том, что Pylons реально рулит, хотя и более сложен в освоении и установке.

Источник