В этой статье я расскажу как проще и удобнее всего разворачивать приложения на 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 желает успеха всем нашим пользователям в разработке и размещении проектов.

У веб-разработчиков часто возникает вопрос: какой же метод запуска 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 приложений без явной необходимости. Ведь чем проще система, тем удобнее ее поддерживать, а значит и работа будет стабильнее.

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