【问题标题】:Running thin restart after rails code deploy, constant 502 bad gateway errors在 Rails 代码部署后运行精简重启,恒定 502 bad gateway 错误
【发布时间】:2012-11-11 07:42:55
【问题描述】:

问题:thin 重新启动时发出的所有请求都会导致 502 Bad Gateway Errors。

当我将代码更改部署到我的服务器时,我必须重新启动 Thin 以使新更改生效。我的瘦配置 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,但之前的瘦进程仍在该端口上运行?为什么会这样?

【问题讨论】:

  • 你是不是在thin前面使用web服务器(比如nginx)?
  • 是的,我正在使用 nginx。我认为正在发生的事情是 nginx 无法与瘦对话,因为在瘦重启期间发生了一些奇怪的事情。

标签: ruby-on-rails ruby-on-rails-3 deployment thin


【解决方案1】:

当 Thin 停止时,它会在与 Nginx 通信时删除套接字文件,然后在成功启动时重新创建它。即使 Thin 停止,NGinx 仍在侦听 Web 请求。如果此时向 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,因为它内置了滚动重启。它被 RailsCast 覆盖 - http://railscasts.com/episodes/373-zero-downtime-deployment

【讨论】:

  • 是的,删除oneoneby还是有问题。我现在没有使用 Capistrano,为了简单起见,我希望不必在我的设置中添加任何其他宝石。独角兽听起来很有趣——它会是瘦身的替代品还是瘦身的补充?
  • 它是 Thin 的绝佳替代品。不久前我离开 Thin 去了 Unicorn。最大的特点是你可以让 Unicorn 产生多个进程,它会管理/看家。在 Thin 中,您必须通过 God、Monit 等自己管理每个 Thin 进程。NGinx + Unicorn 是这些天的默认选择。
  • 为了调试起见,只需在停止和启动之间放置 5 秒的睡眠,然后查看。我猜它试图在完全停止之前开始。我以前见过这个,我记得通过另一种方式启动/停止来修复它。你能把这个细节添加到你的问题中吗?
  • 酷,如果我无法解决这个问题,至少我有一个不错的选择。编辑问题以添加您请求的信息。我认为使用 'restart' 而不是 'stop' 和 'start' 将是确保 Thin 实例始终可用于服务请求的唯一方法。
猜你喜欢
  • 2015-07-25
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-04-23
  • 2021-06-22
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多