Александр Кошелев

Причина

Проблема развертывания джанго приложений в продакшене до недавнего времени у меня стояла остро. Моя стандартная связка nginx+threaded fastcgi(flup) была очень не стабильна. Из-за достаточно ограниченных ресурсов (памяти) на серверах (в основном впс с лимитом до 100мб). Постоянно приходилось перезагружать сервер из-за сжирания памяти (неужели в питоне есть утечки памяти, или это из-за корявости моих скриптов?) и умирании процесса. Хорошо когда это было запланировано, а когда случалось неожиданно - это была маленькая катастрофа. Заказчики ругались.

Но в этой связке меня подкупала легковесность nginx и простота настройки. Изначально я ещё попробовал mod_python и apache, но не впечатлило - медленно и сложно. Фастсиджиай работал быстро и радовал глаз (пока работал).

Моя находка

Как то однажды, достаточно давно, заметил в одной из рсс упоминание о WSGI интерфейсе. Быстро осмотрел, понял что к чему и благополучно забыл (был занят другими более важными делами). Но тут уж пришел край и занялся я плотно поиском альтернативы системы размещения, которую я использовал. Тут как нельзя лучше подвернулся пост Пираньи в котором он упоминается mod_wsgi для nginx, нагрянули воспоминания, была поднята "подшивка" рсс (желтые звездочки в ридере рулят:) ) и начался процесс глубокого изучения этой штуки под названием wsgi.

Замечания того же Пираньи, что модуль для nginx'а ещё сыроват направили мой взор в сторону оригинального модуля для апача. Прочитав документацию, посмотрев результаты тестов, в которых достигается преимущество перед mod_python в два и более раза - решил попробовать.

Конфиги написались быстро. Всё заработало. Понравилось.

Теперь постепенно перевожу свои проект на эту схему.

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

Web Server Gateway Interface

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

Каждый из авторов фреймворков был вынужден ( да и по се день ) изобретать маленькие велосипеды и адаптировать своё детище под несколько протоколов взаимодействия с непосредственно веб-сервером.

WSGI в идеале должен дать универсальный инструмент взаимодействия и упростить всем жизнь. Медленно но верно этот процесс идет.

Как же устроен это интерфейс

И в правду говорят, что всё гениальное просто. Минимально необходимый скрипт для WSGI выглядит примерно так:

def application(environ, start_response):
    status = '200 OK'
    response_headers = [('Content-type','text/plain')]
    start_response(status, response_headers)
    return ['Hello world!\n']

application - точка входа. Именно эту функцию вызывает сервер (посредствам mod_wsgi) и передает в ней два параметра: environ - переменные окружения наподобие оных из CGI; start_response - колбек который уведомляет сервер, статус запроса и какие заголовки (и ещё немного служебной информации) нужно отдать клиенту. Вернуть же функция должна некий итерабельный объект, в нашем случае [""]

В роли точки входа можно использовать любой callable объект, либо связку __init__ + __iter__ для класса.

Более подробную информацию можно получить в официальном вики

Соединяем с джанго

WSGI скрипт для джанго выглядит примерно так:

import os, sys
sys.path.append('/usr/local/django')
os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'

import django.core.handlers.wsgi

application = django.core.handlers.wsgi.WSGIHandler()

Более подробно тут

А что же сам mod_wsgi?

mod_wsgi для апача появился относительно недавно, но уже успел себя хорошо зарекомендовать. Официальный сайт проекта.

Имеет хорошую документацию и легок в настройке.

Для себя отметил несколько очень положительных моментов:

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

Что в итоге

В итоге имеем очень хороший инструмент размещения веб/джано-приложений для питона. Проект находится в постоянном развитии, что дает надежду на появление бОльших возможностей и улучшений.