Установленный в виртуальной машине Ubuntu Server на UNRAID за обратным прокси NPM Discourse не разрешает имя хоста

Всем привет! Я прочитал множество постов здесь, но безрезультатно, поэтому решил подробно описать свою текущую конфигурацию в надежде, что кто-то сможет дать обратную связь и помочь решить проблему.

В настоящее время я использую сервер Unraid. Unraid размещает Docker-контейнеры, а также виртуальные машины (VM). У меня запущен менеджер обратного прокси Nginx (NPM) в Docker-контейнере, который обрабатывает обратные прокси для всех остальных моих Docker-контейнеров. Мой брандмауэр настроен так, чтобы перенаправлять весь входящий WAN-трафик на порты 80/443 в NPM, а внутри NPM я перенаправляю трафик на свои контейнеры.

Я следовал следующей инструкции: discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

В ней указано, что она предназначена для установки на облачном сервере, однако у меня это физическая машина, размещенная самостоятельно (self-hosted).

Системная информация по состоянию на Sun Jan 28 07:35:54 AM UTC 2024

  Загрузка системы:              0.5126953125
  Использование диска /:         45.9% из 13.16 ГБ
  Использование памяти:          6%
  Использование swap:            0%
  Процессы:                      125
  Вошедшие пользователи:         0
  IPv4-адрес для docker0:        172.17.0.1
  IPv4-адрес для enp1s0:         10.30.20.150

Я запустил виртуальную машину в Unraid, установил Ubuntu Server, настроил статический IP-адрес, установил Docker и загрузил Discourse. При запуске настройки я получаю следующую ошибку:

Введите хостнейм для вашего Discourse? [discourse.example.com]: forum.mydomain.net

Проверка доменного имени . . .
ПРЕДУПРЕЖДЕНИЕ: Порт 443 компьютера, по-видимому, недоступен по указанному хостнейму:
ПРЕДУПРЕЖДЕНИЕ: Соединение с  (порт 80) также не удается установить.

Это означает, что forum.mydomain.net разрешается в некоторый IP-адрес, который не ведет к машине,
где вы устанавливаете Discourse.

Первое, что нужно сделать, — убедиться, что forum.mydomain.net разрешается в IP-адрес этого сервера.
Обычно это делается там же, где вы покупали домен.

Если вы уверены, что IP-адрес разрешается корректно, проблема может быть в брандмауэре.
Поиск в интернете по запросу "открыть порты ВАШЕ ОБЛАЧНОЕ СЕРВИС" может помочь.

Этот инструмент предназначен только для самых стандартных установок. Если вы не сможете решить
проблему выше, вам потребуется самостоятельно отредактировать containers/app.yml, а затем ввести:

./launcher rebuild app

Я могу выполнить ping моей Ubuntu VM по статическому IP-адресу 10.30.20.150 из моего контейнера NPM. Я настроил конфигурацию NPM так, чтобы она направляла запросы на https://10.30.20.150:443, а также на http-порт 80, но это не помогло. При сбое настройки, похоже, контейнер Discourse внутри VM закрывается?

Есть ли какое-либо обходное решение?
Возможно, стоит изменить настройки портов брандмауэра, чтобы обойти обратный прокси и направить трафик напрямую на VM, чтобы она могла получить сертификат и запустить контейнер, а после запуска вручную отредактировать config.yml для использования моего обратного прокси?
Можно ли как-то изменить процесс установки, чтобы он не запрашивал SSL-сертификат, работал на порту 80, а получение SSL-сертификата осуществлялось через NPM?

Наконец, я видел в нескольких постах, что существуют версии Discourse ‘production’ и ‘development’. Похоже, что dev-версию можно запустить на локальном порту в режиме HTML? Если это так, я думаю, что смогу легко разместить всё за своим обратным прокси? Из того, что я читал, production-пакет проще обновлять и он может иметь улучшения производительности.

Буду очень признателен за любую помощь, обратную связь или предложения по этому вопросу.

Это единственная поддерживаемая установка для production здесь.

Однако я не уверен, что она подходит для вашей ситуации, так как у вас уже есть обратный прокси.

Возможно, стоит рассмотреть использование базового образа Discourse и самостоятельно собрать свою собственную конфигурацию:

Можете ли вы убрать в файле app.yml ссылки на порты 80 и 443, поставив перед ними символ #?

Этот файл находится в /var/discourse/containers? Я не могу перейти в эту директорию, система выдает «отказано в доступе».

Таким образом, основная идея заключается в том, чтобы отредактировать Dockerfile базового образа Discourse и удалить строки, которые устанавливают и настраивают обратный прокси, входящий в состав пакета?

Нет, я бы рассмотрел создание полностью индивидуального docker compose (или любого другого инструмента оркестрации, который вы используете) и использование кастомного Dockerfile для Discourse.

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

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

Это относится к продвинутому уровню работы системного администратора, но Docker Compose — это, по сути, игра с очень крутым LEGO: это не так сложно, как кажется, и в интернете много помощи.

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

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

Да, это именно он.

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

Скорее всего, стоит следовать методу «запуск других сайтов».

Да, это не так просто, но у меня был опыт работы с довольно хорошим решением на Docker Compose у одного клиента — никакого launcher в помине!

У меня также есть установка для разработки в приватном облаке на DC…