Discourse использует двойной nginx: ошибка — модуль `handlebars` не найден, импортируется из `discourse-common/lib/raw-handlebars`

Поддержка Самостоятельное хостинг
,
1

Привет!
Мой сайт использует версию 2.9 Discourse. По какой-то причине мне пришлось использовать двойной nginx для Discourse. Я развернул два контейнерных узла web_only для Discourse и использовал nginx в качестве прокси перед ними. Схема архитектуры моей системы:

image
image718×978 12.1 KB

Я был сбит с толку, когда мой пользовательский nginx-прокси для двух узлов web_only случайно распределял запросы между любыми узлами web_only, и мой сайт Discourse иногда выдавал ошибки: «Could not find module ‘handlebars’ imported from ‘discourse-common/lib/raw-handlebars’». В этот момент браузер отображал пустой экран. Однако, когда я использовал пользовательский nginx для перенаправления всех запросов только на один из узлов web_only, эта ошибка не возникала. Я искал решение этой проблемы и обнаружил, что ранее были сделаны коммиты для исправления аналогичной ошибки. Я подтвердил, что моя версия содержит код этих коммитов.

Could not find module 'handlebars' imported from 'discourse-common/lib/raw-handlebars'

Broken instance after updating to 2.9.0.beta2 - #11 by david

Не знает ли кто-нибудь, почему это происходит? Большое спасибо!

image
image1728×1566 176 KB

2

Кстати, поделитесь проблемой, когда при использовании двойного nginx невозможно получить реальный IP-адрес пользователя.
Это происходит потому, что мой кастомный nginx включает заголовок X-Forwarded-For для получения IP-адреса клиента, но не отключает X-Forwarded-For в nginx discourse. В результате конфигурация X-Forwarded-For кастомного nginx перезаписывается конфигурацией nginx discourse.

3

И не имеет значения, какой именно вы используете? И они запускают один и тот же образ? Это сбивает с толку.

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

Вам нужно что-то вроде этого в вашем файле web_only.yml:

after_bundle_exec:
  - replace:
    filename: /etc/nginx/conf.d/discourse.conf
    from: "types {"
    to: |
      set_real_ip_from 172.16.0.0/12;
      set_real_ip_from 10.0.0.0/8;
      real_ip_recursive on;
      real_ip_header X-Forwarded-For;
      types {
4

Большое спасибо за ваш ответ.

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

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

Спасибо, это помогло мне решить проблему получения реального IP-адреса пользователя.

6

Это имеет смысл.

Существует настройка для увеличения количества соединений.

Я бы обновился. В той версии, вероятно, есть какая-то проблема, и я почти уверен, что с тех пор было исправлено несколько уязвимостей безопасности.

7

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