从登台服务器连接到GitoLite时出错-ECONNREFUSED部署错误 [英] Error Connecting to GitoLite from Staging Server - ECONNREFUSED Deploy Error

查看:86
本文介绍了从登台服务器连接到GitoLite时出错-ECONNREFUSED部署错误的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

尝试将以前可以正常运行的项目部署到开发服务器时遇到了一些麻烦。我没有设置系统,但是我确实拥有我需要的所有凭据。

I'm having a little trouble trying to deploy a previously working project to the development server. I did not set-up the system however I do have all the credentials I need (I think).

尝试进行cap分段部署之后,到目前为止,它会产生一个错误。请参见下面的内容:

After trying cap staging deploy I get so far and then it produces an error. Please see below:

triggering load callbacks
  * 2012-11-20 14:52:20 executing `staging'
    triggering start callbacks for `deploy'
  * 2012-11-20 14:52:20 executing `multistage:ensure'
Identity added: /Users/XXX/.ssh/id_rsa (/Users/XXX/.ssh/id_rsa)
  * 2012-11-20 14:52:20 executing `deploy'
  * 2012-11-20 14:52:20 executing `deploy:update'
 ** transaction: start
  * 2012-11-20 14:52:20 executing `deploy:update_code'
    executing locally: "git ls-remote ssh://gitolite@repo1:2011/proto_projectname_rails HEAD"
    command finished in 2864ms
  * executing "git clone -q ssh://gitolite@repo1:2011/proto_projectname_rails /var/www/projectname/releases/20121120145223 && cd /var/www/projectname/releases/20121120145223 && git checkout -q -b deploy 0598169ed07015279bd78efa91f25ed3e5edcad8 && (echo 0598169ed07015279bd78efa91f25ed3e5edcad8 > /var/www/projectname/releases/20121120145223/REVISION)"
    servers: ["repo2"]
*** [deploy:update_code] rolling back
  * executing "rm -rf /var/www/projectname/releases/20121120145223; true"
    servers: ["repo2"]
 ** [deploy:update_code] exception while rolling back: Capistrano::ConnectionError, connection failed for: repo2 (Errno::ECONNREFUSED: Connection refused - connect(2))
connection failed for: repo2 (Errno::ECONNREFUSED: Connection refused - connect(2))

deploy.rb

deploy.rb

set :stages, %w(staging production)
set :default_stage, "production"
require 'capistrano/ext/multistage'

set :application, "projectname"

set :scm, :git
set :repository,  "ssh://gitolite@repo1:2011/proto_projectname_rails"

我真的很困惑为什么以前的版本不再起作用。

I am honestly confused as to why a previously working version no longer functions.

任何帮助,建议或指导或此事都非常受欢迎。

Any help, advice or guidance or this matter is more than welcome.

谢谢

请注意,它一直是2011年的非标准端口,位于我的.ssh / config

As a side note, yes it has always been the non-standard port of 2011 and is in my .ssh/config

编辑:

此过程涉及2台服务器。

There are 2 servers involved in this process.

在本地和第二台服务器上运行以下命令后,我会得到响应。

After running the following locally and on 2nd server I do get a response.

git ls-remote ssh://gitolite@repo1:2011/proto_projectname_rails

返回;

0598169ed07015279bd78efa91f25ed3e5edcad8    HEAD
0598169ed07015279bd78efa91f25ed3e5edcad8    refs/heads/master

编辑:在2台服务器上运行。 Repo1和Repo2

Runs on 2 servers. Repo1 and Repo2

cap deploy:check

返回

   triggering load callbacks
 * 2012-11-27 21:02:36 executing `production'
 triggering start callbacks for `deploy:check'
 * 2012-11-27 21:02:36 executing `multistage:ensure'
  Identity added: /Users/x/.ssh/id_rsa (/Users/x/.ssh/id_rsa)
 * 2012-11-27 21:02:36 executing `deploy:check'
 * executing "test -d /var/www/projectname/releases"
   servers: ["repo2"]
   connection failed for: repo2 (Errno::ECONNREFUSED: Connection refused - connect(2))

已解决

事实证明这是由于第二服务器端口号而被拒绝。添加

It turns out that it was being rejected due to the 2nd servers port number. Adding

set :port, 1893

任何可以解释这一点的人都可以得到赏金。

The bounty is still open to anyone that can explain this.

为什么总是可以通过SSH进入服务器,而无需随时编辑我的ssh / config,并且其他机器也可以部署,并且具有完全相同的部署和登台文件,但是在明确添加端口号之前,我无法?

Why could always SSH into the server, without editing my ssh/config at anytime, and were other machines able to deploy, with the exact same deploy and staging files, but I could not until I explicitly added the port number?

推荐答案

有关此问题的最终答案,请参见下面的更新2

好,因此要测试的第一件事是,是否可以在本地计算机上运行 git ls-remote ssh:// gitolite @ XXX:2011 -应该从仓库中返回引用列表。如果这不起作用,则可能会给您一个类似的错误(连接被拒绝或类似的错误),然后您可能需要弄清楚为什么托管git repo的人来自何处。

OK, so first thing to test is whether, from your local computer, you can run git ls-remote ssh://gitolite@XXX:2011 -- it should return the list of references from the repo. If this doesn't work, it should probably give you a similar error (connection refused or similar), and then you probably need to figure out why from whoever is hosting the git repo.

如果它在本地运行,则可能需要设置一些或所有这些选项,具体取决于您在部署时想要访问git的方式。我认为除非您的部署服务器/用户可以直接登录到存储库,否则需要forward_agent选项。

If it does work locally, then you might need to set some or all of these options, depending on how you want to access git while you're deploying. I think the forward_agent option is needed unless your deploy server/user can log into the repository directly.

set :deploy_via, :remote_cache
default_run_options[:pty] = true
ssh_options[:forward_agent] = true

并且我在另一个堆栈溢出答案

关于capistrano的关键要记住的是,大多数命令实际上只是标准的shell命令,但是使用ssh传递到远程服务器,如 ssh user@server.example.com< command> 一样,因此要测试是否不能

The key thing to remember about capistrano is that most commands are really just standard shell commands, but are passed to the remote server using ssh, as in ssh user@server.example.com <command>, so that would be another thing to test if you can't get this working.

根据添加到原始问题的信息进行更新:

Update based on information added to original question:

当您建立与使用URL的服务器,请指定协议,主机地址, nd端口号。许多协议都暗含了端口号。例如。 ssh://1.2.3.4 指定协议SSH,其标准端口为22,因此与 ssh://1.2.3.4相同: 22 。我猜您的git提供程序将不同的端口分配给不同的存储库(也许在同一IP地址上)以路由请求,因此对于每个存储库,您可能具有不同的端口号。因为它不是所使用的ssh协议的默认端口,所以必须将其指定为URL的一部分(并且似乎可以在Capistrano中使用 set:port 覆盖此端口。 )。

When you make a TCP connection to a server using a URL, you specify protocol, host address, and port number. Port number is implied for many protocols. E.g. ssh://1.2.3.4 specifies the protocol SSH whose standard port is 22, thus would be the same as ssh://1.2.3.4:22. I am guessing your git provider assigns different ports to different repositories (perhaps on the same IP address) in order to route requests, so for each of your repos you may have a different port number. Because it is not the default port for the ssh protocol being used, it must be specified as part of the URL (and it seems you can override this in capistrano using set :port).

对我来说,您拥有多个git存储库( repo1 repo2 ),所以也许我需要了解在什么情况下会发生这种情况,但是无论如何,该错误的原因是您的服务器无法与该服务器建立TCP连接git host给出了提供的URL。

It does not make sense to me that you would have multiple git repositories (repo1 and repo2) for the same project so perhaps I need to understand in what cases this happens, but in any case, the reason for the error was that your server could not make an TCP connection to the git host given the supplied URL.

更新2
确定,所以事实证明 repo1 是一个git仓库。它托管在非标准的SSH端口( 2011 )上,因此每当引用git服务器的ssh URL时,都需要将其嵌入URL中。

Update 2 OK, so it turns out that repo1 is a git repository. It is hosted at a non-standard SSH port (2011) so this needs to embedded in the URL whenever referring to the ssh URL of the git server.

但是, repo2 实际上只是运行Rails应用程序的应用程序服务器(由与git repo相同的源托管),并且它在非标准ssh端口( 1893 )上也可用。为了ssh进入该服务器,您将需要使用 ssh -p 1893 ... 指定端口-由于这是capistrano的连接方式,因此也是如此。这就是为什么需要添加 set:port,1893 的原因。

However, repo2 is actually just the application server that runs the Rails app (hosted by the same source as the git repo), and it is also available on a non-standard ssh port (1893). In order to ssh into this server, you will need to specify the port using ssh -p 1893 ... -- and since this is how capistrano connects, so will it. This is why adding the set :port, 1893 is required.

这篇关于从登台服务器连接到GitoLite时出错-ECONNREFUSED部署错误的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆