Ошибка подключения к GitoLite с промежуточного сервера - ECONNREFUSED Ошибка развертывания

Question

У меня возникли небольшие проблемы при попытке развернуть ранее работающий проект на сервере разработки. Я не настроил систему, но у меня есть все необходимые учетные данные (я думаю).

После попытки развертывания кэпа я так далеко захожу, а потом выдает ошибку. Пожалуйста, смотрите ниже:

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

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"

Я честно запутался, почему ранее работающая версия больше не работает.

Любая помощь, совет или руководство или этот вопрос более чем приветствуются.

Спасибо

Как примечание: да, это всегда был нестандартный порт 2011 года, и он находится в моем.ssh/config

Редактировать:

В этом процессе участвуют 2 сервера.

После запуска следующего локально и на 2-м сервере я получаю ответ.

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

Это возвращается;

0598169ed07015279bd78efa91f25ed3e5edcad8    HEAD
0598169ed07015279bd78efa91f25ed3e5edcad8    refs/heads/master

Изменить: работает на 2 серверах. Репо1 и Репо2

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))

решаемая

Оказывается, он был отклонен из-за номера порта 2-го сервера. Добавление

set :port, 1893

Баунти по-прежнему открыт для всех, кто может это объяснить.

Почему всегда можно подключиться по SSH к серверу, не редактируя мой ssh ​​/ config в любое время, и другие машины могут быть развернуты с точно такими же файлами развертывания и размещения, но я не смог, пока я явно не добавил номер порта?

Answer 1

Смотрите обновление 2 ниже для окончательного ответа на этот вопрос

Итак, первое, что нужно проверить, можно ли с локального компьютера запустить git ls-remote ssh://gitolite@XXX:2011 - он должен вернуть список ссылок из репо. Если это не сработает, вероятно, вы получите похожую ошибку (отказ в соединении или подобное), и тогда вам, вероятно, нужно выяснить, почему тот, кто размещает git-репо.

Если он работает локально, вам может потребоваться установить некоторые или все эти параметры, в зависимости от того, как вы хотите получить доступ к git во время развертывания. Я думаю, что опция forward_agent необходима, если ваш сервер / пользователь развертывания не может войти в репозиторий напрямую.

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

и я описал, как установить это в этом другом ответе переполнения стека.

Главное, что нужно помнить о capistrano, это то, что большинство команд на самом деле являются просто стандартными командами оболочки, но передаются на удаленный сервер с помощью ssh, как в ssh [e-mail] <command>, так что это будет еще одна вещь, чтобы проверить, если вы не можете заставить это работать.

Обновление на основе информации, добавленной к исходному вопросу:

Когда вы устанавливаете TCP-соединение с сервером по URL-адресу, вы указываете протокол, адрес хоста и номер порта. Номер порта подразумевается для многих протоколов. Например ssh://1.2.3.4 указывает протокол SSH, чей стандартный порт 22, таким образом, будет таким же, как ssh://1.2.3.4:22, Я предполагаю, что ваш провайдер git назначает разные порты разным репозиториям (возможно, на один и тот же IP-адрес) для маршрутизации запросов, поэтому для каждого из ваших репозиториев у вас может быть другой номер порта. Поскольку это не порт по умолчанию для используемого протокола ssh, он должен быть указан как часть URL (и кажется, что вы можете переопределить это в capistrano, используя set :port).

Для меня не имеет смысла, что у вас будет несколько git-репозиториев (repo1 а также repo2) для того же проекта, поэтому, возможно, мне нужно понять, в каких случаях это происходит, но в любом случае причина ошибки заключалась в том, что ваш сервер не мог установить TCP-соединение с хостом git с учетом предоставленного URL-адреса.

Обновление 2 ОК, так что получается, что repo1 это git-репозиторий Он размещен на нестандартном порту SSH (2011) так что это должно быть встроено в URL всякий раз, когда ссылается на ssh URL сервера git.

Тем не мение, repo2 на самом деле это просто сервер приложений, на котором запущено приложение Rails (размещено в том же источнике, что и git-репозиторий), и он также доступен через нестандартный порт ssh (1893). Для того, чтобы ssh на этот сервер, вам нужно будет указать порт, используя ssh -p 1893 ... - и так как это соединяет Капистрано, так и будет. Вот почему добавление set :port, 1893 необходимо.