berks install - Artifactory - Получение индекса поваренной книги от ARTIFACTORY_URL / api / chef / some-chef-repo HANGS - PullRequest
0 голосов
/ 27 января 2020

Версия Artifactory : Professional Artifactory 6.11.3 rev 61103900

Linux: Red Hat Enterprise Linux Серверная версия 6.10 (Santia go)

berks install --debug просто зависает в следующей строке (и не плюет ошибки / предупреждения / et c):

Fetching cookbook index from http://my-company-artifactory-server-development:8181/artifactory/api/chef/chef-develop-virtual...

Полный журнал, показывающий некоторые предыдущие строки журнала:

23:17:05 I, [2020-01-24T23:17:05.732159 #7235]  INFO -- : Checking if lockfile is trusted
23:17:05 D, [2020-01-24T23:17:05.732185 #7235] DEBUG -- : Checking my_wrapper_cookbook (>= 0.0.0)
23:17:05 D, [2020-01-24T23:17:05.732199 #7235] DEBUG -- :   Not in lockfile - cannot be trusted!
23:17:05 I, [2020-01-24T23:17:05.732212 #7235]  INFO -- : Installing from universe
23:17:05 D, [2020-01-24T23:17:05.732232 #7235] DEBUG -- :   Creating a resolver
23:17:05 Fetching cookbook index from http://my-company-artifactory-server-development:8181/artifactory/api/chef/chef-develop-virtual...

и , этот шаг процесса просто находится здесь за последние 2 + часов.

Я не смог найти ничего в журнале Артефактуры или berks install --debug, что могло бы указать, почему это происходит и зависает!

Мой Berksfile :

# vim: ft=berksfile.ruby:

source "http://my-company-artifactory-server-development:8181/artifactory/api/chef/chef-develop-virtual"

cookbook "my_wrapper_cookbook", ">= 0.0.0"

1 Ответ

0 голосов
/ 29 января 2020

Наша команда опробовала новый экземпляр Artifactory на выходных, и во время учений они указали псевдоним хоста Artifactory my-company-artifactory-server-development на этот новый IP-адрес (например: 11.22.33.44) ,

  • Независимо от того, какое тестирование они провели (запустив различные конвейеры Jenkins), все прошло хорошо.

После тестирования (новый экземпляр Artifactory) они вернулись к исходному Экземпляр Artifactory (например: 1.22.33.444) и сбил новый экземпляр Artifactory.

Похоже, что немногие из сборочных / ведомых машин Jenkins сохранили новый IP-адрес (более нового экземпляра Artifactory) для того же псевдонима имени хоста .

то есть работает traceroute my-company-artifactory-server-development сообщил, что он указывает на новый IP-адрес и не может достичь IP, максимально увеличивая все переходы (так как новый IP / компьютер уже выключен).

-или-

работает wget http://my-company-artifactory-server-development:8181/artifactory/api/chef/chef-develop-virtual показывал ту же информацию об IP и не работал (как ожидалось), так как псевдоним хоста Artifactory указывал на новый IP ( который был недоступен).

Перезапуск службы nscd помог псевдониму хоста: my-company-artifactory-server-development указать / повторно подобрать правильный (оригинал) IP: 1.22.33.444 и теперь berks install работает как положено.

...