Capistrano неправильно перезапускает кластеры Mongrel

StackOverflow https://stackoverflow.com/questions/155234

Вопрос

У меня есть кластер из трех mongrels, работающих под управлением nginx, и я развертываю приложение с помощью Capistrano 2.4.3.Когда я "ограничиваю развертывание" при наличии запущенной системы, поведение:

  1. Приложение развернуто.Код успешно обновлен.

  2. В выходных данных cap deploy есть следующее:

    • выполнение пароля sudo "sudo -p":' кластер mongrel_rails::перезапуск -C /var/www/rails/myapp/current/config/mongrel_cluster.yml"
    • Серверы:["myip"]
    • [myip] выполнение команды
    • ** [выход ::myip] остановка порта 9096
    • ** [выход ::myip] остановка порта 9097
    • ** [выход ::myip] остановка порта 9098
    • ** [выход ::myip] уже запущен порт 9096
    • ** [выход ::myip] уже запущен порт 9097
    • ** [выход ::myip] уже запущен порт 9098
  3. Я немедленно проверяю на сервере и обнаруживаю, что Mongrel все еще запущен, и файлы PID все еще присутствуют для предыдущих трех экземпляров.
  4. Некоторое время спустя (менее одной минуты) я обнаружил, что Mongrel больше не запущен, файлы PID исчезли, и перезапустить его не удалось.
  5. Если я запускаю mongrel на сервере вручную, приложение запускается просто отлично.

Похоже, что 'mongrel_rails cluster:: restart' должным образом не ожидает полной остановки перед попыткой перезапуска кластера.Как мне диагностировать и устранить эту проблему?

Редактировать:Вот вам и ответ:

mongrel_cluster в задаче "перезапуск" просто делает это: 

 def run
   stop
   start
 end

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

Это было полезно?

Решение

Вы можете явно указать рецептам mongrel_cluster удалить файлы pid перед запуском, добавив следующее в свои рецепты capistrano:

# helps keep mongrel pid files clean
set :mongrel_clean, true

Это заставляет его передавать параметр --clean в mongrel_cluster_ctl.

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

пользователи mongrel обсуждают перезапуск

Ниже приведена моя задача развертывания: перезапустить.Я признаю, что это немного халтурно.

namespace :deploy do
  desc "Restart the Mongrel processes on the app server."
  task :restart, :roles => :app do
    mongrel.cluster.stop
    sleep 2.5
    mongrel.cluster.start
  end
end

Другие советы

Во-первых, сузьте область того, что вы тестируете, только вызвав cap deploy:restart.Возможно, вы захотите передать --debug возможность запрашивать запрос перед удаленным выполнением или --dry-run опция просто для того, чтобы посмотреть, что происходит, когда вы настраиваете свои настройки.

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

  • тот самый :runner переменной явно задано значение nil -- Была ли для этого какая-то конкретная причина?
  • Капистрано 2.4 введено новое поведение для :admin_runner переменная.Возможно, это связано с вашей проблемой, если вы не видите весь рецепт целиком?

    :бегун против:admin_runner :администратор (из версия capistrano 2.4) Некоторые разработчики каппинга отметили, что запуск deploy:setup и deploy: cleanup от имени пользователя runner привел к искажению их тщательно разработанных разрешений.Я согласился, что это проблема.В этом выпуске deploy:start, deploy: stop и deploy: restart все продолжают использовать пользователя runner при выполнении sudoing, но deploy:setup и deploy: cleanup будут использовать пользователя admin_runner.Переменная :admin_runner по умолчанию не установлена, что означает, что эти задачи будут выполняться sudo от имени root, но если вы хотите, чтобы они выполнялись от имени :runner, просто выполните “установить :admin_runner, runner”.

Моя рекомендация относительно того, что делать дальше.Вручную остановите полукровок и очистите PIDS.Запустите mongrels вручную.Далее продолжайте выполнять cap deploy:restart во время отладки проблемы.Повторяйте по мере необходимости.

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

sleep 2.5 не является хорошим решением, если для остановки всех запущенных mongrels требуется больше 2,5 секунд.

По-видимому, существует необходимость в:

stop && start

против.

stop; start

(вот как работает bash, && ожидает завершения первой команды без ошибки, в то время как ";" просто запускает следующую команду).

Интересно, существует ли:

wait cluster_stop
then cluster_start

Я ненавижу быть таким примитивным, но похоже, что файлы pid все еще зависают, когда он пытается запуститься.Убедитесь, что дворняга остановлена вручную.Очистите pid-файлы вручную.Затем сделайте развертывание колпачка.

Хорошая дискуссия: http://www.ruby-forum.com/topic/139734#745030

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top