Полезные задачи для Capistrano (управляем nginx сервером)
-
20 октября 2008 14:03
-
Комментарии

Конечно каждый из вас слышал о потрясающем веб-сервере под названием nginx, который создал наш Российский разработчик Игорь Сысоев. К достоинствам nginx-сервера можно отнести: высокую скорость работы, надёжность, удобство настройки и огромное количество разнообразных плагинов.
В Capistrano есть стандартные задачи которые позволяют управлять кластером из Mongrel-серверов на которых работает ваше Ruby on Rails приложение, а вот для управления nginx-сервером задач пока нет, поэтому я попробую восполнить этот пробел.
Для этого я написал следующие задачи:
namespace :nginx do
set :nginx_cfg, "/usr/local/etc/nginx/nginx.conf"
set :nginx_pid, "/usr/local/etc/nginx/logs/nginx.pid"
desc "Start nginx-server"
task :start do
sudo "nginx -c #{nginx_cfg}"
end
desc "Stop nginx-server"
task :stop do
pid = get_nginx_pid
sudo "kill -s QUIT #{pid}"
end
desc "Re-start nginx-server"
task :restart do
stop
start
end
def get_nginx_pid
capture "if [ -f #{nginx_pid} ] ; then cat #{nginx_pid}; fi"
end
end
Как видите ничего сложного в них нет. Чтобы запустить nginx нужно всего лишь вызвать его с параметром -c в котором указать путь к конфигурационному файлу. А чтобы остановить нужно получить pid master-процесса (один из способов это достать его из pid-файла который создаёт nginx при запуске), а затем передать этот pid команде kill которая пошлёт сигнал QUIT nginx-серверу, а он в свою очередь плавно завершит все рабочие процессы и закроется.
Чтобы эти задачи заработали надо не забыть указать правильные пути к конфигурационному файлу и к pid-файлу.
Небольшое замечание по поводу команды capture из Capistrano. Она очень похожа на команду stream которую я использовал в предыдущей статье, за исключением того что она не выводит на локальный терминал содержимое stdout-потока захваченного на сервере, а просто возвращает его в виде строки.
в формате RSS. Присоединяйся!
Комментарии
Добавить новый комментарий
Вы можете использовать следующие BBCode теги в комментариях:
| BBCode тег | Результат |
|---|---|
| [b]Жирный текст[/b] | Жирный текст |
| [i]Курсив[/i] | Курсив |
| [u]Подчёркнутый текст[/u] | Подчёркнутый текст |
| [url]http://example.com[/url] | http://example.com |
| [url=http://example.com]Example[/url] | Example |
|
[code]for message in @messages puts message.name end[/code] |
|
|
[quote] IE6 must die! [/quote] |
IE6 must die! |


Скажите: вы руками все запускаете ? А как же /etc/init.d/ скрипты ?
Не проще ли (и правильнее) звать их ?
Второе, настройте себе уже какой-нть монитор процессов (например, monit). Это и надежнее и управление разными службами будет централизованное. Например, если у Вас помимо кластера монгрелей и nginx'а крутятся какие другие сервисы (BackgrounDRb, Ferret, SOLR и т.п.), перезапуск их всех сводится к одной команде monit'у: "monit -g MyApplication1 restart all".
И Вы будете писать настройки для monit'а, а не таски для Capistrano.
Ну естественно у меня настроен автозапуск nginx и кластера из mongrel серверов, но т.к. работа над проектом кипит, то приходиться выполнять довольно часто такие примитивные вещи например как перезагрузка nginx сервера (или что ещё чаще случается так это подгрузка изменённых конфигурационных файлов для него). И как следствие не хочется каждый раз лезть по ssh на сервер и набивать комманды там.
C monit я ещё не работал, но спасибо за совет :) А Capistrano меня пока вполне устраивает т.к. дешево, сердито и вполне удобно в использовании :)
Когда надо часто что-то делать на сервере, я просто держу открытую ssh консоль туда.
Рад за вас :) Я тоже так поступаю время от времени :) Но у этого подхода есть одна неприятная особенность: если требуется выполнить группу связанных друг с другом команд (а если ещё надо использовать аргументы которые могут меняться, например pid какого-либо процесса), то на это может уйти намного больше времени чем просто выполнение одной команды.
Соответственно я вижу 2 варианта решения этой проблемы:
1) Написать sh-скрипт
2) Написать задачу на Capistrano
Мне больше нравиться второй способ т.к. помимо того что я решаю возникшую передо мною проблему, я ещё и осваиваю этот замечательный инструмент. Так же я считаю что в моей карьере RoR разработчика знания и умение работать с Capistrano будут более востребованы чем умение работать удалённо через консоль и способность писать sh-скрипты (конечно, тем не менее нужно уметь обращаться и с этими вещами на должном уровне)