Здравствуйте,
Я только что установил Discourse и Cloudflared на свой Raspberry Pi 4 и следовал инструкциям из оригинального поста, но не уверен, что указывать в качестве хоста для Discourse. Стоит ли просто указать localhost, так как туннель cloudflared будет перенаправлять запросы?
Может быть, @Falco сможет помочь?
Кстати, извините за всплытие темы.
Для данного руководства вам всё ещё потребуется домен, поэтому значение хоста будет либо корнем домена, либо поддоменом, который вы настроили для Discourse и для туннеля.
Таким образом, значение хоста должно быть тем поддоменом, в котором вы хотите разместить Discourse?
Да, это должен быть URL-адрес, где вы хотите разместить Discourse.
Вы уверены?
Если я сделаю это, я получаю следующую ошибку:
Я установил имя хоста Discourse в точное поддоменное имя, где я хочу, чтобы работал Discourse.
Я установил Cloudflared на Raspberry Pi 4 через командную строку (как описано здесь: Set up your first tunnel · Cloudflare One docs), и я запускаю его как службу.
И я установил Discourse, как указано в вашем оригинальном сообщении, я почти уверен.
Можете поделиться доменом?
Могу я отправить это тебе в личные сообщения? Не хочу, чтобы случайные люди это видели.
Теперь всё работает, когда вы настроили правильное доменное имя?
Да! Только что запустил! Спасибо за помощь! У меня возникла проблема только с MailJet (провайдером электронной почты, который я использую для STMP), который забавно блокирует мои письма для подтверждения.
Пост был объединен с существующей темой: Альтернативы MailJet?
Привет! У меня всё получилось, установка прошла успешно! Есть небольшой вопрос: как вы думаете, сколько активности или пользователей сможет выдержать Raspberry Pi 4 Model B с 4 ГБ оперативной памяти?
Отличный вопрос. Поскольку в такой сложной системе, как Discourse, трудно установить прямую корреляцию между количеством пользователей и нагрузкой на сервер, справедливо признать, что основным узким местом в системе на Raspberry Pi является пропускная способность дискового ввода-вывода (IOPS).
Таким образом, пока большая часть необходимых ресурсов находится в оперативной памяти (между RSS-памятью процессов и кэшированием Linux), вы должны получить плавную работу. Тот факт, что Cloudflare выступает в роли кэширующего CDN, также значительно поможет, а через некоторое время вы даже сможете продлить срок службы вашей установки Pi, используя использование объектного хранилища для загрузки файлов (S3 и аналоги).
У меня возникла эта ошибка в Docker:
FAILED
--------------------
Pups::ExecError: /usr/local/bin/ruby -e 'if ENV["DISCOURSE_HOSTNAME"] == "discourse.example.com"; puts "Aborting! Domain is not configured!"; exit 1; end' завершилась с ошибкой #<Process::Status: pid 115 exit 1>
Место ошибки: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
Выполнение не удалось с параметрами "/usr/local/bin/ruby -e 'if ENV[\"DISCOURSE_HOSTNAME\"] == \"discourse.example.com\"; puts \"Aborting! Domain is not configured!\"; exit 1; end'"
Загрузка не удалась с кодом выхода 1
** ЗАГРУЗКА НЕ УДАЛАСЬ ** Пожалуйста, прокрутите вверх и найдите более ранние сообщения об ошибках — их может быть несколько.
./discourse-doctor может помочь диагностировать проблему.
9ba0db264ae559f3f748cc1e42a8683ea0b4e355b0d45da0f472afea7ff7c472
Это означает, что вы неправильно настроили свой домен. Для работы требуется действительный домен. Запустите ./discourse-setup повторно или отредактируйте файл app.yml, чтобы исправить это.
спасибо за ответ
мне удалось развернуть это на RockPi4 
Привет, @Falco,
Я почти уверен, что настроил всё в точности как в твоей инструкции, но заметил кое-что странное.
В конфигурации контейнера я не загружаю SSL-шаблоны, и переменная окружения DISCOURSE_FORCE_HTTPS установлена в true. Не совсем понимаю, что именно она делает, но предполагаю, что она устанавливает SiteSetting.force_https в true и скрывает эту настройку в админ-панели, чтобы её нельзя было отключить.
Моя конфигурация туннеля Cloudflare выглядит так:
ingress:
- hostname: dc.example.com
service: http://dc:80 # dc — имя моего отдельного контейнера с Discourse
Дело в том, что я могу открыть http://dc.example.com, и перенаправление на HTTPS не происходит. Это ожидаемое поведение?
Ты можешь воспроизвести эту проблему? Мне интересно, не баг ли это.
Мои соответствующие настройки Cloudflare:
Я знаю, что могу настроить перенаправление через Cloudflare (либо через «Всегда использовать HTTPS», либо через правило массового перенаправления), но я предполагал, что если включено force_https, то сам Discourse должен обрабатывать это и перенаправлять все внутренние URI. Что думаешь?
Если проигнорировать проблему с перенаправлением, то доступ к https://dc.example.com работает нормально независимо от значений DISCOURSE_FORCE_HTTPS или SiteSetting.force_https.
Редактирование: Несмотря на то, что я до сих пор не до конца понимаю, что именно force_https делает в нашем случае (возможно, она ничего не делает, если SSL-шаблоны не подключены?), мне только что пришло в голову, что конфигурация туннеля, скорее всего, не сработает как есть, если Discourse действительно перенаправляет всё на HTTPS. Если бы он это делал, argotunnel не смог бы обращаться к Discourse по HTTP (как в service: http://dc:80), поэтому, возможно, мне стоит:
service: https://dc:443)В любом случае, может быть, стоит обновить твою инструкцию по argotunnel, чтобы учесть этот момент?
О, вы правы. Я не заметил этого: мой тестовый домен верхнего уровня .dev работает только по HTTPS:
Я обновил руководство, добавив рекомендацию использовать правило страницы для этого. Спасибо за сообщение!
Но у меня есть вопрос… Я вижу высокий показатель анонимных просмотров на странице «Объединённые просмотры страниц». Думаю, это из-за DDoS-атаки, так как загрузка CPU сервера достигла 60%, а активность краулера невелика. Но как защититься от DDoS-атак? Заранее спасибо за ответ.
Если вы используете Cloudflare как обратный прокси (это отдельная вещь от cloudflared/argotunnel), то защита от DDoS будет включена по умолчанию. Включите её, выбрав «оранжевое облако» для ваших DNS-записей.