Мультисайт против нескольких контейнеров

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

Кто-нибудь знает плюсы и минусы мультисайта по сравнению с несколькими контейнерами?

В настоящее время у меня есть три экземпляра Discourse в отдельных контейнерах, и я думаю о том, чтобы перевести ещё два, а возможно и три форума на Discourse. Они будут размещены на одном сервере (64 ГБ ОЗУ, SSD-диски), поэтому я хочу узнать, какой путь будет наиболее оптимальным.

Я бы предпочёл, чтобы они были максимально независимы: каждый мог бы обновляться, резервироваться и восстанавливаться отдельно, а проблемы с одним не должны влиять на другие.

Что вы посоветуете? На какие плюсы и минусы стоит обратить внимание?

2

В multisite вы не сможете обновлять отдельные сайты по отдельности, также нельзя будет сегментировать используемые плагины. Всё это определяется корневой установкой multisite. Однако настройки, темы и резервное копирование могут выполняться отдельно.

Как правило, также потребуется прокси-сервер перед системой для работы с SSL-сертификатами.

3

На самом деле я нашёл способ, как получить сертификаты Let’s Encrypt для нескольких доменов без перенаправления на основной домен. Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy

@AstonJ, вам интересно протестировать мою инструкцию? Я на 90% уверен, что она работает, но последний раз проверял её несколько недель назад, и не до конца уверен, что инструкции будут понятны и применимы для кого-то другого, кроме меня.

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

4

Я мог бы просто отключать неиспользуемые плагины через ACP (и, насколько я помню, есть только один плагин, который одному из форумов не понадобится), так что, наверное, всё зависит от того, есть ли какие-то преимущества в использовании multisite? В частности, с точки зрения производительности и/или стабильности?

Кажется, я читал, что @Blake однажды писал, что безумие не запускать PG в отдельном контейнере (это отличается от multisite?), поэтому я и задумался об этом. Кстати, не принимайте мои слова на веру — я мог это и присниться :rofl:

Я использую HAProxy, который занимается нашими SSL-сертификатами, так что, думаю, это должно подойти.

Думаю, всё зависит от преимуществ, Джей. Если разница невелика, я не против продолжать как раньше, ведь настройка и управление стали относительно простыми. Но если есть существенные плюсы в переходе на multisite, я определённо заинтересуюсь :sunglasses:

5

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

6

Привет. Возможно ли объединить пользователей мультисайта, чтобы регистрация на одном из сайтов автоматически регистрировала пользователя на всех мультисайтах (как в Magento)? Или же использовать вариант надстройки для Discourse, похожий на федерацию, чтобы уведомления синхронизировались, и пользователь сайта №1 мог получать уведомления от сайта №2? То же самое касается чата.
У меня есть 4 сообщества в рамках одного крупного направления, но с разными темами, и я хочу, чтобы эти сообщества были тесно интегрированы друг с другом.

7

Вы можете сделать один сайт сервером аутентификации Discourse Connect, а все остальные будут аутентифицироваться через него.

8

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

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

Я хочу разместить их все на одном сервере (из-за ограничений по IP-адресам у моего провайдера), но по разным URL-адресам, примерно так:

foo.bar.com/team1
foo.bar.com/team2
foo.bar.com/cooking

Также подойдет перенаправление team1.bar.com на foo.bar.com/team1 и так далее, либо использование отдельных виртуальных серверов. (Я знаю, что Apache может это делать, поэтому предполагаю, что nginx тоже, либо напрямую, либо с прокси-сервером перед ним.)

В идеале сам домен foo.bar.com должен служить шлюзом к этим независимым сообществам, объясняя, что это такое и как к ним попасть. Некоторые категории в каждом сообществе могут быть доступны для публичного чтения и индексации веб-краулерами, чтобы они отображались в результатах поиска.

Является ли это настройкой мульти-сайта, мульти-контейнера или чем-то совершенно другим?

9

Есть ли известные подводные камни при разработке плагинов для работы в режиме Multisite?

Похоже, что мой чат-бот не поддерживает режим Multisite (это известная проблема), но я хотел бы понять, почему: в стандартной установке он работает нормально.

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

10

Решил поделиться обновлением о своей ситуации.

После некоторых исследований я решил, что мне нужна настройка для нескольких сайтов (на данном этапе — один контейнер) с внешним сайтом nginx, который будет объяснять конфигурацию и перенаправлять пользователей и трафик на отдельные сайты Discourse. Таким образом, я смогу открыть оба сайта для доступа только на чтение (и для веб-краулеров), не заставляя участников list1 сталкиваться с контентом из list2. Возможно, мне придётся поэкспериментировать с robots.txt, чтобы удовлетворить требования веб-краулеров.

Примеры настройки для нескольких сайтов были полезны, но мне не удалось заставить их работать с unix-сокетом (ошибка шлюза), поэтому я перенаправил их на другой порт, а затем перенаправил этот порт на 443 внутри контейнера.

В моём файле app.yml я включил шаблон SSL, но не шаблон letsencrypt.

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

Я занимаюсь вопросом сертификатов на стороне внешнего сервера, но столкнулся с проблемой «небезопасное соединение», которую решил, потребовав использование HTTPS внутри контейнера. У меня есть задача, которую я буду запускать через cron для копирования последнего сертификата и ключа в директорию /shared/ssl контейнера (как ssl.crt и ssl.key). Не уверен, нужно ли будет принудительно перезагружать nginx внутри контейнера, чтобы убедиться, что новый сертификат загружается при его изменении (в июле, думаю).

Я также столкнулся с одной особенностью Discourse:

В файле /etc/nginx/conf.d/discourse.conf внутри контейнера есть следующий фрагмент кода (доменное имя изменено):

if ($http_host != ‘site1.my.domain’) {
rewrite (.*) https://site1.my.domain$1 permanent
}

Это вызывало перенаправление site2.my.domain на site1.my.domain, поэтому мне пришлось закомментировать этот фрагмент.

ПРИМЕЧАНИЕ: Пересборка контейнера требует повторного выполнения этого редактирования. Есть ли способ этого избежать?

Это также привело к проблеме в браузере: теперь Firefox пометил это перенаправление как постоянное, поэтому мне пришлось очистить кэш браузера. (Мне потребовалось слишком много времени, чтобы это понять!)

Я также обнаружил ещё одну странность.

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