rails db:migrate 导致 Errno::ECONNRESET，在 capistrano 部署期间由对等方重置连接答案

【问题标题】：rails db:migrate causing Errno::ECONNRESET, Connection reset by peer during capistrano deploymentrails db:migrate 导致 Errno::ECONNRESET，在 capistrano 部署期间由对等方重置连接
【发布时间】：2015-02-10 17:44:45
【问题描述】：

我们遇到 ssh 级别连接错误的问题，似乎是超时，在长时间部署期间运行我们的 capistrano 部署和大型 rails db 迁移任务。我们唯一的帮助是将这些移动到我们在部署后手动运行的 rake 任务中，这并不理想。在 ruby/rails 堆栈内部或外部有什么想法可以确保 ssh 连接保持活跃吗？

Errno::ECONNRESET, Connection reset by peer

完整的跟踪：

** [deploy:update_code] exception while rolling back: Errno::ECONNRESET, Connection reset by peer - recvfrom(2)
/Users/Ben/.rvm/gems/ruby-1.9.3-p550@/gems/net-ssh-2.9.2/lib/net/ssh/buffered_io.rb:65:in `recv': Connection reset by peer - recvfrom(2) (Errno::ECONNRESET)
  from /Users/Ben/.rvm/gems/ruby-1.9.3-p550@/gems/net-ssh-2.9.2/lib/net/ssh/buffered_io.rb:65:in `fill'
  from /Users/Ben/.rvm/gems/ruby-1.9.3-p550@/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:237:in `block in postprocess'
  from /Users/Ben/.rvm/gems/ruby-1.9.3-p550@/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:233:in `each'
  from /Users/Ben/.rvm/gems/ruby-1.9.3-p550@/gems/net-ssh-2.9.2/lib/net/ssh/connection/session.rb:233:in `postprocess'
  from /Users/Ben/.rvm/gems/ruby-1.9.3-p550@/gems/capistrano-2.15.5/lib/capistrano/processable.rb:33:in `block in process_iteration'
  from /Users/Ben/.rvm/gems/ruby-1.9.3-p550@/gems/capistrano-2.15.5/lib/capistrano/processable.rb:45:in `block in ensure_each_session'
  from /Users/Ben/.rvm/gems/ruby-1.9.3-p550@/gems/capistrano-2.15.5/lib/capistrano/processable.rb:43:in `each'
  from /Users/Ben/.rvm/gems/ruby-1.9.3-p550@/gems/capistrano-2.15.5/lib/capistrano/processable.rb:43:in `ensure_each_session'
  from /Users/Ben/.rvm/gems/ruby-1.9.3-p550@/gems/capistrano-2.15.5/lib/capistrano/processable.rb:31:in `process_iteration'
  from /Users/Ben/.rvm/gems/ruby-1.9.3-p550@/gems/capistrano-2.15.5/lib/capistrano/command.rb:171:in `block (2 levels) in process!'
  from /Users/Ben/.rvm/gems/ruby-1.9.3-p550@/gems/capistrano-2.15.5/lib/capistrano/command.rb:170:in `loop'
  from /Users/Ben/.rvm/gems/ruby-1.9.3-p550@/gems/capistrano-2.15.5/lib/capistrano/command.rb:170:in `block in process!'
  from /Users/Ben/.rvm/rubies/ruby-1.9.3-p550/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
  from /Users/Ben/.rvm/gems/ruby-1.9.3-p550@/gems/capistrano-2.15.5/lib/capistrano/command.rb:169:in `process!'

【问题讨论】：

注意两件事，我作为我的 Mac OSX 用户尝试将 .ssh/config 文件放入：Host * ServerAliveInterval 120 并且我也在使用 net-ssh (>= 2.9.2) ruby我认为在部署期间使用的 gem

标签： ruby-on-rails ruby ssh capistrano

【解决方案1】：

“Connection reset by peer”通常意味着连接的远程端的软件已经崩溃，或者客户端和服务器之间的一些状态防火墙正在干扰 TCP 连接。

在这种情况下，远程软件应该是 SSH 服务器。你说这发生在长时间的部署中。鉴于这些情况，我怀疑您在客户端和服务器之间有一个 NAT 设备或其他状态防火墙，并且在一段时间后它会断开 TCP 连接。

您可以尝试将您的客户端设置为发送保活数据包。我不是 Ruby 开发人员，但 this page 描述了一个 keepalive 选项。除此之外，您应该与您的网络工程师交谈，看看是否可以对干扰连接的设备采取任何措施。

【讨论】：

【解决方案2】：

希望这对其他人有所帮助，我想我找到了自己问题的答案。

在我们的情况下，我们的 web 和 worker box 都通过 capistrano 进行了新的部署。 Web 盒子正在执行更昂贵的长期运行任务，例如资产编译和发布到 AWS S3 存储桶。当这种情况发生时，我们的工人盒子变得空闲并因没有活动而超时。 capistrano 将此检测为整体故障并回滚发布。

这里有几个选项，比如提前编译 Rails 资产管道资源，甚至先发布到 aws，然后开始其他部署步骤。

我们选择只让我们的服务器的做客户端 ping 在 ssh 级别保持活动

sudo vim /etc/ssh/sshd_config 将这两行添加到文件中： ClientAliveInterval 60 ClientAliveCountMax 200

请注意，有些网站只提到第一个，我发现它效果不佳，除非也放第二个，因为我怀疑默认的最大计数很低。

确保在每台部署目标机器上更改后重新启动 ssh 服务。

【讨论】：

【解决方案3】：

只需在您的项目上运行 rake db:migrate，然后再将其部署到服务器上，然后运行 rake production deploy。

【讨论】：