Не люблю поднимать эту тему снова, но она всё ещё актуальна. Всё устанавливается безупречно с точки зрения Discourse, всё кажется в порядке, но порты 80 и 443 общедоступно недоступны.
Обновление: Базовая установка действительно работает из коробки на Azure с Ubuntu Server.
Вот что я сделал иначе во второй раз:
-
После создания ВМ и запуска
discourse-setupя не прерывал процесс, поэтому всё выполнилось за один раз.В первый раз я понял, что у меня нет swap-памяти, и хотя скрипт
discourse-setupнастраивает её при отсутствии, я вышел в оболочку, чтобы проверить что-то. Затем некоторые подсказки установки отличались от тех, что в базовом руководстве, поэтому я вышел ещё раз.+ Меня удивил запрос Let’s Encrypt на адрес электронной почты для получения уведомлений, и у меня сложилось впечатление, что HTTPS нужно будет настроить вручную. На самом деле скрипт настраивает экземпляр Discourse с SSL-сертификатом Let’s Encrypt.
+ Ещё один момент — разделы имени пользователя и пароля SMTP; всё ещё не уверен, можно ли было оставить их пустыми, но я просто указал адрес администратора и пароль для этой учётной записи. -
Вручную настроил swap-пространство согласно этой теме на meta.discourse.
Не думаю, что это имело какое-то отношение к проблеме, но упомяну на всякий случай. Во второй раз я сделал всё так же, как и в первый, за исключением: (1) ручной настройки swap и (2) позволяя
discourse-setupработать без прерываний.
Возможно, первый экземпляр можно было бы спасти, но архитектура Discourse всё ещё остаётся для меня загадкой, и я не уверен, как перезапустить HTTP/HTTPS-эндпоинты. При сравнении выводов netstat -tulpn очевидно, что в первом экземпляре все соответствующие службы, похоже, работают и прослушивают правильные порты (например, PostgreSQL на 5432, Redis на 6379 и т. д.), а единственные два отсутствующих входа — это порты 80 и 443 (что указывает на то, что nginx не работал):
Первый (неудачный) экземпляр:
$ sudo -s
# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
62396a99737c local_discourse/app "/sbin/boot" 14 hours ago Up 14 hours 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp app
# docker exec -it 62396a99737c bash
(docker)# netstat -tulpn
Active Internet connections (only servers)
Proto Local Address Foreign Address State PID/Program name
tcp 127.0.0.1:3000 0.0.0.0:* LISTEN -
tcp 0.0.0.0:5432 0.0.0.0:* LISTEN -
tcp 0.0.0.0:6379 0.0.0.0:* LISTEN -
tcp6 :::5432 :::* LISTEN -
tcp6 :::6379 :::* LISTEN -
Второй экземпляр:
(docker)# netstat -tulpn
Active Internet connections (only servers)
Proto Local Address Foreign Address State PID/Program name
tcp 0.0.0.0:6379 0.0.0.0:* LISTEN -
tcp 0.0.0.0:80 0.0.0.0:* LISTEN 2359/nginx: master
tcp 127.0.0.1:3000 0.0.0.0:* LISTEN -
tcp 0.0.0.0:5432 0.0.0.0:* LISTEN -
tcp 0.0.0.0:443 0.0.0.0:* LISTEN 2359/nginx: master
tcp6 :::6379 :::* LISTEN -
tcp6 :::5432 :::* LISTEN -
Несколько заметок для себя в будущем:
-
В первый раз я заметил отсутствие прослушивающих портов 80 и 443, но увидел сокет
127.0.0.1:3000(который, как я помню, является стандартным портом Rails). Мне ещё не пришло в голову, что, возможно, nginx не работал, и по какой-то причине я всё ещё подозревал, что проблема в сопоставлении портов Docker, поэтому я сделал простую пересылку через netcat:Внутри Docker:
nc -l -p 80 -c "nc 127.0.0.1 3000"
Вне Docker в ВМ:nc -zv localhost 80иcurl localhost:80(это убедило меня, что с Docker всё в порядке) -
Я также подозревал правила входящих портов Azure, потому что
nc -zvпостоянно возвращалConnection refused, но затем понял, что это означает лишь то, что порты открыты, но по другую сторону никто не слушает. (Если бы порты были заблокированы,ncпросто завис.)