Чистая установка возвращает 502 Bad Gateway

[NullUsername (NulledName)]

Всем привет,

Я установил Discourse дважды: один раз в контейнере, а текущую версию — на виртуальной машине (ВМ). В обоих случаях Discourse недоступен. Не совсем понимаю, в чём может быть проблема.

Виртуальная машина Discourse:

• Ядра: 4
• ОЗУ: 6 ГБ
• Хранилище: 50 ГБ
• ОС: Ubuntu 22.04.3

Команды для чистой установки после установки ОС:

apt update -y && apt upgrade -y && apt install wget curl zip git docker.io -y && reboot

Затем я следовал следующему руководству: discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

После завершения установки я вижу, что контейнер запущен, но возвращается ошибка 502 Bad Gateway.

Как я это настроил: Nginx Reverse Proxy (включая SSL) → ВМ. Это не работает.
Даже при добавлении записи напрямую в файл hosts страница не загружается.

Из последних строк установки видно, что Docker создал новую сеть:

DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443

Как заставить его использовать IP-адрес хостовой машины?
Мне не нужна сеть внутри сети. Я готов, чтобы Docker использовал IP-адрес хоста, так как на этой ВМ работает только этот сервис.

Буду очень признателен за любую помощь!

Существует ли официальный способ установки без использования Docker?

[pfaffman (Jay Pfaffman)]

Расположен ли контейнер на машине с публичным IP-адресом? Есть ли у этого публичного IP-адреса назначенное доменное имя?

Вы запускали discourse-setup? Удалось ли вам пройти этап проверки корректности DNS и доступности хоста?

Вы выполняли множество пересборок, из-за чего попали под ограничение скорости от Let’s Encrypt и не можете получить сертификат?

[NullUsername (NulledName)]

@pfaffman

Контейнер запущен на машине с публичным IP-адресом? Привязан ли к этому публичному IP доменное имя?

Нет, этой машине назначен локальный IP-адрес, и трафик перенаправляется на него через мой межсетевой экран. Это не проблема.
У публичного IP есть A-запись для сервера, и маршрутизация работает корректно. forum.somedomain.com указывает на правильный сервер.

@pfaffman

Вы запускали discourse-setup? Удалось ли вам пройти этап проверки корректности DNS и доступности хоста?

Да, установка завершена. Я провёл её до конца (трижды) до момента запуска контейнера.
Все проверки домена/DNS пройдены успешно. Система сообщает, что всё валидно.

@pfaffman

Вы выполняли множество повторных сборок, из-за чего попали под ограничение скорости от Let’s Encrypt и не можете получить сертификат?

Нет, здесь невозможно попасть под ограничение скорости, так как SSL-сертификат выдаётся через мой обратный прокси. У меня есть сертификат.

Эта установка завершена на 100%. Проблема в том, что Docker создаёт новую сеть 172.17.0.1, что не нужно, поскольку я хочу использовать локальный IP-адрес хоста 192.xx.xx.xx.

Контейнер запущен, но в другой сети. Мне не удаётся привязать его к IP-адресу хоста.

@NullUsername

По последним строкам установки видно, что Docker создал новую сеть:

DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443

IP-адрес Docker-хоста должен соответствовать IP-адресу сервера-хоста (192.xxx.xxx.xxx), а не новой сети. Скорее всего, всё работает, но в этой сети.
Как указать установке использовать мой локальный IP, а не 172.17.0.1?

[NullUsername (NulledName)]

@pfaffman Что-то вроде этого. Из вашего комментария

@pfaffman

Попробуйте, возможно, так:

 ./launcher start app --docker-args '--network discourse_back --ip 192.168.1.4'

Как мне настроить ./discourse-setup так, чтобы он использовал IP-адрес хоста 192.168.1.X и сеть при установке?

[pfaffman (Jay Pfaffman)]

Вы не можете использовать discourse-setup с обратным прокси-сервером. Вам придется отредактировать файл yml вручную. Существуют темы о запуске Discourse вместе с другими сайтами на одной машине.

Если вы используете обратный прокси-сервер, который обрабатывает SSL, вам нужно будет удалить шаблоны ssl и let’s encrypt.

[NullUsername (NulledName)]

@pfaffman

Есть несколько тем о запуске Discourse вместе с другими сайтами на одной машине.

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

Кажется, здесь возникло недопонимание.

./docker-setup устанавливается успешно. Он создаёт собственную сеть для приложения с адресом 172.17.0.1.

Как мне настроить установку или docker-контейнер так, чтобы они использовали IP-адрес хоста 192.168.1.X, то есть работали в режиме мостовой сети, а не создавали свою собственную?

[pfaffman (Jay Pfaffman)]

@NullUsername

Дело в том, что я не запускаю никаких других сервисов на этой машине. Это отдельная виртуальная машина.

Но вы сказали следующее:

@NullUsername

Нет, это не может быть ограничено по частоте запросов, так как SSL-сертификат выдаётся через мой обратный прокси. У меня есть сертификат

Если вы используете обратный прокси, вы не можете использовать discourse-setup.

[NullUsername (NulledName)]

@pfaffman

Но вы сказали следующее:

@NullUsername

Нет, это не может быть ограничено по частоте запросов, так как SSL-сертификат выдаётся через мой обратный прокси. У меня есть сертификат.

Если вы используете обратный прокси, вы не можете использовать discourse-setup.

Да, обратный прокси находится на другом сервере, но я понимаю, что вы имеете в виду.

У меня есть идея. Я просто направлю весь трафик из моей сети в сеть контейнеров Docker.

Есть ли руководство по установке для запуска Discourse за обратным прокси nginx?

Или способ собрать Discourse самостоятельно?

[Jagster (Jakke Flemming)]

Это довольно просто. Вы разрешили HTTP-порт в app.yml, куда Nginx отправляет трафик, и отключили SSL. Нужно исправить только эти две вещи. Конечно, нужно указать реальный IP, но это требуется делать всегда для любого бэкенда: Discourse, Moodle, WordPress или чего-то ещё. UFW пытается ограничить доступ только между фронтендом и бэкендом, так как нет необходимости разрешать прямой доступ к бэкенду.

Если я не ошибаюсь, вот документация по настройке Apache2. Nginx делает то же самое, но, конечно, по-своему.

Или что я сейчас упустил?

[NullUsername (NulledName)]

Давайте начнём с самого начала, чтобы вы могли понять, что я упускаю.

У меня есть обратный прокси-сервер Nginx. Он работает с публичным IP-адресом и выполняет маршрутизацию трафика к сервисам.

Например: запрос клиента к cloud.domain.com → Обратный прокси Nginx (обрабатывает SSL) → перенаправляет на cloud.domain.com.

Теперь я настроил виртуальную машину для Discourse и выполнил следующие команды:
Ubuntu 23.04. Команды после установки ОС:

apt update -y \
apt upgrade -y \
apt install wget curl zip git docker.io -y

Затем я следовал этому руководству от Discourse: discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

Установка завершилась успешно, но затем начались проблемы.

Я не могу получить доступ к контейнеру Docker с хоста из-за сети docker0. Я могу выполнить ping до 172.17.0.2, и контейнер работает, но с хоста машины по адресу 192.168.1.10:80/443 трафик не передаётся в контейнер.

Моя цель — чтобы контейнер Docker использовал сеть хоста, так как в контейнере открыты порты 80 и 443.

Первый обратный прокси Nginx обрабатывает трафик извне и корректно передаёт его на виртуальную машину. Если бы это не работало, утилита ./discourse-setup не смогла бы определить доменное имя правильно и не смогла бы получить SSL-сертификаты для контейнера.

В итоге: я знаю, что контейнер работает на 100%, просто я не могу получить к нему доступ из-за сети Docker.

Если вам нужна дополнительная информация, пожалуйста, дайте знать.

[merefield (Robert)]

Другой подход — использовать базовый образ Discourse

discourse/base - Docker Image

и создать собственную систему оркестрации, например, с помощью Docker Compose (помня, что вам понадобятся дополнительные сервисы, такие как Redis и PostgreSQL).

[Jagster (Jakke Flemming)]

Я могу настроить это с помощью Nginx или Nginx + Varnish для Discourse на одном VPS или на разных VPS с разными IP-адресами. Вы не уточнили, что именно вы делаете с вашим Nginx, выступающим в роли обратного прокси. Ваши примеры немного запутаны, так как непонятно, являются ли они просто примерами или вы действительно пытаетесь использовать частную сеть.

Однако:

@NulledName

хост-машина 192.168.1.10:80/443 не передаёт трафик в контейнер.

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

Что-то вроде этого (что на самом деле используется с Varnish, но принцип точно такой же и это очень базовые вещи):

proxy_pass http://127.0.0.1:8080;
proxy_set_header X-Real-IP  $remote_addr;
proxy_set_header X-Forwarded-For
 $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Port 443;
proxy_set_header Host $host;
proxy_pass_header Server;

[NullUsername (NulledName)]

@Jagster

Ваши примеры немного запутанные, потому что невозможно понять, являются ли они просто примерами или вы действительно пытаетесь использовать частную сеть.

Понимаю, спасибо за конкретику :).

@Jagster

Но:

@NullUsername

хост-машина 192.168.1.10:80/443 не пропускает трафик в контейнер.

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

Не совсем уверен, потому что эта Docker-сеть запутывает.

@Jagster

Что-то вроде этого (это действительно используется с Varnish, но принцип абсолютно тот же, и это очень базовые вещи):

Именно поэтому я так расстраиваюсь из-за Docker, lol.

Ниже показано точно, как WAN-сеть пропускает и маршрутизирует трафик от моего обратного прокси-сервера Nginx к нужному хосту.

map $scheme $hsts_header {
    https   "max-age=63072000;includeSubDomains; preload";
}

server {
  set $forward_scheme https;
  set $server         "10.10.1.38";
  set $port           443;

  listen 80;
listen [::]:80;

listen 443 ssl http2;
listen [::]:443 ssl http2;


  server_name forum.domainname.com;

  # Let's Encrypt SSL
  include conf.d/include/letsencrypt-acme-challenge.conf;
  include conf.d/include/ssl-ciphers.conf;
  ssl_certificate /srv/ssl/domainname.pem;
  ssl_certificate_key /srv/ssl/domainname-ke.pem;


# Кэширование ассетов
include conf.d/include/assets.conf;

# Блокировка эксплойтов
include conf.d/include/block-exploits.conf;

# HSTS (требуется модуль ngx_http_headers_module) (63072000 секунд = 2 года)
add_header Strict-Transport-Security $hsts_header always;

# Принудительное использование SSL
include conf.d/include/force-ssl.conf;

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;


access_log /var/logs/domainname-access.log proxy;
error_log /var/logs/domainame_error.log warn;

proxy_set_header  X-Real-IP $remote_addr;
proxy_set_header  X-Forwarded-For $http_x_forwarded_for;
proxy_set_header  X-Forwarded-Proto $scheme;

location / {

  # HSTS (требуется модуль ngx_http_headers_module) (63072000 секунд = 2 года)
  add_header Strict-Transport-Security $hsts_header always;

    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_http_version 1.1;
    
    # Прокси!
    include conf.d/include/proxy.conf;
  }
}

Странно то, что я однажды настроил Docker-контейнер для клиента, которому нужен был менеджер обратного прокси-сервера Nginx, и это было чрезвычайно просто.

docker-compose up -d
Всё. Частный IP 192.168.1.3 мог обращаться к открытым портам 80/443 контейнеров, а исходящий трафик корректно маршрутизировался на 192.168.1.3.

[Jagster (Jakke Flemming)]

@NullUsername

Не уверен, что именно, потому что эта сеть Docker запутанная.

Она запутанная, потому что это пакетная система, работающая в собственном изолированном окружении. По сути, всё в этом и заключается.

Но понимание Docker — это одно, а его использование — совсем другое (и теперь целая куча разработчиков начала ныть ). Ваш обратный прокси отправляет трафик на IP-адрес через брандмауэр, и вам нужно указать этот IP и порт прослушивания. У вас на этом IP запущен Discourse (то есть Docker), а порт вы указываете в app.yml. Внутренний Nginx, работающий непосредственно с Discourse, берёт на себя остальное.

Discourse не должен слушать порт 443, так как вы уже завершили SSL-соединение.

И, по сути, вы не можете использовать кэширование на обратном прокси. Бэкенд, то есть Discourse, — это не веб-страница. Это веб-приложение, отправляющее JavaScript и JSON.

[NullUsername (NulledName)]

@Jakke Flemming

Это сбивает с толку, потому что это пакетная система, которая работает в своём собственном изолированном окружении. По сути, всё именно так.

Я вроде бы уже понял это.

@Jakke Flemming

Но понимание Docker — это одно, а его использование — совсем другое (и теперь куча разработчиков начала плакать )

С этим я согласен. Я бы не сказал, что они плачут, просто это бесполезно для системных администраторов и разработчиков, которые действительно разбираются в Linux. Создание LXC или виртуальной машины, которая изолирована, чтобы затем позволить Docker создать ещё одну изолированную среду, — это излишне и бессмысленно.

@Jakke Flemming

Ваш обратный прокси отправляет трафик на IP-адрес через фаервол, и вам нужно указать этот IP и порт прослушивания. На этом IP у вас работает Discourse, то есть Docker, а порт, который вы указываете в app.yml. Внутренний Nginx, который работает с самим Discourse, берёт на себя остальное.

Discourse не должен слушать порт 443, потому что вы уже завершили SSL.

Вот эта часть сбивает с толку. В app.yml порты 80:80 и 443:443 пробрасываются на 172.17.0.2, который находится в сети Docker 172.17.0.1/16, в то время как IP-адрес виртуальной машины — 10.10.1.38.

Как мне настроить Discourse/Docker так, чтобы весь входящий трафик на 10.10.1.38 перенаправлялся на 172.17.0.2, а весь исходящий трафик шёл через 10.10.1.38? Это всё, что нужно для решения этой проблемы. Буквально всё.

Мой обратный прокси будет обрабатывать маршрутизацию от WAN к forum.domainname.com.

@Jakke Flemming

И вы в принципе не можете использовать кэширование на обратном прокси. Бэкенд, Discourse, — это не веб-страница. Это веб-приложение, которое отправляет JavaScript и JSON.

Кэширование было отключено.

[Jagster (Jakke Flemming)]

@NullUsername

app.yml открывает порты 80:80 и 443:443

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

80:80 и 443:443 — это значения по умолчанию, которые используются только в том случае, если нет обратного прокси-сервера или чего-либо ещё, выступающего в качестве фронтенда.

[NullUsername (NulledName)]

Ты дал мне идею.

Я был занят проверкой всех базовых файлов и, думаю, разобрался.

Так просто, лол. Я сейчас занимаюсь восстановлением, и это может сработать на 100%, если использовать стандартные официально поддерживаемые методы установки.

[NullUsername (NulledName)]

Успех! Форум теперь установлен и работает.

Используя стандартный и поддерживаемый метод установки

[NullUsername (NulledName)]

@pfaffman Вы можете переместить это в раздел установки, так как сейчас это поддерживаемая установка.

[Jagster (Jakke Flemming)]

Оно там есть. Просто помечено как неподдерживаемое

А в чём была проблема изначально, из-за чего вы не начали установку без обратного прокси? Мне просто интересно.