Запуск тонкого перезапуска после развертывания кода рельсов, постоянные ошибки 502 bad gateway

Проблема: все запросы, сделанные во время перезапуска Thin, приводят к ошибке 502 Bad Gateway Errors.

Когда я развертываю изменения кода на своем сервере, мне приходится перезапускать тонкий сервер, чтобы новые изменения вступили в силу. Моя тонкая конфигурация yml выглядит так:

chdir: /var/www/appname
servers: 6
environment: production
onebyone: true
wait: 30
no-epoll: true
address: 0.0.0.0
port: 3000
timeout: 30
log: log/thin.log
pid: tmp/pids/thin.pid
max_conns: 1024
max_persistent_conns: 512
require: []
daemonize: true

Насколько я понимаю, свойство «onebyone» гарантирует, что по крайней мере 1 сервер всегда доступен для ответа на запросы. Однако происходит то, что любые запросы, сделанные до завершения перезапуска всех серверов, приведут к ошибкам 502 Bad Gateway или 504 Gateway Time-out. Как я могу гарантировать, что мои запросы всегда обрабатываются должным образом после того, как я отправлю новый код в производство?

ОБНОВЛЕНИЕ

тонкие журналы показывают эту ошибку:

/usr/local/lib/ruby/gems/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:572:in `start_tcp_server': no acceptor (RuntimeError)
    from /usr/local/lib/ruby/gems/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:572:in `start_server'
    from /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/backends/tcp_server.rb:16:in `connect'
    from /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/backends/base.rb:53:in `block in start'
    from /usr/local/lib/ruby/gems/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `call'
    from /usr/local/lib/ruby/gems/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run_machine'
    from /usr/local/lib/ruby/gems/1.9.1/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `run'
    from /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/backends/base.rb:61:in `start'
    from /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/server.rb:159:in `start'
    from /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/controllers/controller.rb:86:in `start'
    from /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/runner.rb:185:in `run_command'
    from /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.3.1/lib/thin/runner.rb:151:in `run!'
    from /usr/local/lib/ruby/gems/1.9.1/gems/thin-1.3.1/bin/thin:6:in `<top (required)>'
    from /usr/local/bin/thin:19:in `load'
    from /usr/local/bin/thin:19:in `<main>'

Я перезапускаю с sudo thin -C /etc/thin/appname.yaml restart

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


ruby-on-rails deployment ruby-on-rails-3 thin
person D-Nice    schedule 11.11.2012    source источник
comment
Используете ли вы веб-сервер перед тонким (например, nginx)?   -  person Andrew Marshall    schedule 11.11.2012
comment
Да, я использую nginx. Я думаю, что происходит то, что nginx не может общаться с тонким, потому что во время перезапуска тонкого происходит что-то странное.   -  person D-Nice    schedule 11.11.2012

Ответы (1)


arrow_upward
1
arrow_downward

Когда Thin останавливается, он удаляет файл сокета, пока связывается с Nginx, а затем воссоздает его при успешном запуске. Даже когда Thin остановлен, NGinx продолжает прослушивать веб-запросы. Если в этот момент будет сделан запрос к Nginx, это приведет к ошибке, как вы упомянули. Это просто означает, что Thin не смог нормально запуститься или привязаться к сокету в вашем случае. Это может означать, что вы пытаетесь остановиться и начать слишком быстро.

Такая задача ограничения должна работать нормально.

task :restart do
  sudo "bundle exec thin restart -C thin.yml"
end

Это все еще проблема, когда onebyone удален?

Я также нашел эту статью очень полезной для реализации непрерывного перезапуска с помощью Thin и Capistrano — http://pointatstar.wordpress.com/2011/01/17/rolling-restart-for-thin-cluster-via-capistrano/

Лично я использую Unicorn, так как он имеет встроенный последовательный перезапуск. ">http://railscasts.com/episodes/373-zero-downtime-deployment

person Akshay Rawat    schedule 11.11.2012
comment
Да, это еще проблема с одним удаленным. Сейчас я не использую Capistrano и надеялся, что мне не придется добавлять какие-либо дополнительные драгоценные камни в мою настройку ради простоты. «Единорог» звучит интересно — будет ли он заменой «худого» или дополнением к «тонкому»? - person D-Nice; 11.11.2012
comment
Это отличная замена Thin. Некоторое время назад я ушел из Thin в пользу Unicorn. Самая большая особенность заключается в том, что вы можете попросить Unicorn создать несколько процессов, и он будет управлять ими. В Thin вы должны самостоятельно управлять каждым тонким процессом через God, Monit и т. д. В наши дни NGinx + Unicorn является выбором по умолчанию. - person Akshay Rawat; 11.11.2012
comment
Для отладки просто установите 5-секундный сон между остановкой и запуском и посмотрите. Я предполагаю, что он пытается запуститься до того, как полностью остановится. Я видел это раньше, и я помню, как исправлял это, запуская/останавливая другим способом. Можете ли вы добавить эту деталь к вашему вопросу. - person Akshay Rawat; 11.11.2012
comment
Круто, по крайней мере, у меня есть хорошая альтернатива, если я не могу это исправить. Отредактированный вопрос, чтобы добавить запрошенную вами информацию. Я думал, что использование «перезапуска» вместо «стоп» и «старт» будет единственным способом гарантировать, что экземпляр thin всегда будет доступен для обслуживания запросов. - person D-Nice; 12.11.2012