2

所以我有几台机器正在生产中，它们在 Rack 上运行 Sinatra 应用程序。通常一切都是笨拙的，直到 Puppet（我们用来将更改同步到我们的服务器）注意到项目的 Gemfile.lock 已更改，因此需要发出bundle install --binstubs --deployment命令以便我们获得新的 gem。发生这种情况时，任何 http 请求在调用 Bundler 以要求我们的 gem 时都会导致 500 错误，因为尚未安装新的 gem。

我们通常至少有一个 Rack 进程挂起，因为另一个进程会定期发出 http 请求以确保服务器处于活动状态，但是当这种情况发生时，没有 Rack 进程处于活动状态。如果问题出在新实例上，该指令似乎PassengerMinInstances可能会有所帮助，但我们还有一个进程会定期获取页面以测试服务器是否仍在运行，因此至少应该有一个 Rack 进程处于活动状态来处理请求.

我可能应该注意到 puppettouch直到bundle install完成之后才真正重新启动 Rack（通过重新启动.txt 文件），所以我们的 Rack 进程在这个时候消失是没有任何意义的。有没有人遇到过这样的事情？是否有一些 Rack 选项可以在我忽略的每个请求上不重新加载整个环境？

4

2 回答 2

1

我知道这并不能直接回答您的问题，但是我过去为解决这种情况所做的是将应用程序部署到版本编号的目录中，并带有指向它们的软链接和（Nginx）代理服务器将请求路由到链接。在部署结束时，部署脚本将链接指向新应用程序。

它对我来说似乎工作得很好，如果真的出了问题，你总是可以手动将链接重新指向以前的版本。

于 2012-02-07T03:02:43.693 回答
0

为了后代，我会回答这个问题。作为部署的一部分，所有文件都使用 chown -R 来处理，它会更新文件的 ctime（但不是 mtime）。乘客中还有一个有趣的错误/功能，只要 /tmp/restart.txt 文件的 mtime 或 ctime 更改，他们就会重新启动服务器。

解决方案：在部署期间停止更改目录。

于 2012-02-16T21:06:42.483 回答