Мы будем вынуждены остановить практически всё оборудование для переезда около 23 часов 3 апреля. По нашим расчетам переезд не займет больше пяти-шести часов, и к утру субботы 4 апреля все ваши проекты будут в строю и работать на новом месте. Никакие IP-адреса не поменяются.

О процессе переезда мы будем сообщать в нашем Twitter-аккаунте.

Короткий список ruby gems для работы с терминалом или Rails консолью. На все случаи жизни, если потребуется что-то напечатать или спросить у пользователя. У нас очень активно используются все четыре в различных внутренних консольных инструментах.

• Highline для проектирования интерактивных интерфейсов. Ввод-вывод на терминал, множественный выбор, цвета, все дела. Очень сильно облегчает задачу спросить что-нибудь из консоли или дать выбрать.
• Thor для проектирования консольных приложений. Самые разные опции с кучей синтаксического сахара для парсинга аргументов командной строки. Сравнивая с далекими девяностыми, понимаешь, насколько стало проще получать желаемое.
• Colorize для вывода цветных букв на терминал. Простой gem, который удобно использовать для выделения сервисных сообщений в Rails консоли. Как и положено хорошему инструменту, очень прост в использовании.
• Terminal table для рисования ASCII табличек. Достаточно передать массив, а табличку он нарисует сам. Задача, для которой раньше нужно было написать кучу кода, теперь решается в пару строк.

И в качестве послесловия: в Gemfile есть группа :console, которая подключается только из консоли.

Изменения коснулись пути доступа к PID-файлам проектов. Новое значение пути выглядит так:

/var/run/unicorn/#{user}/#{application}.#{login}.pid

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

set :unicorn_pid, "/var/run/unicorn/#{application}.#{login}.pid"

на строку

set :unicorn_pid, "/var/run/unicorn/#{user}/#{application}.#{login}.pid"

Указанные изменения путей не касаются работоспособности уже запущенных проектов, но без внесения этих изменений перезапустить остановленный проект невозможно.

Основную часть проблем составила нестабильная работа серверов баз данных mysql0 и postgresql0, причем, второй пострадал в значительно меньшей степени.

Причины же отказов были разными. 27 февраля мы получили сообщение от мониторинга о резком всплеске нагрузки на сервере Neon. Выяснение причин всплеска заняло некоторое время, в течение которого пул подключений к СУБД оказался занят полностью и сервер mysql0 перестал принимать новые подключения.

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

Тем временем наши специалисты обнаружили источник проблемы: сразу несколько проектов, на которых запущены популярные форумные движки вроде SMF подверглись атаке ботнета: с большой скоростью в 20-30 потоков в них размещались автоматически спам-записи. Форумы оказались с необязательной регистрацией и без проверки капчи. Они честно записывали любой поступивший POST-запрос в базу, открывая столько подключений, сколько пришло запросов.

Автоматическая система предодвращения флуда не среагировала на эту атаку, т.к. количество запросов в момент времени с одного IP-адреса было сравнительно невелико для принятия решения о блокировке этого адреса.

Мы заблокировали проблемные проекты до выяснения обстоятельств, перезапустили СУБД mysql0 и все проекты, которые его используют. На этом инцидент был исчерпан и сервис продолжил нормальную работу до утра 28 февраля.

28 февраля мы получили сообщение о резком росте нагрузки на сервер mysql0, при этом наблюдалась очень высокая дисковая активность. При этом в таблице активных запросов не было ничего необычного или странного. Дальнейшее разбирательство показало, что проблема кроется в части нашей панели управления: модуль исполнения задач, запущенный на сервере mysql0 начал активно увеличивать потребление памяти и занял ее всю, что и привело к активному использованию дисков для сохранения страниц памяти в swap.

Перезагрузка этого модуля и перезапуск MySQL помогли — ситуация моментально стабилизировалась.

Такое поведение наших компонент происходит впервые и нашим разработчикам пришлось поломать голову, в чем же причина? Выяснилось, что наложились три фактора: ошибка в коде компонента, нетипичное задание в работу от клиента и ошибка в интерпретаторе ruby, которая в других ситуациях не проявляется.

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

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

Компенсации за неработу проектов будут начислены в течение этой недели всем клиентам, чьи проекты используют СУБД сервера mysql0.

К сожалению, это означает, что мы не можем отфильтровать запросы так, чтобы не сломать работу проектов — JSON, в отличие от XML, используется в вебе очень широко.

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

Для обновления Rails ветки 2.3 вам необходимо отредактировать файл config/environment.rb, заменив строку:

RAILS_GEM_VERSION = '2.3.16' unless defined? RAILS_GEM_VERSION

Для обновления Rails ветки 3.0 пропишите нужную версию Rails в ваш Gemfile

gem "rails", "~> 3.0.20"

Будьте внимательны.

Rvm, Bundler, Capistrano — все эти инструменты сильно облегчают жизнь разработчику и администратору проекта, но могут изрядно запутать. В этой статье мы наглядно покажем процесс деплоя распространенной системы управления проектами Redmine.

Создаем новый Ruby On Rails проект

1. Выбираем тип проекта «Ruby on Rails»
2. Задаем имя будущему проекту
3. Создаем. Панели нужно две-три минуты, чтобы создать всё необходимое для работы проекта, после чего можно продолжать. Около 15 минут необходимо, чтобы проект начал отзываться по присвоенному ему DNS-имени.

Обратите внимание на созданную базу данных, она нам еще пригодится.

Загружаем дистрибутив

Новые версии Redmine замечательно работают с Ruby 1.9.3, поэтому, настройки проекта по умолчанию нам подойдут. Мы будем ставить последнюю на момент написания статьи стабильную версию Redmine 2.0.3.

Узнаём параметры входа на сервер по ssh

Начинаем работать с терминалом. Заходим на сервер

Переходим с свежесозданный каталог проекта

$ cd projects/redmine

Удаляем автоматически созданные файлы

$ rm -rf ./current/*

Загружаем архив с исходниками Redmine

$ wget http://rubyforge.org/frs/download.php/76259/redmine-2.0.3.tar.gz

Распаковываем архив

$ tar xvf redmine-2.0.3.tar.gz

Переписываем симлинк current на распакованный Redmine

$ rm current
$ ln -s redmine-2.0.3 current

Подготавливаем окружение

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

Переходим в каталог с исходниками

$ cd current

Подготавливаем бандл. Хотя Gemfile уже идет в поставке Redmine, хостинг Locum использует сервер приложений Unicorn для запуска проектов, поэтому в Gemfile необходимо внести изменения

$ echo 'gem "unicorn"' >> Gemfile

Теперь можно создать бандл

$ rvm use 1.9.3 do bundle install --path=~/projects/redmine/shared/gems --without development test

Этот процесс обычно занимает около пяти минут. Теперь нужно поправить конфигурацию базы данных для проекта. Узнаем параметры подключения к БД в панели управления хостингом. Заходим в «Услуги — Проекты», нажимаем «Подробнее» на проекте redmine, далее в графе «Ресурсы» нажимаем на ссылку с базой данных.

Возвращаемся в терминал. Копируем файл конфигурации БД из поставки Redmine

$ cp config/database.yml.example config/database.yml

Редактируем файл с настройками, вписываем параметры подключения нашей базы

Обратите внимание на адаптер базы, для Ruby 1.9 это должен быть mysql2. Вторая частая ошибка — имя хоста. Обязательно внесите хост со страницы с параметрами подключения БД.

Сохраняем изменения: Ctrl+O, Ctrl+X.

Выполняем настройку проекта

Следуем инструкции по установке, выполняем таски, необходимые для запуска проекта. Особенность хостинга — все команды нужно оборачивать в rvm и bundle.

$ rvm use 1.9.3 do bundle exec rake generate_secret_token
$ RAILS_ENV=production rvm use 1.9.3 do bundle exec rake db:migrate

В нашем примере мы загрузим тестовые данные в проект

$ RAILS_ENV=production rvm use 1.9.3 do bundle exec rake redmine:load_default_data

Правим права доступа к каталогам

$ chmod -R 755 files log tmp

Перезапускаем сервер приложений

Установка практически завершена. Все, что осталось сделать, это перезапустить сервер приложений, обслуживающий наш проект. Из терминала выполняем команды:

$ kill -QUIT `cat /var/run/unicorn/hosting_redmine/redmine.redmine5.pid`
$ rvm use 1.9.3 do bundle exec unicorn_rails -Dc /etc/unicorn/redmine.redmine5.rb

Проверяем, что сервер приложений запустился и проект работает. В панели управления идем в «Услуги — Проекты», напротив проекта redmine нажимаем на ссылку с его доменом. Авторизуемся учетной записью по умолчанию admin/admin.

Можно приступать к настройке непосредственно самого Redmine.

Если что-то пошло не так, полезную информацию можно найти в логах в каталоге проекта ~/projects/current/log

• production.log — основной журнал Redmine. Ошибки уровня приложения пишутся сюда.
• unicorn.stderr.log — журнал ошибок запуска Unicorn. Недостающие библиотеки и проблемы запуска сервера приложений запишутся сюда.

Причины сбоя будут установлены и ликвидированы в процессе выполнения работ, об окончании сообщим дополнительно.

Во время проведения работ возможно временное прекращение доступа к вашим проектам.

Благодарим за понимание.

• запрещена отпрака почты и создание почтовых аккаунтов на тестовом периоде;
• введено ограничение на 25 получателей одного письма в поле «To»;
• установлено ограничение на скорость отпраки писем — пять в минуту.

Мы надеемся на понимание, и что эти ограничения никак не затронут вас.

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

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

Что случилось?

Мы долго шли к этому, и все-таки это состоялось. Теперь по умолчанию используется rvm и bundler на всех новых проектах. Старые проекты не будут затронуты до тех пор, пока вы сами не начнете переключать версию ruby в настройках. Подумайте — стоит ли делать это, если все работает.

Зачем?

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

Ruby 1.8.7 уже устарел, тем более в новых версиях Ruby On Rails его поддержка со временем прекратится. Сейчас все наши пользователи могут использовать самые последние версии ruby, да и к тому же переключаться между ними. Переведите свой проект на 1.9.3 и наслаждайтесь производительностью. Конечно, перед этим необходимо установить нужные gem для этой версии ruby. Об этом читайте далее.

Как теперь все работает?

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

Теперь для запуска процессов нужно будет указывать какая версия ruby вам нужна. Для этого используется Ruby Version Manager или сокращенно — RVM. Наверняка многие из вас уже знакомы с этим средством переключения между различными версиями ruby. Если нет — обратитесь к официальной документации, она довольно проста и понятна.

Как же теперь запускается unicorn?

Для этого нужно выполнить следующую команду:

rvm use <версия> do bundle exec unicorn_rails -Dc /etc/unicorn/<имя_проекта>.<логин_в_панель_управления>.rb

Вместо <версия> нужно подставить одно из следующих значений, что и будет определять версию ruby, которая используется на данный момент:

• 1.9.3
• 1.9.2
• ree-1.8.7 (это Ruby Enterprise Edition)
• 1.8.7

Перезагрузка кода

Тут ничего не поменялось, так как нам нужно всего лишь отправить сигнал USR2 мастер-процессу, это делается и без rvm:

kill -USR2 `cat /var/run/unicorn/<имя пользователя на сервере>/<имя_проекта>.<логин_в_панель_управления>.pid`

Как всегда логи находятся в logs/unicorn.*.log, и если вдруг после отправки сигнала ничего не поменялось — это хороший повод заглянуть в них. Полная остановка unicorn делается аналогично, но сигнал будет QUIT, вместо USR2.

Почему bundler а не rvm gemsets?

Этот вопрос может возникнуть у знакомых с работой rvm пользователей. Ответ довольно просто — gemsets не предназначены для работы в разделяемой среде между несколькими пользователям — будут проблемы прав доступа. Тем более bundler стал стандартным средством ограничение области видимости gem а так же их установки и обновления, независимо от того используется вообще rvm или нет. Большинство проектов у нас используют bundler уже сейчас, а уж все новые так и тем более должны это делать.

Куда ставить bundle?

Мы рекомендуем ставить в ../../shared/gems, сделать это можно указав нужный параметр при выполнении команды (предполагается, что команда выполняется в RAILS_ROOT):

bundle install --path ../../shared/gems

Shared — чтобы не переустанавливать все gem после каждого деплоя, а просто вызывать bundle update.

Как переключать версии?

Войдите в раздел «Услуги»->»Проекты», далее нажмите на ссылку «подробнее» напротив нужного проекта в таблице, откроются параметры проекта. Там вы увидите поле с версией ruby, выберите интересующую вас версию и нажмите кнопку сохранения параметров.

Что при этом произойдет?

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

Итак, по умолчанию у нас запущен проект с ruby 1.9.3, если мы сменили версию, то вначале будет удалена директория ../../shared/gems, так как система предполагает, что ваши gem стоят там. Удалять директорию приходится потому, что bundler не может понять иногда, что native extension того или иного gem собран был для другой версии ruby и попытается использовать его не пересобирая, что приведет к ошибке и падению unicorn. Конкретно такая проблема наблюдается при смене версии с 1.9.3 до 1.9.2, если не удалить все gem и не поставить снова.

После этого в RAILS_ROOT (projectname/current) будет выполнена команда bundle install —path ../../shared/gems, а затем — полная остановка unicorn и запуск его с указанием новой версии ruby для rvm.

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

Почему не rvmrc?

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

Что по умолчанию?

По умолчанию создается «пустой» rails-проект (по сути то, что получаем после rails new) с ruby 1.9.3 и rails 3.1.1

Кстати, не удивляйтесь, что ссылка «About your application’s environment» не работает — по идеологии Ruby On Rails она должна работать только в development-окружении, а на хостинге все запускается в production.

Что станет с Capistrano?

Как всегда мы предполагаем, что для размещения кода на сервере будет использоваться Capistrano. RVM этому никак не помешает, просто мы теперь генерируем deploy.rb c учетом использования rvm.

Получить deploy.rb для каждого конкретного проекта можно в вашей панели управления услугами Locum.ru. Войдите в раздел «Услуги»->»Проекты», далее нажмите на ссылку «подробнее» напротив нужного проекта в таблице, откроются параметры проекта. Там вы увидите кнопку для генерации deploy.rb, нажмите ее и получите содержание файла с учетом rvm.

Обычно для того, чтобы начать пользоваться Capistrano достаточно просто добавить в deploy.rb ссылку на вашу систему контроля версий, настроить авторизацию по ключам на наш сервер. а так же с нашего сервера к вашей системе контроля версий (git, svn, mercurial). Если вы нигде еще не разместили свой проект в контроле версий, то можете создать гит репозиторий на нашем сервере, об этом у нас есть соответствующая заметка в блоге.

Имейте ввиду, что если вы измените версию ruby для проекта, вам необходимо будет поменять ее и в вашем deploy.rb.

Что делать с моими старыми проектами?

Решение остается полностью за вами. Если вы знаете что такое rvm и понимаете зачем вам нужно перейти на новую версию, или даже если понимаете, что это не имеет смысла но хочется (бывает такое, не правда ли?), вы всегда можете это сделать. А так — просто не трогайте их, с ними ничего не произошло.

На что еще важно обратить внимание?

Всегда помните, что все команды ваши теперь следует запускать в rvm и bundle, т.е. вместо

rails c

мы используем

rvm use <версия> do bundle exec rails c

И только так входим в консоль. Мы всегда рекомендуем вызывать команду явно, а не полагаться на rvmrc, фазу луны или еще что-нибудь. Так меньше вероятность совершить ошибку, потому что довольно легко забыть изменить версию в rvmrc и потом долго думать от чего не работает.

Заключение

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

Главный вопрос, возникающий после выбора системы контроля версий: где же хранить репозиторий, в котором будет лежать полная история развития вашего проекта?

В случае использования распределённой системы контроля версий Git и виртуального хостинга Locum, этот вопрос можно решить буквально одним движением руки, не прибегая к использованию дорогостоящих тарифных планов GitHub или Assembla.

Итак, допустим, что у нас есть некоторый проект, репозиторий которого можно сохранить на хостинге Locum, и пусть он находится в каталоге meet.git.

Для начала узнаем название вашего сервера виртуального хостинга. Эту информацию вы можете посмотреть в нашей клиентской панели: вкладка «Услуги» → раздел «FTP и SSH».

Зайдём на сервер виртуального хостинга через SSH и подготовим окружение для работы Git.

% ssh hosting_ПОЛЬЗОВАТЕЛЬ@ВАШ_СЕРВЕР.locum.ru

% mkdir -p ~/git/meet.git

% cd ~/git/meet.git

% git init --bare

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

Работа с репозиторием будет проводиться поверх протокола SSH, поэтому лучше избавиться от постоянного требования ввода пароля, добавив свой публичный SSH-ключ в список авторизованных ключей на сервере: достаточно просто скопировать ваш публичный SSH-ключ в конец файла ~/.ssh/authorized_keys, а если такого файла не существует, то достаточно будет просто создать его.

На самом деле, всё это можно легко автоматизировать. Выполните данную команду на вашем локальном компьютере:

% cat ~/.ssh/id_rsa.pub | ssh hosting_ПОЛЬЗОВАТЕЛЬ@ВАШ_СЕРВЕР.locum.ru 'cat >> ~/.ssh/authorized_keys' 

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

% ssh hosting_ПОЛЬЗОВАТЕЛЬ@ВАШ_СЕРВЕР.locum.ru 'chmod 0700 ~/.ssh' 

Отлично, теперь работа с нашими серверами при помощи SSH станет гораздо проще и комфортнее, без какого-либо ущерба безопасности. Главное — мы выполнили все приготовления для функционирования Git.

Создадим в директории вашего проекта на локальном компьютере Git-репозиторий:

% cd meet.git

% git init 

Добавим в учёт все файлы вашего проекта:

% git add . 

Пока не поздно, можно сделать ревизию состояния всех файлов:

% git status 

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

% git commit -m 'initial commit' 

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

Для того, чтобы Git обеспечил согласование вашего локального репозитория с его братом-близнецом на сервере Locum, нужно определить точку синхронизации. Это не является обязательным пунктом, ведь оба репозитория являются полноценными, и возможность согласования — всего лишь приятная возможность. В системе Git точки синхронизации называются remotes и являются именованными. Как правило, единственная точка синхронизации носит гордое имя origin.

% git remote add origin ssh://hosting_ПОЛЬЗОВАТЕЛЬ@ВАШ_СЕРВЕР.locum.ru/home/hosting_ПОЛЬЗОВАТЕЛЬ/git/meet.git 

Теперь попробуем впервые отправить наши данные на сервер. В терминологии Git это зовётся push. При этом необходимо указать целевую точку синхронизации и название ветке, в которую публикуются изменения. По-умолчанию все данные в Git лежат в ветке master.

% git push -u origin master

Counting objects: 3, done.

Writing objects: 100% (3/3), 211 bytes, done.

Total 3 (delta 0), reused 0 (delta 0)

To ssh://hosting_ПОЛЬЗОВАТЕЛЬ@ВАШ_СЕРВЕР.locum.ru/home/hosting_ПОЛЬЗОВАТЕЛЬ/git/meet.git

* [new branch] master -> master

Branch master set up to track remote branch master from origin. 

Команда push вызвана с ключом -u, который заставляет Git запомнить, что вы предпочитаете делать push и обратный ему процесс pull в ветке master точки синхронизации origin. С этого момента никаких дополнительных параметров для команд git push и git pull вам не понадобится.

Кстати, если после выполнения последней команды вы увидели аналогичный результат в вашем терминале, то Git функционирует корректно. Для того, чтобы это проверить, попробуем выполнить клонирование (скачивание) новоиспечённого репозитария. Попробуйте выполнить эту команду, находясь в какой-либо директории, не содержащей каталог meet-git:

% git clone 'ssh://hosting_ПОЛЬЗОВАТЕЛЬ@ВАШ_СЕРВЕР.locum.ru/home/hosting_ПОЛЬЗОВАТЕЛЬ/git/meet.git'

Cloning into meet-git...

remote: Counting objects: 3, done.

remote: Total 3 (delta 0), reused 0 (delta 0)

Receiving objects: 100% (3/3), done. 

Удалось? Поздравляем, у вас теперь есть собственный приватный Git-репозиторий, в котором вы можете самостоятельно заниматься разработкой вашего проекта, не беспокоясь о сохранности исходного кода. Удачи!

Для дальнейшего чтения мы можем посоветовать русскоязычный перевод книги Pro Git.

P.S. Кстати, если вам нужно подключить к репозиторию своих сотрудников, то просто пропишите их публичные SSH-ключи в конец списка авторизованных ключей (см. выше) и попросите выполнить git clone с известным вам адресом.

Странные сообщения об ошибках

Если вы читаете эту статью, то вполне вероятно вы видели такую ошибку, несмотря на то, что gem  с нужной версией ruby on rails у вас установлен.

Missing the Rails 2.3.8 gem. Please `gem install -v=2.3.8 rails`, update your RAILS_GEM_VERSION setting in config/environment.rb for the Rails version you do have installed, or comment out RAILS_GEM_VERSION to use the latest version installed.

Или может быть такую?

You have already activated ** rack** 1.1.0, but your Gemfile requires rack 1.0.1. Consider using bundle exec. (Gem::LoadError)

Версии, указанные в примерах могут, конечно, отличаться, но сути это не меняет.  В этой статье я объясню от чего такое возникает и как этого избежать.

Rack и проблемы, связанные с ним

Всему виной rack, точнее несоответствие его версии тому, что хочет видеть rails. Причем первое сообщение об ошибке очень странное, никаким образом не упоминает rack и даже никак не намекает на него, но давайте посмотрим в код, который выводит это сообщение. Открывает config/boot.rb, и видим:

class GemBoot < Boot
   def load_initializer
       self.class.load_rubygems
       load_rails_gem
       require 'initializer'
   end
   def load_rails_gem
       if version = self.class.gem_version
          gem 'rails', version
      else
          gem 'rails'
      end
      rescue Gem::LoadError => load_error
          $stderr.puts %(Missing the Rails #{version} gem.

          Please `gem install -v=#{version} rails`,

          update your RAILS_GEM_VERSION setting in config/environment.rb

          for the Rails version you do have installed,

          or comment out RAILS_GEM_VERSION

          to use the latest version installed.)

          exit 1
      end

Тут-то и становится понятно, что это сообщение выводится не только когда не удается загрузить именно rails, но и в любом другом случае, когда возбуждается исключение Gem::LoadError. Стоит отметить, что в последующих версиях rails (где-то после 2.3.10), сообщение об ошибке стало более информативно, и пользователи перестали предпринимать отчаянные попытки установить нужный gem несколько раз подряд, до этого видимо авторы rails не подозревали, что такое исключение может возникнуть в иной ситуации.

Вторая ошибка уже более информативна и подсказывает нам, что дело тут в rack, как это на самом деле обстоит и в первом случае. Суть в том, что отличный сервер для rails — unicorn, использует rack для своей работы. Современные версии Ruby On Rails так же используют rack для своей работы, и необходимо, чтобы они использовали одну и ту же версию. Иначе будем получать такие вот ошибки, потому что вызов activate! у rack во время загрузки rails не пройдет.

Очевидным решением было бы добавить в config/environment.rb строку следующего вида:

config.gem 'rack', '=1.0.1'

Однако, попробовавшие это решение будут разочарованы — ничего не поменяется. Проблема в том, что unicorn вначале запускается сам, загружает свой код и активирует rack. Причем написан он довольно грамотно и активировать будет самую новую версию, которая есть, работает он с ней нормально. И уже только после этого unicorn будет пытаться загрузить Ruby On Rails, только тогда считается environment.rb и эта строка, но более новый rack уже будет активирован.

Еще одним простым решением будет просто удалить локальную инсталляцию более нового rack, оставив только нужную нашему rails-проекту версию, но такое решение подходит лишь для тех, у кого один проект, или на всех проектах нужен один и тот же rack. Если у вас есть проекты, например на rails 2.3.8, 2.3.11 и 3.0.2 — вам потребуется для каждого из них своя версия rack и вариант с удалением не подойдет.

Тут на выручку приходит bundler.

Решаем проблему с помощью bundle

Bundler — это средство управления различными окружениями gem. Он легко позволяет создать изолированную инсталляцию gem для конкретного проекта, чтобы остальные, установленные на локальной машине gem не мешали работать. Так же при помощи bundler удобно устанавливать большие пачки gem в системные или иные директории. На всех серверах Locum.ru bundler уже установлен. Если при попытке выполнить команду bundle вы получаете ошибку:

bash: bundle: команда не найдена

То убедитесь, что у вас правильно настроена переменная окружения PATH. Мы рекомендуем устанавливать следующее значение PATH=»/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/$HOME/.gem/ruby/1.8/bin:/var/lib/gems/1.8/bin».

Подробнее о том, как работать с bundler и что он позволяет вы всегда сможете узнать в официальной документации, тут же мы кратко рассмотрим только ограничение версий нужных нам gem. Итак, для начала создаем Gemfile. Gemfile — это такой список используемых в проекте gem, с указанием нужных версий. Если версию не указать — будет доступна самая последняя из установленных. Важно перечислить все gem, необходимые для работы проекта, так как то, что не указано в Gemfile, не будет доступно из кода ни rails, ни unicorn. Ровно по этой же причине необходимо добавить сам unicorn в список. Gemfile должен находиться в той директории, откуда запускается unicorn, т.е. в нашем случае это current в каталоге capistrano, RAILS_ROOT. Если вы используете систему контроля версий, рекомендуем поместить Gemfile  в нее, так как он будет нужен для каждого деплоя.

Вот пример Gemfile для запуска redmine из trunk:

source "http://rubygems.org"
gem "unicorn"
gem "rack", "1.1.0"
gem "rails", "2.3.11"
gem "rake", "0.8.7"
gem "i18n", "0.4.2"
gem "rubytree", "0.5.2", :require => "tree"
gem "RedCloth", "~>4.2.3", :require => "redcloth" # for CodeRay
gem "mysql"
gem "coderay", "~>0.9.7"

Сохранив такое содержимое рекомендуем выполняем следующие команды (все запускается из директории current):

bundle install --path ../../shared/gems

kill -QUIT `cat /var/run/unicorn/имя_пользователя_на_сервере/имя_проекта.логин_в_панели_управления.pid`

bundle exec unicorn_rails -Dc /etc/unicorn/имя_проекта.логин_в_панели_управления.rb

Первая команда должна установить все gem с нужными версиями (просто так, на всякий случай), важно не забывать про ключ —path, потому что иначе bundler будет пытаться установить все в системную директорию и требовать с вас пароль на sudo. Вторая — остановить уже запущенный экземпляр unicorn для проекта. Если он упал ранее по причине ошибки — ничего страшного, PID-file просто будет отсутствовать. Последняя команда стартует unicorn в созданном нами окружении bundle. После этого все должно работать, перезагрузка кода так же выполняется отправлением сигнала USR2. Так же для этого есть специальная кнопка в панели управления хостингом Locum.ru.

Если вы используете capistrano, как мы всем рекомендуем, то нужно добавить вызов bundle exec перед командой запуска unicorn в ваш deploy.rb.

Иногда при работе со старыми версиями Rails возникает ошибка, примерно следующего вида:

uninitialized constant ActiveSupport::Dependencies::Mutex (NameError)

Эта проблема не связана с bundle и rack, но возникает не редко, связанно это с изменениями в новых версиях rubygems, на которые не рассчитаны старые версии rails. Решается проблема добавлением вызова require ‘thread’ в config/environment.rb или config/boot.rb. Спорный вопрос в какой из этих файлов идеологически правильнее добавить вызов, но сработают оба варианта. Кто имеет четкое мнение по этому вопросу — напишите, пожалуйста, в комментариях. Что до меня, так идеологически правильным я вижу только одно решение — обновить версию rails до такой, где ошибки не возникает, а все остальное примерно одинаково костыль, но костыль абсолютно рабочий.

Подведем итог

Bundler — действительно удобное средство для решения таких проблем. Любая система установки дополнительных пакетов, вроде rubygems, которая позволяет держать много версий одной и той же библиотеки, в итоге должна столкнуться с проблемами конфликтов версий и как-то их решать. Недостатком является только то, что саму версию rubygems выбрать при помощи bundler никак не получится, но это нужно уже совсем редко, в таких ситуациях придется скорее всего решать проблему при помощи RVM. Процесс деплоя с bundler не сильно усложнился, тем более все это так же легко автоматизируется с Capistrano.  Ограничивать версию разных gem для rails можно было и раньше, используя вызовы config.gem в environment.rb и хорошим тоном всегда считалось перечислять там нужные gem. Сейчас просто ограничивается набор gem не только для rails, но и для сервера приложений, а вызов bundle install просто заменяет нам старое rake gems:install.

На этом прощаемся с вами, всем удачи в развитии своих проектов и их размещении на Locum.ru. Кстати, кто-нибудь сталкивался в своей практике с необходимостью ограничить версию чего-то еще не только для самого rails-приложения, но и для сервера, кроме Rack? Если да — напишите, пожалуйста, об этом в комментариях. Пока по общению с нашими клиентами и собственной практике разработки и деплоя мы не встречались с другими примерами.

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

Базовый тариф и типы сервиса

Для многих из вас не секрет, что в предыдущей версии хостинг и виртуальные серверы были разными типами сервиса, не совместимыми на одном аккаунте. Тем из наших клиентов, кто пользовался виртуальным сервером и хостингом одновременно, необходимо было иметь разные учетные записи. Сейчас эти ограничения исчезли. На одном аккаунте можно приобретать как виртуальный хостинг, так и виртуальные серверы, а так же, ряд дополнительных услуг. Если у вас есть несколько аккаунтов, и вы хотите объединить их в один — создайте соответствующий запрос в техническую поддержку, и наши специалисты помогут вам. Объединение двух тарифов аккаунтов с хостингом пока не предусмотрено, но такая возможность должна появиться в будущем, в том или ином виде. Ресурсы и средства всех этих аккаунтов будут объединены.  Теперь, количество виртуальных серверов на одном аккаунте  не ограничено .

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

Выбрать, какие услуги отображать, а какие скрывать, вы можете в разделе «Аккаунт» во вкладке «настройки».

Почасовая тарификация

В предыдущей версии вам были доступны 2 периода оплаты, и стоимость тарифа зависела от срока, на который пользователь его оплачивал . Сейчас, все ресурсы тарифицируются по часам. Исключение составляют домены, так как, по правилам регистрации, их необходимо оплачивать на 1 год или больший срок. Каждый час наша система биллинга проводит списание средств, если средств на балансе на момент списания недостаточно для оплаты следующего часа обслуживания, то аккаунт будет заблокирован. Пополнив баланс, пользователь сможет разблокировать аккаунт. Для удобства клиентов сохранена информация о стоимости ресурсов в день и месяц.

Ресурсы: тарифные и дополнительные

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

Бесплатные домены и иные бонусы

Как и раньше, при единовременном платеже в 1500р, вы получаете на баланс бонусные 390р. Именно об этом идет речь, когда в описании тарифа говорится о бесплатном домене, при оплате за год. Эти средства могут быть потрачены как на покупку или продление доменов, так и на любые другие, предоставляемые нами услуги, на ваше усмотрение. Бонус начисляется за каждые 1500р, то есть, при единовременном платеже в 3000р вы получите 780р бонусных средств.

Переход от старой системы к новой и перерасчет

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

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

В скором будущем: партнерская программа

Так же хотелось упомянуть, что в скором времени готовится релиз партнерской программы для клиентов locum.ru. Она позволит получать реальные денежные  средства за привлеченных клиентов и отлично подойдет всем, кто так или иначе связан с разработкой web ресурсов. Более подробно о партнерской программе мы сообщим после ее запуска. Следите за новостями!

В этой статье я расскажу как проще и удобнее всего разворачивать приложения на ruby on rails на нашем хостинге. Используя эту инструкцию вы сэкономите время и легко обнаружите ошибки, которые могут возникать при развертывании Rails-приложений. Так же будет информация о самых частых проблемах и о том, как их избежать. Описанный метод так же подходит и для Rack-приложений, с некоторыми оговорками и незначительными изменениями в конфигурационных файлах.

Сервер приложений.

На серверах locum.ru для Rails-приложений по умолчанию используется unicorn. По запросу можно создать проект, который будет использовать Phusion Passenger, но обычно это не требуется. Unicorn зарекомендовал себя как быстрый и очень гибкий в использовании сервер для rails и rack.

Определяем нужную версию Rails.

Итак, мы решили разместить приложение на ruby on rails на сервере locum.ru. Первое что нам нужно знать — версию Ruby On Rails, которую использует наше приложение. Если это Rails ветки 2.3 и версия выше 2.3.5 — дополнительные действия не нужны. Можно сразу переходить к следующему шагу. Приложение на Rails 2.3.5 и старше скорее всего не получится запустить на Unicorn, из-за несовместимости этих версий с нужной версией Rack. Стоит отметить, что для большинства приложений будет достаточно просто поменять версию фреймворка на 2.3.6 в config/environment.rb, чтобы все заработало на unicorn, например с популярным issue-трекером Redmine это легко решает проблему запуска.

Если наше приложение использует rails 3.X, первым делом следует войти по ssh на сервер и установить соответствующий gem. Для этого нужно выполнить команду:

gem install rails --user-install --no-rdoc --no-ri

Если хочется использовать Bundler и устанавливать gem вне стандартного пути «~/.gem»,  то нужно установить хотя бы rack версии 1.2 в стандартный путь для gem аналогичной командой:

gem install raсk --user-install --no-rdoc --no-ri

Дело в том, что unicorn при старте запускается вне bundle, поэтому он будет использовать rack 1.1, и не сможет запустить приложение, требующее более новую версию rack, так же как и не сможет заменить в процесс работы уже активированную версию rack на более новую. Это является особенностью работы rack и часто приводит к ошибкам, если не помнить о ней.

Создание проекта из панели управления.

Теперь нужно зайти в панель управления и создать проект для нашего приложения. Заходим в раздел «проекты», создаем новый проект с типом Ruby On Rails. Если планируется использовать отличную от MySQL базу данных, то отключаем пункт «создать базу данных», так как по умолчанию создается база именно этого типа.

Размещение кода на сервере.

Создание проекта занимает некоторое время, но после этого у вас на сервер в директории projects появится директория с именем проекта, а в ней стандартная структура каталогов для Сapistrano.  Удобнее всего использовать именно capistrano для загрузки кода на сервер. Это стандартное средство, которое позволяет легко обновлять версию кода, перезапускать сервер приложений, а так же многое другое. Пример конфигурационного файла, адаптированного для использования с нашим хостингом и unicorn можно скачать по следующей ссылке: http://locum.ru/examples/deploy.rb

Заменив в примере нужные значения вы сможете легко загрузить ваш проект на сервер и перезапустить unicorn командой «cap deploy».

Если не хочется использовать capistrano — это не проблема, можно обойтись и без  нее. Структура директорий такова:

имя проекта/
   current -> текущий каталог для unicorn, является символической ссылкой на одну из версий в релизах
   releases/ -> директория с версиям приложения
       initial_release/ -> созданное по умолчанию приложение

Вам нужно разместить код вашего приложения в директории внутри releases, имя выберите произвольно, а затем изменить ссылку current, чтобы она указывала на директорию с вашим приложением, вместо initial_release, сделать это можно командой ln -sf по ssh.

Типичной ошибкой является удаление директории initial_release или всех файлов в ней.  Дело в том, что у нас unicorn использует очень удобный метод перезапуска. Когда приходит команда на перезагрузку сервера, запускается новый экземпляр unicorn, загружается код и затем, если все в порядке — новый экземпляр замещает предыдущий, а старый завершается. Сам процесс немного сложнее, но полное описание работы unicorn выходит за рамки этой статьи. Так как старый процесс был запущен в то время, когда ссылка current указывала на каталог initial_release, то и лог пишется там. Если новый экземпляр unicorn не сможет запуститься, то информацию об ошибке следует искать в файле log/unicorn.stderr.log именно по старому пути. Если эти файлы удалить, unicorn будет все еще пытаться писать по открытому заранее дескриптору, но прочитать мы эти данные уже не сможем. Если директория initial_release вам чем-то мешает, то вы всегда сможете удалить ее позже, после того как эти файлы уже перестанут использоваться.

После того, как файлы размещены и ссылка current изменена следует зайти в подробности проекта в панели управления хостингом и нажать кнопку «перезагрузить сервер».  В случае использования capistrano, сервер будет перезапущен автоматически. Через минуту вы можете зайти на URL вашего проекта и увидеть свое приложение в работе.

Распространенные ошибки, где их искать и как избежать.

Опыт показывает, что самой распространенной проблемой при размещении rails-приложений на нашем хостинге является  нехватка того или иного gem или же нужной его версии. Этого можно избежать, если описывать все, необходимые для работы кода gem в environment.rb и выполнять rake gems:install перед перезагрузкой unicorn с новым кодом. Так же можно использовать bundler и выполнять bundle install. Имейте ввиду, что команда bundle по умолчанию будет пытаться установить gem в системные директории, что конечно же не удастся сделать без root-доступа. Поэтому не забывайте всегда использовать ключ —path с указанием пути, куда вы хотите устанавливать локальные gem. Можно делать это, например, в директорию «~/.gem».

Так же, некоторые пользователи банально забывают внести нужные настройки для базы данных в database.yml. Не забывайте, что на нашем хостинге все проекты запускаются в режиме ‘production’, а значит и настройки нужно вносить в соответствующей секции database.yml

Что делать, если после перезагрузки кода unicorn на сайте проекта ничего не поменялось? Это значит, что новый экземпляр unicorn не смог запуститься по какой-то причине. Для выяснения причины нужно посмотреть последние строки файла log/unicorn.stderr.log в той директории, где запущена версия unicorn, которая осталась работать. При загрузке нового приложения это будет releases/initial_release.

Еще одна частая ошибка, это попытка зайти на домен, созданный для проекта сразу после появления его в панели управления. Дело в том, что для перезагрузки конфигурации DNS-сервера требуется некоторое время, потому лучше подождать несколько минут. В противном случае можно оказаться в неприятной ситуации. DNS сервер вашего провайдера может кэшировать ответы на запросы, если вы зайдете слишком рано и получите ответ, что такого домена нет, и это попадет в кэш, может получиться, что после того, как наш DNS сервер уже начнет сообщать IP-адрес этого домена, вы  все еще будете получать ошибочный ответ из кэша.

Коллектив Locum.ru желает успеха всем нашим пользователям в разработке и размещении проектов.

Уже созданные проекты, тем не менее, продолжают работать под управлением Phusion Passenger, и, если вас не устраивает производительность, то из этой статьи вы узнаете, как правильно и с минимальными усилиями изменить способ запуска вашего проекта.

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

В окне свойств перейдите к базе данных вашего проекта.

В свойствах базы данных нажмите кнопку «Отвязать» напротив названия проекта.

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

Используя логин и пароль в разделе «FTP и SSH», подключитесь к серверу, зайдите в каталог projects и переименуйте директорю с вашим проектом.

Удалите проект через панель управления хостингом.

После того, как проект исчезнет из списка (на это может уйти некоторое время), создайте новый Rails-проект с точно таким же именем. При этом базу данных создавать не нужно.

Дождитесь, пока проект перейдет в состояние «Готово», после чего вернитесь к менеджеру файлов по FTP.

В каталоге projects вы увидете две директории: архивная с вашим проектом и новая с именем вашего проекта, которая была создана только что. Удалите только что созданную директорию, после чего переименуйте архивный каталог обратно.

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

Привяжите к проекту все нужные вам домены.

Несколько важных моментов

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

kill -USR2 `cat /var/run/unicorn/project.hosting_user.pid`

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

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

Все говорят о Rails 3, некоторые его уже пробуют, а некоторые даже используют в production. Некоторые наши клиенты интересуются, работает ли бета этого фреймворка у нас. Не смотря на то, что нужный gem не установлен в системе, его можно поставить локально для пользователя. Зависимости также ставятся без каких-либо нареканий.

Весь процесс занял всего несколько минут ( большую часть времени ждал пока gem подумает ). Дабы не быть голословным, опишу весь процесс по шагам:

1. Создаем проект с типом «Ruby on rails», например с именем «rails3″.

2. Устанавливаем gem. Тут есть небольшая хирость: надо использовать ключ —install-dir с указанием директории установки гема. Чтобы не потерять уже установленные локально, укажем стандартный путь.

>gem install rails --pre --install-dir /home/hosting_<имя_пользователя>/.gem/ruby/1.8

3. После некоторого ожидания можно проверить, какая версия rails установлена.

>rails -v
Rails 3.0.0.beta4

4. Теперь попробуем создать простейшее рабочее приложение:

>cd ~/projects/rails3/releases
>rails new thefirst
>cd thefirst
>rails generate scaffold book name:string price:float
>RAILS_ENV=production rake db:migrate
>rm public/index.html
>nano config/routes.rb # Тут пропишем путь root :to =>; "books#index"
>cd .. ; rm current ; ln -s releases/thefirst current
>touch releases/thefirst/tmp/restart.txt # говорим passenger'у перечитать код приложения

5. Идем по ссылке http://rails3.<имя_пользователя>.locum.ru и видим знакомый всем интерфейс скаффолда.

Как видно, никаких особенных хитростей не понадобилось, все компоненты просто ставятся и работают. В четвертом шаге я описал стандартный способ разворачивания простого rails приложения на locum.ru и способ перезагрузки кода из консоли, так что, если кто-то еще не знал — знайте.

Update:
Обнаружился небольшой нюанс: bundler версии 1.0.0.beta.5 не работает (пытается использовать sudo, что, конечно, запрещено). Нужно использовать стабильную версию, сейчас это 0.9.26.

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

Mongrel

Первый метод, что приходит в голову, — Mongrel cluster. В основном, именно он описан в литературе по ruby on rails, он же используется для запуска rails-кода в режиме разработки (development environment). Все, что необходимо для запуска rails с mongrel cluster уже разработано и идет в стандартной поставке, также готовы и методы для capistrano. Казалось бы: бери, да пользуйся! Но, как говорится, без ложки дегтя тут не обходится.
Как же работает rails-приложение, запущенное при помощи mongrel cluster? Слово cluster в данном случае использовано не случайно. Дело в том, что сервер mongrel умеет обрабатывать одновременно только один запрос, поэтому запускается некоторое количество серверов на разных портах. Чтобы скрыть эти нюансы от посетителей сайта, используется прокси-сервер. Он распределяет между серверами mongrel запросы для своевременной их обработки. Каждый mongrel — это процесс, который выполняется независимо от своих «собратьев». Поскольку все они работают с одной базой данных и одной версией кода, запросы могут приходить на любой из них. Никаких проблем это не вызывает. Если ваш сервер перестал справляться с нагрузкой, вы легко можете добавить к нему еще один, запустив на нем еще некоторое количество серверов mongrel. Изменений в коде приложения для такой кластеризации делать не придется, ведь ruby on rails изначально рассчитан на данный подход. Единственное, придется обеспечить всем серверам доступ к хранилищу сессионных данных. Это могут быть и СУБД, и memcached, и примонтированная сетевая файловая система (NFS). Такое действие необходимо для того, чтобы при случайном распределении запросов по серверам сессия пользователя не терялась, т.к. первый его запрос может обрабатывать один mongrel, второй — уже другой и т.д.
А вот теперь пора поговорить о минусах. Самый очевидный из них заключается в том, что каждый из серверов mongrel в силу своей автономности будет загружать в память собственную копию кода rails, кода приложения и всех необходимых библиотек. Вот вам и обратная сторона простого кода сервера и легкой возможности кластеризации. При среднем проекте каждый mongrel запросто потребляет около 100М памяти. И если запускать на сайт по три сервера mongrel (т.к. одного явно недостаточно), то память будет потребляться в очень больших количествах. Да, сегодня 300-500 мегабайт памяти – цифра не слишком серьезная. Однако не стоит забывать, что речь идет о разделяемом хостинге, а значит число таких сайтов будет измеряться сотнями. В такой ситуации потребление памяти действительно становится проблемой.

Thin

Еще одной слабой стороной сервера приложений mongrel является то, что он обязательно занимает один порт. Это создает возможность для различных коллизий и трудно отслеживаемых ошибок. Например, пользователю A выделены порты 3001, 3002 и 3003. Он остановил на время свой mongrel-кластер, а пользователь B в это время взял и запустил на 3001-м порту собственный. При старте один из серверов mongrel пользователя A обязательно упадет, так как порт, который он собирается прослушивать, уже занят другим процессом. Пользователь A ничего не сможет с этим сделать, ведь он никак не может остановить процесс пользователя B. А тем временем один из трех запросов на сайт пользователя A будет попадать на чужой mongrel, так как фронтенд настроен именно на эти порты. Конечно, обратившись к администрации сервера, пользователь A решит свои проблемы, но осадочек останется… Есть ли выход? Дать определенному пользователю возможность прослушивать только конкретный список портов средствами современных операционных систем не так-то просто, все это лишь еще раз усложнит общую систему. Хорошим решением было бы слушать не порт, а unix сокет, но mongrel не обладает такой возможностью.Еще один известный метод запуска rails приложений – thin. Он разработан с использованием EventMachine и Rack, достаточно хорошо оптимизирован. Это делает его более производительным сервером, чем mongrel. Thin обладает теми же что и mongrel особенностями в вопросах одновременной обработки запросов и кластеризации. В сравнении с mongrel он потребляет меньше памяти, но по-прежнему загружает всю копию rails для каждого экземпляра. Большим и важным для хостеров плюсом thin является то, что он умеет «слушать» unix-сокеты вместо стандартных tcp портов. Это позволяет избежать неприятной проблемы, что была описана в примере для сервера mongrel. Ограничивать права на сокет, по сути являющийся файлом с атрибутами чтения и записи, гораздо проще и удобнее. К тому же работа через unix-сокеты ведется быстрее из-за отсутствия накладных расходов на tcp/ip стэк. Мы по возможности рекомендуем использовать unix-сокеты вместо tcp портов. Это действительно положительно сказывается на скорости работы приложения. В качестве подтверждения — ссылка на некоторые результаты сравнения серверов thin и mongrel с точки зрения производительности.
Настройка и запуск thin не сложнее чем у сервера mongrel, конфигурационный файл по-прежнему представляет из себя YML. Для capistrano так же легко добавить нужный код в deploy.rb, чтобы перезапуск серверов thin происходил автоматически при выкладывании новой версии кода. С thin вместо mongrel хостеру (а значит и пользователям) живется действительно легче. Однако проблема большого потребления памяти все еще остается. Ведь получается, что для каждого проекта независимо от текущего количества запросов будет запущено несколько серверов thin, а каждый из них поместит в память весь код rails и самого приложения.

Passenger

Попробуем решить проблему с памятью при помощи Phusion Passenger, известного также как mod_rails или mod_rack. Passenger — это модуль для популярных сегодня веб-серверов Apache и Nginx. Он изначально создан для запуска большого количества rails приложений. Passenger грамотно распределяет ресурсы и потребляет память по мере необходимости. Проблем с прослушиванием большого количества портов разными процессами тоже, по понятным причинам, нет. При этом в конфигурационном файле можно указать интерпретатор ruby, который будет использоваться для запуска rails. Это при желании позволит использовать ruby enterprise edition и выиграть в потреблении памяти еще до 30%. Для пользователя все опять же остается достаточно прозрачно. Для перезагрузки кода приложения теперь нужно просто создать файл tmp/restart.txt или изменить его время последнего доступа. Это легко автоматизируется средствами capistrano. Каждый проект до сих пор имеет возможность использовать свою версию rails, достаточно лишь установить необходимый gem. Passenger устанавливается при помощи rubygems, затем вам нужно будет скомпилировать модуль для вашего веб-сервера и включить его в сборку. По умолчанию код rails будет запускаться с правами пользователя, который владеет файлом environment.rb. Это поведение вполне удобно для хостера, но при желании его можно изменить соответствующими настройками, описанными в документации. Возможность кластеризации при этом остается, просто уже не диктуется необходимостью: ведь никто не мешает поставить несколько веб-серверов, на которых работает passenger за балансирующим прокси.
Phusion Passenger умеет работать не только с rails, но и с любым приложением, которое следует rack-интерфейсу. Это позволяет запускать код, разработанный с использованием фреймворков Merb, Sinatra и других rack-приложений. Мы выбрали для себя связку Nginx + Passenger как самую выгодную по производительности и удобству для нас и наших пользователей. Использование модуля Nginx вместо Apache обусловлено нежеланием поддерживать лишнее звено в цепи запуска rails приложений без явной необходимости. Ведь чем проще система, тем удобнее ее поддерживать, а значит и работа будет стабильнее.

Смотрите также:

Дорогие друзья! Дружная команда Locum поздравляет вас с Новым годом!

Уходящий 2009-й год ознаменовался запуском нашего проекта в широкую эксплуатацию. Сегодня, в предновогоднюю пору, уже можно подвести некоторые итоги работы Locum и поделиться планами на будущее. Итак, приступим.

За десять месяцев, прошедших со старта проекта, мы исправили более 200 ошибок и учли около 500  пожеланий клиентов. Мы постоянно стремимся обеспечивать самые высокие скорости работы ваших проектов. Среднее время непрерывной работы наших серверов составило около 50 дней, а их доступность — 99,56%.

Для вашего удобства мы запланировали и внедрили такие замечательные вещи как возможность размещения Django-проектов, Passenger для обработки Ruby on rails проектов, а также  услугу виртуального выделенного сервера на базе технологии Xen. Кардинальные изменения претерпел дизайн нашего сайта и панели управления, в итоге став более современным и удобным.

В новом году мы не собираемся останавливаться на достигнутом и будем радовать вас новыми услугами и специальными предложениями (в планах уже значатся более 150 различных усовершенствований!). В их числе:

• долгожданная поддержка Java-проектов на тарифах виртуального хостинга;
• легкая и быстрая установка популярных web-приложений — всего пара минут и вы сможете получить работающий блог или информационный сайт;

• SMS-уведомления пользователей;

• работы по улучшению панели инструментов;

• специально от отдела по работе с клиентами — новая партнерская программа.

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

Накануне праздничных дней хочется сказать теплые слова и пожелания в адрес абсолютно всех наших клиентов! Особенно хочется поблагодарить самых активных посетителей, которые оставляют свои идеи и предложения в системе Reformal. Ни одна из этих здравых мыслей не осталась без внимания, а многие из них будут реализованы уже в самом ближайшем будущем. Следите за нашими анонсами
Отдельное спасибо также тем, кто публикует о нас такие положительные отзывы. Поверьте, нам очень приятно, что вы так высоко оцениваете нашу работу.

Еще раз с праздником! Здоровья и счастья вам и вашим близким! Пусть сбудутся все самые сокровенные и светлые мечты!

Locum — лучший дом для ваших интернет-проектов.

Как это работает? Дело в том, что спам рассылается специальным программным обеспечением, которое ведет себя так же как обычный почтовый сервер, но с некоторыми особенностями. Оно перебирает почтовые сервера и пытается отправить нежелательную корреспонденцию на известные ему адреса. Если почтовый сервер, к которому обращается программа рассылки, сообщает о временной ошибке, то она просто пропускает его и продолжает рассылку дальше. Объемы рассылаемой спамерами почты огромны, а ошибки в доставке таких писем возникают постоянно, поэтому этими ошибками обычно пренебрегают. Нормальный же почтовый сервер всегда пытается повторно доставить письмо, если он получил сообщение о временной ошибке. Суть грейлистинга заключается в том, что при первой попытке отправить почту на определенный адрес сервер сообщает о временной проблеме и заносит данные о сервере отправителе и письме в свою базу данных. Если сервер повторил попытку отправить через некоторое время, то его письмо уже будет принято, а адрес сервера попадет на определенный период в белый список. Почта с серверов из белого списка принимается без задержки. В отличие от честного SMTP сервера, программа, рассылающая спам, обычно не будет предпринимать попыток повторной отправки письма, если при первой попытке возникла ошибка. Таким образом адреса, с которых идет рассылка спама не будут попадать в белый список и эта нежелательная корреспонденция не будет доставлена ее предположительному адресату. Практика показывает, что грейлистинг является на данный момент очень эффективным средством борьбы со спамом и позволяет решить эту проблему почти на сто процентов.
Ну а теперь ложка дегтя. Основным недостатком такого подхода являются задержки в доставке почты, причем задержки эти по сути никак не регулируются на стороне принимающего сервера, где используется грейлистинг. Дело в том, что отправляющий сервер будет предпринимать повторную попытку отправки после определенного таймаута, который определяется его настройками. Например, в случае нашей почты, для попадания в белый список достаточно повторить попытку через 10 минут, но сервер может сделать это и через час. Конечно, после попадания в белый список, задержка пропадает, но при доставке первых писем она всегда будет проявляться. К сожалению с нашей стороны мы не можем повлиять на величину этой задержки, как уже было сказано выше, она полностью зависит от администрации других серверов электронной почты.
Удобно это или нет — решать вам, в любом случае вы можете включить грейлистинг отдельно для любого из ваших адресов электронной почты, расположенных на наших серверах. Стоит так же заметить, что если код вашего проекта будет отправлять почту на ваши адреса, например, какие-нибудь уведомления о регистрации посетителей или иных событиях, то эти сообщения будут доходить без задержки, так как грейлистинг касается только той почты, что приходит от внешних серверов.
По умолчанию грейлистинг выключен, включить его вы можете в подробных настройках учетной записи в разделе «ПОЧТА» вашей панели управления.

Кэширование страниц веб-интерфейса

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

Запуск memcached

Для удобства наших пользователей мы запустили memcached на стандартном порту 11211. К сожалению, формат шаред-хостинга не позволяет обеспечить раздельное использование этого сервиса, а сам memcached не обладает средствами аутентификации. Поэтому напоминаем, что все данные, помещенные нашими клиентами в memcaced, могут быть потенциально доступны и другим клиентам, чьи проекты размещены на том же сервере. Также, во избежание проблем с конфликтами имен ключей, необходимо использовать имена вида: «логин-пользователя_имя-ключа». Конечно, безопасность такого решения невелика, но при осторожном использовании можно добиваться хорошей оптимизации производительности.

Обновление интерфейса привязки и регистрации домена

Теперь каждый клиент решает сам: создавать ли DNS зону в нашем домене для привязываемого или регистрируемого домена. Такая мера значительно упрощает определение правильной конфигурации DNS для не принадлежащих доменов.

Оптимизация проверки электронных платежей

Мы внедрили новый способ проверки статуса электронных платежей. В результате время поступления информации об оплате сократилось до 2-3 минут.

Новый интерфейс заказа доменов

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

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

Хостинговые технологии не должны отставать от технологий создания web-проектов. Необходимо обеспечивать работоспособность широкого спектра фреймворков, написанных на очень разных языках: от традиционного PHP до нетривиального Lisp.

Именно этими принципами мы руководствовались, когда проектировали наш хостинг: разнородная среда, скорость и масштабируемость — именно такими были основные критерии. В результате каждый пользователь нашей системы имеет возможность создавать «проекты» — это специально подобранные наборы системных и внешних ресурсов. Именно проект является основой системы. Далее пользователь получает контроль над основными ресурсами, которые предоставлены ему в рамках проекта, а также может изменять набор этих ресурсов, например, добавить в проект еще одну базу данных.

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

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

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

Естественно, веб-интерфейс — это далеко не основной компонент системы. Он лишь принимает запрос пользователя, конвертирует его в удобный для системы формат и кладет в особую очередь задач для выполнения. Стоит заметить, что какое-либо атомарное с точки зрения интерфейса пользователя действие может на самом деле состоять из некоторого количества мелких операций. Например, пользователь, создавая новый сайт, кликает на соответствующую кнопку в своей панели управления. Та определяет, какие действия нужно выполнить: добавить DNS-имя, создать директорию сайта в домашней папке пользователя, скопировать в нее стандартные файлы-заглушки, создать конфигурационный файл веб-сервера и т.д. После того, как задачи отправлены в очередь, работа веб-интерфейса заканчивается. В дело вступает второе звено нашей системы — специальный процесс, который следит за очередью задач и их выполнением. Он постоянно получает запросы и отчеты от третьего звена — маленьких рабочих серверов, отвечающих за исполнение всех физических действий на той или иной машине. Обработчик очереди, руководствуясь системой приоритетов, а также специализацией конкретного сервера, видит запросы от этих приложений, анализирует текущую очередь задач и выбирает из них первоочередную. После этого задача получает статус «в работе», и обработчик очереди ожидает отчета об ее исполнении. Тут надо отметить, что некоторые задачи (регистрация доменного имени и др.) требуют достаточно много времени, поэтому была выбрана именно такая схема взаимодействия компонентов системы. Обработчик очереди не ждет мгновенного ответа от исполнителя, но помнит о каждой задаче и в любой момент готов принять отчет о ее исполнении.

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

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

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

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

Уважаемые клиенты!

С 17 августа на всех наших серверах изменится  глобальная настройка PHP: опция magic_quotes_gpc будет установлена в значении off, как это рекомендовано разработчиками PHP (начиная с версии 6 эта настройка не будет поддерживаться).  Если ваши проекты используют эту настройку, пожалуйста, экранируйте специальные символы вручную, как это рекомендуют разработчики.

С каждым днем отрасль IT бурно прогрессирует и новые технологии растут как грибы после дождя. С одной стороны, такие темпы радуют, но с другой — создают достаточно много сложностей. Хостерам (мы же все живые люди!) за динамикой развития технологий уследить также непросто. Отсюда и возникают проблемы при выполнении важнейшей задачи для любой хостинговой компании — как предоставить клиентам возможность использовать самые передовые IT-достижения, при этом не нарушив работу старых проектов? Ведь, с одной стороны, нельзя отставать от прогресса и конкурентов, а с другой — хочется стабильности и проверенных временем решений.

В таких ситуациях часто приходится балансировать на грани, к тому же разработчики языков программирования, фреймворков и серверов приложений иногда недостаточно заботятся об обратной совместимости своих продуктов.  Это сильно усложняет работу хостеров. Посудите сами: код, написанный под php 4, вовсе не обязательно будет стабильно работать с пятой версией этого популярного языка, с ruby 1.9 будет работать rails, но половина популярных gem-ов — не будет.

Многим IT-специалистам известен золотой принцип: «Работает — не трогай!». Он действительно помогает избежать лишних проблем, но, к сожалению, не универсален. С таким подходом легко превратиться в этакого IT-ретрограда, ведь на современном рынке хостинга можно и сейчас встретить серверы под управлением FreeBSD 4.11 (вышедшей еще в 2005 году), на которых предоставляется хостинг с php 4 и mysql четвертой ветки. В такой ситуации и сотрудники хостинговой компании, и их клиенты не могут использовать множество новых возможностей, появившихся в последующих версиях операционной системы и прочего программного обеспечения. В итоге хостер имеет стабильность ради стабильности, пожертвовав ради нее как своим удобством, так и новыми клиентами, которые хотят пользоваться всеми современными технологиями.
Постоянное обновление до последних версий в день их появления на свет тоже не будет разумным решением. Ведь помимо очевидных проблем с безопасностью и стабильностью это может привести к ситуации, когда у половины клиентов перестанут работать их проекты (просто потому, что разработчики не очень хорошо подумали о вопросах обратной совместимости, или были сделаны слишком принципиальные изменения, и добиться совместимости со старым кодом не представлялось возможным).
Таким образом, хороший хостер вынужден постоянно балансировать на грани между ретроградством и переднем краем разработок, изучать вопрос совместимости старого кода с новыми версиями языков и платформ, выделять новые сервера для запуска новых решений, а потом тестировать все это для выявления проблем с безопасностью и стабильностью работы.

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

Для создания работоспособного виртуального хостинга, который мог бы предоставлять клиентам возможность размещать Django-проекты, мы изучили три основных способа их размещения: с использованием mod_python web-сервера Apache2, FastCGI и mod_wsgi.

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

Установка и настройка:

Чем привлекает FastCGI? Он прост в настройке, принципы работы с ним хорошо известны и его внедрение не представляет никаких сложностей. Для нормальной работы django-приложения достаточно правильным образом сконфигурировать VirtualHost web-сервера Apache2 и написать простой сценарий запуска для FastCGI:

  #user defined
  ServerAdmin admin@django-test.locum.ru
  ServerName django-test.locum.ru
  #end
  DocumentRoot "/home/versus/projects/django-test.locum.ru"
  SuexecUserGroup versus customers
  AddType fastcgi-script .fcgi
  Alias /media/ /home/versus/projects/django-test.locum.ru/media/
  ScriptAlias / /home/versus/projects/django-test.locum.ru/django.fcgi/ 

  CustomLog "/var/log/apache2/django-test.locum.ru.custom.log" combined
  ErrorLog "/var/log/apache2/django-test.locum.ru.error.log"

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

#!/usr/bin/python
import os
import sys
from flup.server.fcgi import WSGIServer
from django.core.handlers.wsgi import WSGIHandler 

sys.path.insert(0, '/home/versus/projects/django-test.locum.ru/app/')
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings' 

WSGIServer(WSGIHandler()).run()

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

  #user defined
  ServerAdmin admin@django-test.locum.ru
  ServerName django-test2.locum.ru
  #end 

  DocumentRoot "/home/versus/projects/django-test2.locum.ru"
  Alias /media/ /home/versus/projects/django-test2.locum.ru/media/ 

  WSGIDaemonProcess django-test2 user=versus group=customers threads=2
  WSGIProcessGroup django-test2 

  WSGIScriptAlias / /home/versus/projects/django-test2.locum.ru/django.wsgi 

  CustomLog "/var/log/apache2/django-test.locum.ru.custom.log" combined
  ErrorLog "/var/log/apache2/django-test.locum.ru.error.log"

Каталог, содержащий статические документы, обрабатывается непосредственно web-сервером.

#!/usr/bin/python
import os
import sys 

sys.path.insert(0, '/home/versus/projects/django-test2.locum.ru/app/')
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings' 

import django.core.handlers.wsgi 

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

В этой ситуации все необходимые переменные необходимо устанавливать уже в файле сценария запуска, поэтому придется создавать отдельные файлы для каждого django-проекта. С одной стороны, это не очень хорошо — появляется дублирование и возможны проблемы с неправильной конфигурацией. С другой стороны, такой подход дает большую гибкость.
WSGI кеширует модули python, поэтому изменения в проекте вступают в силу не сразу, а только либо после перезагрузки web-сервера (что недопустимо в коммерческой эксплуатации), либо при изменении timestamp конфигурационного файла.

Тестируем производительность

Так какой же способ быстрее? Для ответа на этот вопрос мы взяли стандартное django-приложение, которое отображает всего одну страничку текста и картинку.

Методика тестирования была крайне проста: требовалось определить, какой способ затратит меньше времени на многократное повторение запросов. Для этого был написан специальный сценарий, который 1000 раз загружал главную страницу проекта.

#!/bin/bash 

for i in `seq 1 1000`; do
	wget -O /dev/null "http://django-test2.locum.ru/" > /dev/null 2> /dev/null
done

В процессе выполнения при помощи системной утилиты time замерялось время, необходимое для загрузки всех 1000 запросов. Сценарий выполнялся на локальной машине, чтобы избежать возможных накладок сети. И вот какие результаты мы получили:

Разница получилась больше, чем в 20 раз! После этого эксперимента мы однозначно выбрали mod_wsgi в качестве сервера для django-проектов. Конечно, пришлось учесть особенности такого подхода: в любой момент прямо с панели управления хостингом можно отдать команду на перезапуск сервера (touch для сценария запуска) и восстановить содержимое индивидуального сценария по умолчанию на тот случай, если пользователь случайно что-то неправильно написал.