Установка Discourse в интранете — сбой bootstrap с кодом выхода 17

Здравствуйте,

Я устанавливаю Discourse в среде интранета. Иногда во время процесса пересборки я сталкиваюсь с этой ошибкой:

Pups::ExecError: cd /var/www/discourse && su discourse -c ‘bundle install --retry 3 --jobs 4’ failed with return #<Process::Status: pid 645 exit 17>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn’
exec failed with the params {“cd”=>“$home”, “hook”=>“bundle_exec”, “cmd”=>[“su discourse -c ‘bundle config --local deployment true’”, “su discourse -c ‘bundle config --local without "development test"’”, “su discourse -c ‘bundle install --retry 3 --jobs 4’”]}
bootstrap failed with exit code 17
** FAILED TO BOOTSTRAP ** пожалуйста, прокрутите вверх и поищите более ранние сообщения об ошибках, их может быть несколько.
./discourse-doctor может помочь в диагностике проблемы.
6ef3d42536c82021bdb1f24980cbd860572869f207e4eb2001e59e8923b182cf
root@wpyb3816:/var/discourse# cat /etc/docker/daemon.json

Кто-нибудь знает, что это может быть?
Спасибо.

Появляются ли какие-либо другие сообщения об ошибках ранее в вашем логе сборки?

I, [2024-03-29T14:58:21.260866 #1] INFO – :
I, [2024-03-29T14:58:21.261079 #1] INFO – : > su postgres -c ‘createdb discourse’ || true
2024-03-29 14:58:21.298 UTC [55] postgres@postgres ERROR: база данных “discourse” уже существует
2024-03-29 14:58:21.298 UTC [55] postgres@postgres STATEMENT: CREATE DATABASE discourse;
createdb: ошибка: создание базы данных не удалось: ERROR: база данных “discourse” уже существует
I, [2024-03-29T14:58:21.299606 #1] INFO – :
I, [2024-03-29T14:58:21.299710 #1] INFO – : > su postgres -c ‘psql discourse -c “create user discourse;”’ || true
2024-03-29 14:58:21.334 UTC [59] postgres@discourse ERROR: роль “discourse” уже существует
2024-03-29 14:58:21.334 UTC [59] postgres@discourse STATEMENT: create user discourse;
ERROR: роль “discourse” уже существует

а затем ещё одна ошибка перед падением …

[2024-03-29T14:59:48.410149 #1] INFO – : > cd /var/www/discourse && su discourse -c ‘bundle install --retry 3 --jobs 4’
Повторная попытка получения данных из-за ошибки (2/4): Bundler::Fetcher::CertificateFailureError Не удалось проверить SSL-сертификат для https://rubygems.org/.
Возможно, вы столкнулись с атакой «человек посередине», но скорее всего в вашей системе отсутствуют необходимые сертификаты удостоверяющего центра (CA) для проверки. Справочную информацию о сертификатах OpenSSL см. по адресу OpenSSL Errors and Rails – Certificate Verify Failed · RailsApps.
Повторная попытка получения данных из-за ошибки (3/4): Bundler::Fetcher::CertificateFailureError Не удалось проверить SSL-сертификат для https://rubygems.org/.
Возможно, вы столкнулись с атакой «человек посередине», но скорее всего в вашей системе отсутствуют необходимые сертификаты удостоверяющего центра (CA) для проверки. Справочную информацию о сертификатах OpenSSL см. по адресу OpenSSL Errors and Rails – Certificate Verify Failed · RailsApps.
Повторная попытка получения данных из-за ошибки (4/4): Bundler::Fetcher::CertificateFailureError Не удалось проверить SSL-сертификат для https://rubygems.org/.
Возможно, вы столкнулись с атакой «человек посередине», но скорее всего в вашей системе отсутствуют необходимые сертификаты удостоверяющего центра (CA) для проверки. Справочную информацию о сертификатах OpenSSL см. по адресу OpenSSL Errors and Rails – Certificate Verify Failed · RailsApps.
Не удалось проверить SSL-сертификат для https://rubygems.org/.
Возможно, вы столкнулись с атакой «человек посередине», но скорее всего в вашей системе отсутствуют необходимые сертификаты удостоверяющего центра (CA) для проверки. Справочную информацию о сертификатах OpenSSL см. по адресу OpenSSL Errors and Rails – Certificate Verify Failed · RailsApps.
I, [2024-03-29T14:59:49.328710 #1] INFO – : Получение индекса источников с https://rubygems.org/

В этом и проблема. Похоже, ваш интернет-провайдер блокирует доступ к rubygems.

Discourse требует HTTPS, а стандартная установка должна быть доступна по общедоступному IP-адресу для получения сертификата. Скорее всего, у вас возникнут проблемы и по этой причине.

Хорошо, я отправил внутренний запрос на открытие этого URL, так как в среде интранета все URL-адреса по умолчанию закрыты.

Как только это будет сделано, я сообщу вам о результатах. Спасибо.

Та же ошибка при открытии URL https://rubygems.org/

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

Работа Discourse в закрытой интрасети, не имеющей доступа к интернету, официально не поддерживается. Возможно, вы сможете создать образ где-то ещё, а затем попытаться запустить его в своей интрасети. Однако вам всё равно придётся самостоятельно решить вопрос получения SSL-сертификатов для HTTPS.

Здравствуйте,

Вот что я сделал:

  • Я создал образ извне интранета на своём ПК.
  • Загрузил его в репозиторий.
  • Скачал образ на виртуальную машину в интранете и запустил контейнер.
    ./launcher start app --run-image my image

Контейнер работает нормально, но порты 80/443, похоже, недоступны (я проверил с помощью nmap — они открыты!). Я не могу получить доступ к приложению через браузер. При вводе команды curl -v localhost:80 я получаю следующую ошибку.

* Используется переменная окружения прокси no_proxy == 'localhost,127.0.0.1,.laposte.fr'
*   Попытка подключения к 127.0.0.1:80...
* Подключено к localhost (127.0.0.1) порт 80 (#0)
> GET / HTTP/1.1
> Host: localhost
> User-Agent: curl/7.81.0
> Accept: */*
> 
* Ошибка получения данных: соединение сброшено удалённым узлом
* Закрытие соединения 0
curl: (56) Ошибка получения данных: соединение сброшено удалённым узлом

Полагаю, у вас нет сертификатов, и nginx не работает. Вам нужно удалить шаблоны ssl и let’s encrypt и собрать новый образ. Затем вам потребуется обратный прокси с сертификатом.

Возможно, вы сможете использовать сертификат, который вы сгенерировали самостоятельно. Думаю, на эту тему ещё есть тема (созданная до появления let’s encrypt).

Вы можете посмотреть логи nginx, чтобы увидеть ошибки.

Я не активировал шаблон Let’s Encrypt в моём файле app.yml, поэтому мне не стоит беспокоиться об этом запросе на удаление, верно? Однако я использую фронтенд VIP с собственным сертификатом.