Исправлен загрузочный цикл GitLab Omnibus Docker (ранее работал)? - PullRequest
Новая
       10

Исправлен загрузочный цикл GitLab Omnibus Docker (ранее работал)?

0 голосов
/ 19 мая 2018

Итак, после окончательной настройки GitLab и использования его в течение дня, я решил попытаться включить реестр GitLab.Однако после запуска gitlab-ctl reconfigure система входит в цикл загрузки (каждая загрузка длится 10-15 с).

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

Я запускаю образ GitLab (последняя версия) Omnibus Docker на VPS-устройстве с дроплетами Digital Ocean.GitLab настроен так, чтобы не использовать https, так как я использую обратный прокси-сервер (apache) для подключения (это соединение через https).

Настройка обратного прокси Browser => example.com:443 (https) => localhost: 8888 (http)

Вывод Docker ps 

c13e26a20f7d        gitlab/gitlab-ce:latest       "/assets/wrapper"        24 hours ago        Up 2 seconds (health: starting)   0.0.0.0:2222->22/tcp, 0.0.0.0:8888->80/tcp, 0.0.0.0:4444->443/tcp   gitlab

Что я пробовал (без успеха):

  • Восстановление снимка ранее работающей конфигурации.
  • Восстановление прав доступа к файлу с помощью команды gitlab-ctl.
  • Поиск подсказок любого типа в доступных файлах журнала (только для журналов доступа.

Любые предложения и / или , как бы я решил эту проблему , будет принята с благодарностью!

1 Ответ

0 голосов
/ 19 мая 2018

Исправление : Завершение работы Docker Container, проверка журналов переконфигурации (находится в каталоге logs / переконфигурирование в папке установки) и внесение изменений в файл конфигурации на основеошибки, обнаруженные в журнале.

Исправление цикла загрузки (шаг за шагом)

ПРИМЕЧАНИЕ : если вы не работаетекак пользователь root, я рекомендую временно запустить его как root (используя sudo su), чтобы избежать ошибок, связанных с отказом в доступе.

После ручной остановки Docker Container я смог просмотреть полный журнал, расположенный по адресу /srv/gitlab/logs/reconfigure (с самой последней отметкой времени)

Выдержка из последнего журнала перенастройки: 

[2018-05-19T00:24:50+00:00] INFO: *** Chef 13.6.4 ***
[2018-05-19T00:24:50+00:00] INFO: Platform: x86_64-linux
[2018-05-19T00:24:50+00:00] INFO: Chef-client pid: 25
[2018-05-19T00:24:50+00:00] INFO: The plugin path /etc/chef/ohai/plugins does not exist. Skipping...
[2018-05-19T00:24:52+00:00] WARN: Plugin Network: unable to detect ipaddress
[2018-05-19T00:24:52+00:00] INFO: Setting the run_list to ["recipe[gitlab]"] from CLI options
[2018-05-19T00:24:52+00:00] INFO: Run List is [recipe[gitlab]]
[2018-05-19T00:24:52+00:00] INFO: Run List expands to [gitlab]
[2018-05-19T00:24:52+00:00] INFO: Starting Chef Run for [REDACTED]
[2018-05-19T00:24:52+00:00] INFO: Running start handlers
[2018-05-19T00:24:52+00:00] INFO: Start handlers complete.
[2018-05-19T00:24:54+00:00] INFO: Loading cookbooks [gitlab@0.0.1, package@0.1.0, postgresql@0.1.0, registry@0.1.0, mattermost@0.1.0, consul@0.0.0, gitaly@0.1.0, letsencrypt@0.1.0, nginx@0.1.0, runit@0.14.2, acme@3.1.0, crond@0.1.0, compat_resource@12.19.0]
[2018-05-19T00:24:56+00:00] WARN: Runtime directory '/run' is not a tmpfs.

Сообщения об ошибках - хорошее начало, но не раскрывают основную проблему ... 

[2018-05-19T00:24:56+00:00] ERROR: Running exception handlers
[2018-05-19T00:24:56+00:00] ERROR: Exception handlers complete

Теперь последние 3 строки журнала выявили проблему 

[2018-05-19T00:24:56+00:00] FATAL: Stacktrace dumped to /opt/gitlab/embedded/cookbooks/cache/chef-stacktrace.out
[2018-05-19T00:24:56+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[2018-05-19T00:24:56+00:00] FATAL: RuntimeError: Unsupported GitLab Registry external URL path: /gitlab/registry

Теперь, увидев самую последнюю строку, я вижу, что моя конфигурация неверна и имеет значение причина смертипроблема .

Чтобы устранить проблему, я отредактировал конфигурацию, когда контейнер докера находился в незагруженном состоянии (файл конфигурации находится в /srv/gitlab/config/gitlab.rb).После исправления конфигурации, которая в моем случае заключалась в том, чтобы закомментировать все параметры конфигурации реестра GitLab (поскольку я решил пока подождать с тестированием этой функции).

Разница для конфигурации 

################################################################################
## Container Registry settings
##! Docs: https://docs.gitlab.com/ce/administration/container_registry.html
################################################################################

- registry_external_url 'http://[REDACTED]:4567/gitlab/registry'
+ # registry_external_url 'http://[REDACTED]:4567/gitlab/registry'

### Settings used by GitLab application
- gitlab_rails['registry_enabled'] = true
+ # gitlab_rails['registry_enabled'] = true
- gitlab_rails['registry_host'] = "[REDACTED]"
+ # gitlab_rails['registry_host'] = "[REDACTED]"
- gitlab_rails['registry_port'] = "4567"
+ # gitlab_rails['registry_port'] = "4567"
- gitlab_rails['registry_path'] = "/var/opt/gitlab/gitlab-rails/shared/registry"
+ # gitlab_rails['registry_path'] = "/var/opt/gitlab/gitlab-rails/shared/registry"

Я запустил следующие команды, чтобы загрузить контейнер и применить новую конфигурацию. 

docker start gitlab
sudo docker exec gitlab gitlab-ctl reconfigure

Обнадеживающие результаты сразу же, поскольку контейнер не перезагрузился сразу после того, как я выполнил команду. 

Starting Chef Client, version 13.6.4
resolving cookbooks for run list: ["gitlab"]
Synchronizing Cookbooks:
  - gitlab (0.0.1)
  - package (0.1.0)
  - registry (0.1.0)
  - postgresql (0.1.0)
  - letsencrypt (0.1.0)
  - mattermost (0.1.0)
  - runit (0.14.2)
  - nginx (0.1.0)
  - gitaly (0.1.0)
  - consul (0.0.0)
  - acme (3.1.0)
  - crond (0.1.0)
  - compat_resource (12.19.0)
Installing Cookbook Gems:
...

Это оно!Теперь все работает как надо.Оказалось, ошибка пользователя была причиной проблемы.

...