История вопроса

Исторически сложилось, что хостинг python-приложений очень мало распространён. Более удивителен этот факт при наличии достаточно удобных и развитых фреймворков, таких как Django или Pylons. Мы, как разработчики в том числе и на python, естественно, не cмогли пройти мимо идеи сделать хостинг, который позволил бы использовать эти популярные технологии.

Перепробовав различные подходы к запуску python-приложений на практике, мы столкнулись с нелёгкой задачей выбора. Ведь массовая услуга должна подразумевать, по нашему мнению, и удобство развёртывания кода, и некоторую универсальность (поскольку уникальность технологий скорее вредит бизнесу из-за страха клиента остаться наедине с этой уникальностью), и эффективность использования, и расширяемость (в том смысле, что мы должны всегда учитывать рост проекта клиента). Также, нам хотелось не ограничиваться хостингом только узкого набора фреймворков, а организовать именно полноценный хостинг для приложений на языке Python.

В конце прошлого столетия установились три основные концепции запуска приложений на веб-серверах - модуль с предзагруженным интерпретатором в составе веб-сервера (например, mod_php), CGI и FastCGI. Сложившаяся практика такова, что каждая из этих трёх концепций (и даже конкретная реализация) предполагает свой способ общения приложения и веб-сервера. Например, проектируя приложения на языке python при использовании mod_python под Apache разработчик должен выбрать так называемый "паблишер" (способ сцепки приложения и mod_python) и оформить своё приложение в соответствии с выбранным способом. Если понадобится перейти на FastCGI, а такие переходы неизбежны с ростом проекта - потребуется переделка оформления приложения. Перенос приложения из-под управления одним сервером под управление другим нередко становится очень трудоёмким процессом. Поэтому, при сегодняшней скорости развития Сети и многобразии различных технологий и просто программ, вполне закономерным явилось появление стандартов связки сервера и приложения, абстрагированных от их реализации.

WSGI

WSGI является стандартом Python и описан в PEP 333. WSGI – это описание унифицированной связки между веб-сервером и веб-приложением. На практике - это просто описание функции вызова приложения абстрактным сервером: формата передаваемых параметров и формата возврата значений этой функции. Ваше приложение, написанное на WSGI, не знает кто его вызвал, для него абсолютно всё равно, запущен ли он на mod_python под Apache или как FastCGI, или как CGI. Приложение и сервер выделяются в разные абстракции. (Кстати, WSGI для Python не одинок - для языка Ruby существует стандарт Rack: a Ruby Webserver Interface).

Наш выбор - WSGI

Наличие этого стандарта позволило нам отделить техническую реализацию хостинга от кода приложений. Это расширяет наши возможности в перспективе по специализации предоставления услуг хостинга python-приложений в зависимости от разных условий, например, от нагрузки создаваемой приложением, с минимальными затратами со стороны клиента. WSGI поддерживают все популярные веб-приложения на Python. Многие из них считают WSGI основным способом публикации и поставляемые "коннекторы" к другим технологиям публикации являются всего-лишь прослойкой для WSGI (например, Django). Установка многих из этих приложений на хостинге занимает несколько минут (например). WSGI - отличное решение и для тех, кто предполагает разрабатывать уникальное программное обеспечение. В любой ситуации несложно будет написать промежуточную прослойку, наподобие тех что имеет тот же Django, чтобы разместить код на любом хостинге, предоставляющем Python в любой сервировке. Для строителей больших проектов хостинг WSGI является отличной возможностью начать разрабатывать и внедрять свой проект с использованием введённого стандартом WSGI понятия MiddleWare ещё на начальных этапах разработки.

Технология, которую мы внедрили, создаёт для каждого приложения несколько процессов с интерпретатором python в контексте пользователя, которые во время первого обращения к приложению, подхватывают операционый код приложения, и после выполнения оставляет у себя в памяти до следующего обращения. Запросы диспетчеризуются и в резидентную программу с подгруженным приложением приходят только "родные" запросы. Такая схема повышает эффективность работы программ и удобно разграничивает ресурсы между пользователями. Перед приложением запрос обрабатывает веб-сервер понимающий файлы .htaccess, поэтому существует возможность раздельной отдачи статических картинок, закрытых статических областей сайта минуя веб-приложение, а также использовать привычные rewrite-правила. Система в целом очень похожа на принцип работы FastCGI за тем только различием, что ни внутри, ни внешне - нигде нет никакого намёка на FastCGI. Система реализована просто и академически правильно и вы будете редко сталкиваться с последствиями особенностей той или иной настройки хостинга.

WSGI - это правильный выбор. Пробуйте, разрабатывайте, внедряйте, развивайтесь!