Публикации с меткой «nginx»

1. Удобное управление запуском/остановкой/перезапуском нескольких проектов на одном хосте
2. Поддержка разных виртуальных сред для разных проектов

WSGIServer: missing FastCGI param SERVER_PORT required by WSGI!
WSGIServer: missing FastCGI param SERVER_PROTOCOL required by WSGI!" while reading upstream, client: xx.xx.xxx.xx, server: xxx.xxx.xxx.xxx, request: "POST /profiles/change_data/ HTTP/1.1", upstream: "fastcgi://unix:/home/constellation/front.sock:", host: "xxx.xxx.xxx.xxx:xxxx", referrer: "http://xxx.xxx.xxx.xxx:xxxx/profiles/change_data/"

Я вчера перевёл все свои сайты на связку nginx + fastcgi-демон. Раньше они работали на связке nginx + apache/mod_wsgi. Даже не знаю, зачем я это сделал. Да и какая разница :o) Я сейчас просто опишу как соединять nginx с fastcgi-django-демонами через библиотеку superfcgi и надеюсь, кому-нибудь это будет полезно.

Так вот, для начала нада поставить superfcgi библиотеку. Кстати, её автор barbuza. Ставится банально: pip install superfcgi. Только не забудьте зависимости поставить предварительно. В debian надо ставить такие пакеты: gcc, python2.5-dev (если у вас 2.5 python), libfcgi-dev. Ещё надо multiprocessing либу поставить в случае python2.5, правда, Виктор говорит, что она уже автоматически ставиться. Но, если что, имейте в виду.

После установки superfcgi надо прописать ‘superfcgi’ в settings.INSTALLED_APPS. Это сделает доступной команду manage.py runserupfcgi, с помощью которой можно запустить процесс, который позволит общаться с nginx через fastcgi-интерфейс.

Проблема в том, что надо как-то контролировать этот процесс: уметь его останавливать, например. Команда manage.py runsuperfcgi этого не умеет, поэтому я использую дополнительный bash скрипт. Пощупать его можно тут: http://bitbucket.org/lorien/spawn/src/tip/spawn.sh

У меня для каждого сайта есть свой маленький spawn.sh, в котором я задаю одну переменную $SITE и затем делаю include главного spawn.sh. Например, для запуска веб-мозгов у меня такой скрипт:

На всякий случай, если вдруг сайт упадёт или будет сделан rebot сервера у меня в кроне каждую минуту стартуются все сайты. Тупо, да, зато работает :D Конечно, если сайт уже запущен, то копия не запускается, в spawn.sh учтёт этот момент. Каждую минуту я пытаюсь запустить все сайты таким скриптом:

Кроме django-сайтов я запустил через superfcgi также один trac-проект. Для этого я сделал следующее, создал в директории проекта файл trac_wsgi.py

import os

os.environ['TRAC_ENV'] = '/web/pybb.org'
os.environ['PYTHON_EGG_CACHE'] = '/web/cache/trac/pybb.org'

import trac.web.main
app = trac.web.main.dispatch_request

Это просто создание WSGI приложения, обслуживающего trac-проект. Теперь его можно подцепить к superfcgi библиотеке. Библиотека superfcgi предоставляет команду superfcgi, которая в параметре —app принимает название модуля, где находится wsgi-приложение. Описываю я всё довольно сумбурно, но писать подробнее не могу — шибко лень :) Я просто это всё напишу здесь, потом кто-то будет искать через google, наткнётся, прочитает, что-то поймёт. Я сам иногда на свои старые посты натыкаюсь и иногда даже нахожу то, что успел забыть :D

В общем, spawn.sh файл для запуска trac такой:

Преамбула

Как я и обещал в предыдущей серии, посвящаю этот пост нашей системе развертывания.

Система самописная, достаточно тесно связана с процессом разработки и реализована при помощи sh-скрипта.

Общая схема

На рисунке приведена немного сумбурная схема процесса развертывания.

Разработка ведется с использованием SVN установленным на локальном сервере, там же расположен и локальный сервер MySQL. MySQL используется всеми при разработке, структура создается через initdb. Начальные данные в обязательном порядке (скоро узнаете почему) сохраняются либо в fixtures, либо в init.sql, а в случае прав пользователей создается команда manage.py.

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

Когда проект готов для тестирования, менеджер проекта запускает (по ssh;) развертывание на TEST он же помечен цифрой 2 на схеме. Структура база данных переносится из DEV версии.

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

Процесс деплоя на TEST выполняется итеративно, пока не будут исправлены все обнаруженные ошибки. И тогда наступает час X, менеджер проекта достает большую красную кнопку и запускает развертывание на PROD версию.

Публичная версия обновляется исключительно с TEST версии, копированием файлов и структуры базы. Это с одной стороны дает гарантию что мы запустим именно тот код который был оттестирован, с другой подразумевает что любые изменения должны быть проверены (задеплоиться с DEV или репозитория нельзя).

Расскажу об одном интересном моменте, почему при деплое не теряются пользовательские данные. Дело в том, что mysqldiff генерирует ALTER срипт, который изменяет лишь структуру БД, но не трогает сами данные. Файлы загруженные пользователями хранятся в отдельном месте и подключаются в структуру проекта с помощью символической ссылки. Таким образом мы имеем три независимых версии со своими данными в базе и загруженными файлами.

Конфигурация системы

Система планировалась более-менее универсальной, поэтому у каждого проекта есть опции развертывания, которые должны храниться в файле deploy/params.sh. Основные параметры:

• Параметры SVN репозитория, для скачивания и обновления исходного кода.
• Параметры MySQL сервера, который используется для переноса изменений структуры на DEV.
• Имя конечного конфигурационного файла, который формируется из шаблона для каждой версии проекта.
• Путь к media и загружаемым файлам пользователя.
• Базовые порты FCGI и SPHINX.
• Команда выполняемая сразу после деплоя (обычно команда инициализации прав пользователей).

MySQL

С базой при деплое все достаточно просто, если её не существует, скрипт запускает создание базы manage.py initdb, Django загружает fixtures, скрипт запускает init.sql и в конце выполняет прописанную в конфиге команду. Огромное разнообразие методов начальной загрузки данных удовлетворяет любые даже самые сложные случаи.

Например, в свое время мы столкнулись со сложностью распределения прав пользователей по группам. На уровне fixtures или init.sql ну никак не получалось этого сделать, из-за того что на разных версиях проекта, созданные initdb права, имеют разные id. В итоге и появилась команда выполняемая в конце развертывания, которая используя стандартные методы Django, формирует необходимые группы пользоватей и распределяет права доступа.

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

Если база данных уже создана, то при развертывании переносится только структура с помощью mysqldiff. Этот скрипт делает экспорт структуры двух баз данных (откуда и куда переносим), сравнивает эти данные и формирует sql скрипт для обновления целевой базы. Скрипт уже стандартными средствами СУБД применяется к базе. Причем при деплое на PROD, скрипт просматривается вручную, дабы в случае сбоя не удалить пользовательские данные.

Конфигурационные файлы

Одна из моих любимых функций нашей системы — генерация конфигурационных файлов.

Конфиг разработчиков хранится в отдельном файле base_settings.py а в стандартном settings.py всего одна строчка включения базовых настроек from base_settings.py import *.

Для настроек применяемых на хостинге создается специальный шаблон настроек template_settings.py в котором переопределяются нужные настройки из base_settings.py, причем следуя принципу DRY шаблонный файл всего один для всех трех версий системы.

Поведение специфичное для конкретной версии (имена баз данных, например, у всех разные) поддерживается макро-язык суть которого в замене конструкции {имя версии: значение} на значение. Допустим строка

DATABASE_NAME={dev:eshtab_dev}{test:eshtab_test}{prod:eshtab}

Но с другой стороны мы уже указали имя базы данных в params.sh, воскликнет внимательный читатель. Для решения этой проблемы активны специальные подстановки, вот примерный их список:

{instance}

DEV, TEST или PROD — версия системы.

{dbname}

имя базы данных.

{sitepath}

путь к файлам проекта.

{domain}

базовый адрес версии проектам (например dev.eshtab.ru).

{fcgi_port}

FCGI порт, используется как Django так и NGINX.

{sphinx_port}

порт поискового движка, используемого на наших проектах.

{media_path}

путь к статическим файлам.

Подстановки изумительны с точки зрения DRY, они используются как в Django так и в конфигурационных файлах SPHINX, NGINX, так и в скриптах запуска.

Макро-замены и подстановки осуществляются потоковым текстовым редактором sed. После замен settings.py заменяется шаблоном.

SPHINX, NGINX

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

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

{dev:#}{test:#}    server {
{dev:#}{test:#}        listen       80;
{dev:#}{test:#}        server_name .{domain};
{dev:#}{test:#}        rewrite ^/(.*) http://www.{domain}/$1 permanent;
{dev:#}{test:#}    
}

Как вы наверно догадались на DEV и TEST эти строки будут закомментированы, а на PROD веб-сервер будет переадресовывать запросы с domain на www.domain из эстетических соображений.

На правах заключения

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

Неделю назад я сравнивал производительность и устойчивость работы nginx'а с Django с помощью mod_wsgi и fastcgi. Сравнение показало, что скорость работы при наличии быстрой локальной (читай - практически не оказывающей влияние) БД практически не отличается, отличается только количество используемых ресурсов.

А сегодня я наконец-то собрался посмотреть, что же будет, когда база данных находится на другом компе, а связь по wifi между веб-сервером и БД усугубляет проблему. :-) То есть весь смысл сегодняшних моих мучений - посмотреть на ситуацию с тормозящей базой данных (стало интересно после комментария Манлио). Заодно и хотелось посмотреть, как себя ведёт Apache.

Перед этим я таки запустил пару раз лёгкий тест (ab -n 100 -c 20) на Апач (с локальной базой данных), который показал, что апач не хочет использовать два моих ядра ни в какую. :-( Ни prefork, ни worker не использовали второе ядро и запрос в среднем занимал 28 мс, что в два раза дольше, чем nginx'овый показатель - 14 мс. Логически поразмышляв, можно понять, что тяжёлый Апач в любом случае работает медленнее nginx'а - второе ядро в два раза не ускорит (что и говорит показатель в 24 мс у nginx'а при работе с одним ядром :-).

Дальше PostgreSQL был запущен на другом ноуте. Апач я мерял как в prefork версии, так и в worker.

Первый вариант - ab -n 1000 -c 20:

• apache - ~37 мс. Стабильно, в пределах 5 запусков разницы не было даже в миллисекунду.
• nginx + mod_wsgi - ~50 мс. Ожидаемо.
• nginx + fastcgi prefork - ~28 мс. В мозгу не укладывается, что оно настолько быстрее Апача! :-)

Второй вариант - при ab -n 3000 -c 500 - не слишком отличается. Апач и фастцги - такие же, мод_всги вырос до 55 мс.

В этот момент мне показалось, что mod_wsgi годится только когда нету БД (или задержками на её работу можно пренебречь). Однако, поразмыслив, я сделал ход конём - увеличил количество воркеров в нгинксе. :-) При 16 воркерах (проверено позже - 8 достаточно) и 500 одновременных запросов один отклик приходит в среднем раз в 28 мс. Теперь и результат фастцги укладывается, и апач выглядит толстым и тяжёлым, как обычно. ;-) Правда, каждый процесс nginx'а, работающий с джангой, кушает порядка 15 мегабайт. Хотя это в любом случае меньше, чем апач и fastcgi.

Выводы каждый может сделать сам для себя, но nginx + mod_wsgi однозначно - очень интересная комбинация.

Неделю назад я сравнивал производительность и устойчивость работы nginx'а с Django с помощью mod_wsgi и fastcgi. Сравнение показало, что скорость работы при наличии быстрой локальной (читай - практически не оказывающей влияние) БД практически не отличается, отличается только количество используемых ресурсов.

А сегодня я наконец-то собрался посмотреть, что же будет, когда база данных находится на другом компе, а связь по wifi между веб-сервером и БД усугубляет проблему. :-) То есть весь смысл сегодняшних моих мучений - посмотреть на ситуацию с тормозящей базой данных (стало интересно после комментария Манлио). Заодно и хотелось посмотреть, как себя ведёт Apache.

Перед этим я таки запустил пару раз лёгкий тест (ab -n 100 -c 20) на Апач (с локальной базой данных), который показал, что апач не хочет использовать два моих ядра ни в какую. :-( Ни prefork, ни worker не использовали второе ядро и запрос в среднем занимал 28 мс, что в два раза дольше, чем nginx'овый показатель - 14 мс. Логически поразмышляв, можно понять, что тяжёлый Апач в любом случае работает медленнее nginx'а - второе ядро в два раза не ускорит (что и говорит показатель в 24 мс у nginx'а при работе с одним ядром :-).

Дальше PostgreSQL был запущен на другом ноуте. Апач я мерял как в prefork версии, так и в worker.

Первый вариант - ab -n 1000 -c 20:

• apache - ~37 мс. Стабильно, в пределах 5 запусков разницы не было даже в миллисекунду.
• nginx + mod_wsgi - ~50 мс. Ожидаемо.
• nginx + fastcgi prefork - ~28 мс. В мозгу не укладывается, что оно настолько быстрее Апача! :-)

Второй вариант - при ab -n 3000 -c 500 - не слишком отличается. Апач и фастцги - такие же, мод_всги вырос до 55 мс.

В этот момент мне показалось, что mod_wsgi годится только когда нету БД (или задержками на её работу можно пренебречь). Однако, поразмыслив, я сделал ход конём - увеличил количество воркеров в нгинксе. :-) При 16 воркерах (проверено позже - 8 достаточно) и 500 одновременных запросов один отклик приходит в среднем раз в 28 мс. Теперь и результат фастцги укладывается, и апач выглядит толстым и тяжёлым, как обычно. ;-) Правда, каждый процесс nginx'а, работающий с джангой, кушает порядка 15 мегабайт. Хотя это в любом случае меньше, чем апач и fastcgi.

Выводы каждый может сделать сам для себя, но nginx + mod_wsgi однозначно - очень интересная комбинация.

Вчера вечером таки связался с автором mod_wsgi (до этого были какие-то проблемы - он говорит, что мне отвечал, но у меня даже в спамбоксе пусто было) и скомпилировал nginx с mod_wsgi (ха-ха, как много решают слеши в нашей жизни ;-).

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

Но тут начинается веселье - тестирование. ;-) Простая страничка, 15 запросов (PostgreSQL на этом же компе), инфы по этим запросам приходят мелочи (ещё хочу потестировать, чтоб было инфы побольше, а постгрес был на другом компе). 2 воркера (пробовал и 3, и 4 - выходит медленнее в любом варианте, на 2-4 мс). Два варианта запросов (ab -n 1000 -c 20 и ab -n 10000 -c 500) и три варианта серверов (mod_wsgi, prefork fastcgi, threaded fastcgi). Железо (всё равно интересно только в сравнении на одном железе и софте, потому конфигурация несущественна, но всё же) - Core 2 Duo T7300 и 2 Gb RAM.

При ab -n 1000 -c 20 (на каждый вариант сервера пришлось порядка 10-12 тестирований):

• mod_wsgi стабильно выдаёт 14.2-14.3 мс на запрос
• prefork fastcgi выдаёт 12.5-16.5 мс (в основном около 12, но иногда подскакивает), жрёт больше рамы - у меня xmobar¹ показывает количество съеденной памяти, при mod_wsgi там на пару процентов (процент - 20 мегов) меньше всегда
• threaded fastcgi выдаёт 24-25 мс на запрос - он использует только одно ядро, я пытался настроить в нгинксе upstream - он работает, но использует почему-то только 1 процесс

Т.е. в большинстве случаев при такой нагруженности фастцги выходит немного быстрее (хотя и кушает немножко больше ресурсов). Но... идём дальше? ;)

При ab -n 10000 -c 500 (тут вышло по 3-4 запуска):

• mod_wsgi выдаёт 13-14 мс. Каждый воркер хавает примерно 21/15 мегов памяти (VSZ/RSS)
• prefork fastcgi выдаёт 15.5-17 мс на запрос, но при этом запускается от 40 до 50 обслуживающих процессов, каждый из которых кушает 16-20 VSZ (10-13 RSS) мегов памяти! По xmobar'у расход выходит до 50% (скачками, обычно около 45-48) относительно 33% у wsgi. Это лишних 300 мегов оперативки!
• threaded fastcgi - самый интересный вариант. При таком количестве одновременных запросов он умирает. При -c 100 - тоже умирает. При -c 50 - живёт, но скорость выходит чуть ниже, чем при -c 20, а рабочий процесс хавает до 300 мегов VSZ.

Что тут можно сказать? Ждём, когда mod_wsgi станет стабильным! :-)

Вчера вечером таки связался с автором mod_wsgi (до этого были какие-то проблемы - он говорит, что мне отвечал, но у меня даже в спамбоксе пусто было) и скомпилировал nginx с mod_wsgi (ха-ха, как много решают слеши в нашей жизни ;-).

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

Но тут начинается веселье - тестирование. ;-) Простая страничка, 15 запросов (PostgreSQL на этом же компе), инфы по этим запросам приходят мелочи (ещё хочу потестировать, чтоб было инфы побольше, а постгрес был на другом компе). 2 воркера (пробовал и 3, и 4 - выходит медленнее в любом варианте, на 2-4 мс). Два варианта запросов (ab -n 1000 -c 20 и ab -n 10000 -c 500) и три варианта серверов (mod_wsgi, prefork fastcgi, threaded fastcgi). Железо (всё равно интересно только в сравнении на одном железе и софте, потому конфигурация несущественна, но всё же) - Core 2 Duo T7300 и 2 Gb RAM.

При ab -n 1000 -c 20 (на каждый вариант сервера пришлось порядка 10-12 тестирований):

• mod_wsgi стабильно выдаёт 14.2-14.3 мс на запрос
• prefork fastcgi выдаёт 12.5-16.5 мс (в основном около 12, но иногда подскакивает), жрёт больше рамы - у меня xmobar¹ показывает количество съеденной памяти, при mod_wsgi там на пару процентов (процент - 20 мегов) меньше всегда
• threaded fastcgi выдаёт 24-25 мс на запрос - он использует только одно ядро, я пытался настроить в нгинксе upstream - он работает, но использует почему-то только 1 процесс

Т.е. в большинстве случаев при такой нагруженности фастцги выходит немного быстрее (хотя и кушает немножко больше ресурсов). Но... идём дальше? ;)

При ab -n 10000 -c 500 (тут вышло по 3-4 запуска):

• mod_wsgi выдаёт 13-14 мс. Каждый воркер хавает примерно 21/15 мегов памяти (VSZ/RSS)
• prefork fastcgi выдаёт 15.5-17 мс на запрос, но при этом запускается от 40 до 50 обслуживающих процессов, каждый из которых кушает 16-20 VSZ (10-13 RSS) мегов памяти! По xmobar'у расход выходит до 50% (скачками, обычно около 45-48) относительно 33% у wsgi. Это лишних 300 мегов оперативки!
• threaded fastcgi - самый интересный вариант. При таком количестве одновременных запросов он умирает. При -c 100 - тоже умирает. При -c 50 - живёт, но скорость выходит чуть ниже, чем при -c 20, а рабочий процесс хавает до 300 мегов VSZ.

Что тут можно сказать? Ждём, когда mod_wsgi станет стабильным! :-)

Сегодня наткнулся на просто невероятную вещь - mod_wsgi для nginx'а. На английском упоминаний нету вообще нигде, но не сомневаюсь, что они скоро появятся. :)

UPD. Он, конечно, совсем новый и ещё не юзабельный для продакшена, но, судя по всему, пока разработчик порядочно активен - только что добавился TODO

Сегодня наткнулся на просто невероятную вещь - mod_wsgi для nginx'а. На английском упоминаний нету вообще нигде, но не сомневаюсь, что они скоро появятся. :)

UPD. Он, конечно, совсем новый и ещё не юзабельный для продакшена, но, судя по всему, пока разработчик порядочно активен - только что добавился TODO