Это лучше, чем DigitalOcean и подобные сервисы, так что да, это хорошо.
Всё работало нормально, но я также указал на ограничения: сайты имели очень низкий трафик и активность. Если вы ожидаете значительной активности на этих сайтах, вам понадобятся дополнительные ресурсы. Использование ресурсов Discourse увеличивается по мере роста активности.
Это действительно зависит от того, нужно ли вам изолировать некоторые сайты от других. Коммерческий хостинг Discourse обычно представляет собой крупные мульти-сайтовые кластеры с дополнительными функциями для поддержки системы биллинга и т. д.
Если у вас нет специальной конфигурации, все сайты будут использовать учётные данные родительского сайта. То есть, если родительский сайт настроен на использование адреса noreply@example.com как адреса для исходящих писем, этот адрес будет использоваться и всеми дочерними сайтами. Вам потребуется дополнительная настройка, если вы хотите уникальные адреса электронной почты для каждого сайта.
В основном это зависит от того, что вы считаете «проблемами».
Использование одного файла app.yaml для мультисайта возможно, но я рекомендую перейти на установку в 2 контейнера (отдельно для веб-части и данных) для мультисайта.
Вам придётся столкнуться с некоторыми сложностями: изменить пути в файлах yml, а затем запустить их. По сути, как если бы /var/discourse-a имел свою собственную конфигурацию, а /var/discourse-b — свою.
Стоит отметить, что это довольно сложные технические концепции. Для организации мульти-сайта вам действительно нужен опыт работы с Discourse и его внутренним устройством. Если вы чувствуете неуверенность, возможно, стоит рассмотреть управляемый хостинг для Discourse или поручить профессиональную настройку кому-то другому. Это значительно снизит ваши головные боли в долгосрочной перспективе. Если у вас есть бюджет, рассмотрите возможность публикации в Marketplace.
Да, но именно поэтому я и говорил, что со временем всегда смогу перейти на более высокий тариф с большим количеством ресурсов. Я никогда не планировал оставаться на этом… тарифе… надолго. Я просто пытаюсь избежать лишних затрат во время тестирования, понимаете?
Можете ли вы указать несколько причин, по которым мне стоит их разделить, кроме ресурсов сервера? На данный момент я не вижу веской причины размещать их на разных серверах, но я всегда готов выслушать разные точки зрения на вещи, которые мне ещё неизвестны.
Это очень интересный момент, о котором я не знал. Похоже, что это действительно делается и работает. Хорошо знать.
Что вы имеете в виду под родительским сайтом? Разве каждая установка не является независимой? Какой из них будет считаться родительским?
Я немного запутался, потому что при просмотре файла app.yaml там есть отдельный раздел для email и учётных данных Brevo. Вы сказали, что могу пойти по пути создания отдельных файлов app.yaml для каждого сообщества. Разве это не означает, что у каждого сообщества будут свои учётные данные Brevo, включая email для уведомлений?
Вещи, которые помешают мне правильно делать резервные копии, или уведомления по email не будут отправляться корректно, и тому подобное. Опять же, как неэксперт, который ещё только знакомится с Discourse, есть вещи, которые другие могут считать проблемой, но я пока их не вижу.
Да, именно это я и планировал. Общим будет только сам сервер. Всё остальное будет работать как отдельная установка, отсюда и мой вопрос выше об email.
Думаю, самые сложные шаги для меня уже были сделаны, когда несколько месяцев назад я глубоко погрузился в установку Discourse. У меня не было никаких знаний об этом. Я даже не знал, что означает «docker». Сейчас у меня гораздо более чёткое представление, хотя я всё ещё считаю себя «базовым пользователем Discourse» в вопросах самостоятельного хостинга. С помощью этого сообщества, а также ChatGPT и Claude, я смог немного больше узнать и сделать заметки о том, как всё работает и устанавливается. Я готов к трудностям, и давайте будем честны: это просто установка программного обеспечения. Я же не собираюсь создавать ядерную бомбу Если что-то пойдёт не так, удалю всё и вернусь к одной установке на сервер. Всё будет хорошо
Как я уже упоминал, у меня уже есть установленное сообщество, поэтому считаю, что самая сложная часть уже позади. Я умею следовать инструкциям и задавать вопросы, поэтому, пробуя новые вещи, я всегда могу остановиться, провести исследование, сделать заметки и так далее.
Моя цель сейчас — больше понять механику процесса, плюсы и минусы, что возможно, а что нет, чтобы принять правильные решения, о которых я не пожалею в будущем и которые не потребуют от меня слишком много времени на исправление ошибок, понимаете?
Так что вся эта информация, которой вы сегодня делитесь, невероятно ценна, потому что даёт мне чёткое представление о том, о чём стоит подумать. Особенно когда вы упомянули, что управляемый хостинг от команды Discourse поддерживает мультисайты. Это действительно заставило меня понять, что это возможно. Возможно, потребуется несколько дополнительных шагов, но всё выполнимо.
Сначала вам нужно решить, хотите ли вы одну мультисайтовую установку или один сервер, на котором размещены несколько независимых сайтов. Я пока воздержусь от ответов на ваши вопросы выше, пока вы не определитесь с выбором между этими вариантами. Есть много нюансов: простое установка Discourse на виртуальную машину не делает вас автоматически готовым к настройке мультисайтовой среды без проблем. Например, мне потребовалось три года, чтобы довести опыт установки мультисайта до совершенства. Признаю, что документация во многом была неясной, и мне пришлось многое выяснять методом проб и ошибок. Я использую Discourse с 2016–2017 годов (на данный момент почти 9–10 лет).
Поэтому, пожалуйста, сделайте шаг назад, ещё раз обдумайте, чего именно вы хотите достичь, и тогда мы сможем сосредоточиться на реализации этой цели.
Ещё раз напоминаю: установка Discourse — это не самое сложное. Впереди ещё много всего нужно изучить, и даже после девяти лет использования и развёртывания Discourse я всё ещё считаю, что каждый день узнаю что-то новое.
Это всегда было моей целью. Для того, что я создаю, я не вижу преимуществ в использовании единой мультисайтовой структуры. Моя цель — просто сэкономить расходы, используя один сервер с независимыми установками.
И я понимаю, что вы имеете в виду под сложностью. Вот почему я говорил, что, хотя мне удалось установить систему и теперь я начинаю понимать некоторые концепции, я считаю себя новичком, когда дело доходит до установки.
После почти 35 лет создания музыки я каждый день узнаю что-то новое, так что это отлично. Я с радостью учусь каждый день и никогда не жду, что это прекратится Вот почему я здесь, в этом сообществе. Чтобы учиться новому вместе с вами.
Итак, если вы просто хотите иметь несколько сайтов Discourse на одном сервере, без общего кода или контейнера, вот что вы можете попробовать:
Внимательно прочитайте app.yml и ознакомьтесь с разделом mounts. Вам понадобятся разные, предсказуемые точки монтирования для каждого сайта. Как минимум, вам придётся вручную отредактировать эти директории.
В единственный раз, когда я это делал (и, думаю, выбрал наименее эргономичный способ), я клонировал код Discourse в две разные директории. Возможно, это и не обязательно, но я не пробовал, поэтому не уверен.
В каждой директории я запускал ./discourse-setup с флагами, чтобы пропустить проверку подключения и пересборку. Это дало мне базовые файлы app.yml. Следующим шагом было вручную отредактировать оба файла: я изменил точки монтирования, закомментировал раздел, экспонирующий порты, и добавил шаблон web.socketed, чтобы мой внешний nginx мог обрабатывать SSL и внутреннюю маршрутизацию.
Затем всё свелось к запуску ./launcher rebuild app в каждой директории.
Честно говоря, мне не очень понравилась такая настройка, и я бросил это дело через несколько месяцев экспериментов. Но это показывает, что то, что вы пытаетесь сделать, действительно осуществимо — просто вам предстоит разобраться в деталях.
Также вам, возможно, стоит уменьшить количество воркеров и т. д., чтобы все сайты имели равные шансы на использование ресурсов, но это уже тема для размышлений, когда вы заложите первоначальный фундамент.
Спасибо за подробную информацию!
Я всё ещё обдумываю лучший вариант, и даже если в итоге выберу этот, мне всё равно предстоит разобраться с некоторыми моментами.
Вы имеете в виду это? Потому что при поиске слова “mount” ничего не нашлось, но я предположил, что это что-то связанное с томами?
Если так, то именно здесь я создаю разные пути, например:
var/discourse/shared/website1
var/discourse/shared/website2
и т. д.
?
То есть по сути вы выполнили обычную установку в одном из путей, например:
var/discourse/shared/website1
затем скопировали эти файлы в
var/discourse/shared/website2
?
Если это так, зачем запускать ./discourse-setup? Разве это не приведёт к перезаписи файлов?
Разве не лучше просто выполнить обычные установки в обоих путях? Как две полностью независимые установки? Для меня, особенно с учётом упомянутых вами “флагов” и прочего, это означало бы больше забот, и, возможно, обычная установка была бы предпочтительнее, а затем ручное редактирование файлов app.yaml в каждом пути?
РЕДАКТИРОВАНИЕ: Неважно. Я провёл исследование и понял, что вы имеете в виду под “клонированием” в данном контексте. Вы клонировали файлы репозитория. Я подумал, что вы сказали, будто установили всё в один “путь”, а затем скопировали эти файлы в другой “путь”.
У вас уже запущен экземпляр Discourse? Вы давно на этом форуме. Вы пытаетесь запустить второй экземпляр на сервере, где уже работает один?
Лучший способ научиться — попробовать самому. Разверните дешёвый VPS и поэкспериментируйте. Если у вас пока нет работающего экземпляра, просто установите стандартную версию с поддержкой сообщества и изучите её. У вас не будет реальных посетителей и необходимости сохранять что-либо. Вы можете просто удалить установку и пробовать снова и снова, пока не освоитесь. Если вы запустите два или даже три экземпляра на одном VPS, и все они будут получать (почти) нулевой трафик, я бы поставил на то, что самый дешёвый доступный VPS справится с этим.
Если у вас получится, опубликуйте инструкцию, чтобы и мы могли чему-то научиться!
Да, у меня он есть. Я хочу установить дополнительные экземпляры.
Поскольку эта установка ещё новая и пользователи ещё не зарегистрировались, проблем с этим нет. Сначала я сделаю резервную копию и попробую всё на этом сервере. Реального риска пока нет.
Конечно, сделаю это. Надеюсь, это поможет другим.
@itsbhanusharma Я задал несколько дополнительных вопросов и ChatGPT, и Claude, потому что подумал, что хотел бы переименовать путь текущего экземпляра с “discourse” на название сайта, например “website-name”. Оба указали на несколько важных моментов. Один из них: поскольку каждой установке требуется 2 ГБ оперативной памяти, если я установлю, например, 5 экземпляров, мне понадобится 10 ГБ, верно?
Если это так, то, вероятно, лучше подойдёт этот план:
Это всё ещё очень выгодная цена для 5 экземпляров, вместо 5 × 5 = 25 .
Как вы думаете, насчёт необходимости выделять 2 ГБ на каждый экземпляр? Это верно в данном случае? Считаете ли вы, что этот план, который я привёл, подойдёт?
У меня было несколько случаев, когда клиенты наносили больше вреда, чем пользы своим сайтам на Discourse, слепо следуя советам ChatGPT.
Это немного сложнее, и такие вопросы не решаются так просто, как сложить 2+2. Именно поэтому в большинстве случаев лучше выбрать путь мультисайта.
Ещё раз: остановитесь, сделайте перерыв, отойдите в сторону и ещё раз обдумайте свои потребности. Здесь, на meta, есть отличные ресурсы, и единственному ИИ-боту, которому я доверяю в вопросах Discourse, является https://ask.discourse.org
Это немного чрезмерно… Никто не слепо следует советам ChatGPT (по крайней мере, не я), поэтому я и веду этот разговор со всеми вами здесь.
Я использую эти инструменты как инструменты. Они упоминают вещи, которые позволяют мне увидеть другие точки зрения, затем я провожу исследования в интернете или задаю вопросы здесь, в сообществе. По пути они также показывают мне другие концепции, не строго связанные с Discourse, что тоже хорошо. Инструменты хороши настолько, насколько хорош человек, который их использует.
И я много сделал, используя советы от ChatGPT и Claude. Мы не можем отвергать всё, что они говорят… слепо
Не могли бы вы рассказать об этом немного подробнее? Если информация от ChatGPT / Claude неточна, может быть, вы сможете просветить меня, а также других, кто, возможно, прочитает это в будущем?
Не для моего случая, по нескольким причинам (и если я что-то упускаю, вот они):
Я хочу иметь возможность вносить индивидуальные изменения, если это необходимо, в каждый экземпляр, не затрагивая другие. Не то чтобы я буду, но я хочу знать, что могу, если захочу.
В мульти-сайте, если родительский сервер падает, все они падают, верно?
Мне просто нравится, когда вещи независимы. Меня беспокоит идея, что 4-5 экземпляров все подключены к чему-то, что может выйти из строя в какой-то момент.
Снова, возможно, мое представление о том, как работает мульти-сайт, ошибочно, но, насколько я понимаю, это не кажется мне подходящим вариантом.
На данный момент мои потребности:
Создать все необходимые мне сообщества
Потратить как можно меньше денег, потому что я не знаю, правильны ли эти решения по созданию этих сообществ в долгосрочной перспективе или нет (было уже такое, больше, чем мне хотелось бы, тратя слишком много денег на «эксперименты»).
Я не знал об этом инструменте, спасибо, что поделились. Добавил в закладки.
Хотя я должен сказать, что мы не должны слепо (извините, мне пришлось сделать это снова, ха-ха) отвергать всё, что говорят ChatGPT или Claude, даже если ИИ-бот Discourse более осведомлен, что я считаю верным, учитывая столько доступного контента по этой теме. Я также использую ChatGPT и Claude, потому что иногда некоторые вещи связаны не только с Discourse, и мне всегда нравится узнавать немного больше о других вещах.
В любом случае, я ценю ваши отзывы и время. Это уже очень помогло мне.
Из того, что я понял, вы уже по уши в излишнем обдумывании своей настройки.
По сути, вам не стоит пытаться реализовать все 1000 гениальных новых идей для сообщества одновременно, разворачивая столько же новых экземпляров Discourse (и, соответственно, любого другого ПО).
Создание сообщества — это итеративный процесс, требующий фокуса. Если вы распылите внимание между более чем одним сообществом одновременно, в итоге на вас ляжет больше задач, чем вы сможете справиться.
Мои предложения были лишь пищей для размышлений. Как я уже упоминал ранее, когда я проводил эти эксперименты, это было именно так: группа друзей, делающих что-то просто потому, что у них есть такая возможность.
Есть причина (или две), почему такие практики не распространены? Они сопряжены со значительными накладными расходами на поддержку и управление, что в будущем вызовет множество головных болей и бессонных ночей. Вы предупреждены.
Учитывая ваши цели, я бы завершил свои слова следующей мыслью: то, чего вы пытаетесь достичь, не невозможно, но сегодня не тот день, чтобы реализовать всё, что вообще возможно. Сосредоточьтесь на том, что у вас есть под рукой, создайте первое сообщество, а остальное последует в своё время.
Что касается обучения через эксперименты: если ваша главная цель — сокращение затрат, то вариант с мультисайтом — лучший путь, несмотря на все компромиссы, которые он влечёт за собой.
Я понимаю, что вы имеете в виду, и поверьте, если бы я создавал все сообщества, необходимые для всех моих проектов, речь шла бы не о 4–5, а скорее о 15.
В итоге я остановился на трёх, которые кажутся действительно важными и которые нужно создать прямо сейчас. На данном этапе всем трём нужно собственное пространство, чтобы пользователи могли обсуждать свой опыт использования продуктов и сервисов, которые я создаю или уже создал.
Как я уже говорил, мультисайт, где всё зависит друг от друга, не кажется мне правильным решением. Честно говоря, головные боли и бессонные ночи, о которых вы упоминаете, скорее всего, возникнут именно в таком случае (по крайней мере, исходя из моего опыта в других сферах, где всё было взаимозависимым) при конфигурации мультисайта. Не знаю… Это один из тех случаев, когда моё интуитивное чувство говорит: «Не делай этого», и я ему доверяю. Возможно, я ошибаюсь, и в процессе это подтвердится, но пока я доверяю своей интуиции в первую очередь.
В любом случае, ещё раз спасибо за ваше время и помощь. Я это очень ценю
Для меня эта тема как раз вовремя, ведь я как раз настраиваю свою систему, чтобы сэкономить время и деньги. У меня есть три небольших частных сайта, трафик на них очень низкий, но они все важны для меня. Кроме того, я хочу иметь возможность быстро разворачивать новые сайты для тестирования идей. Поэтому, думаю, мультисайт меня заинтересует.
Тем не менее, я только что перенёс один из своих сайтов с DigitalOcean на Hetzner и был удивлён экономией. Самый маленький тариф cx23 стоит всего 3,49 доллара в месяц, что идеально подходит для одного небольшого сайта. На DigitalOcean за похожую конфигурацию я платил 15,60 доллара.
Прочитав эту и другие связанные темы, я пришёл к выводу, что главное препятствие для мультисайта — это желание использовать прямую доставку электронной почты для всех моих сайтов, используя доменное имя сайта как домен для почты, чтобы она легко распознавалась и вызывала доверие у участников. Инструкции по настройке этого кажутся не очень понятными.
Поэтому на данный момент я считаю, что мне, возможно, лучше остаться с отдельными сайтами и перенести их все на Hetzner. Я сэкономлю деньги, но не так много времени, учитывая, сколько времени уходит на ручную настройку отдельных сайтов.
Вы можете это сделать, но только если все они используют одинаковые учётные данные SMTP.
Поскольку ваш новый сервер Hetzner намного дешевле, вы всё равно останетесь в выигрыше с тремя сайтами, чем с одним по старой цене.
Я бы не рекомендовал мультисайт с всего 1 ГБ оперативной памяти, да и его настройка вызывает больше проблем, хотя новое переменное окружение для псевдонимов хостов решает одну из самых больших проблем.
У cx23 — 4 ГБ оперативной памяти. Я перемещаю свои два других сайта на отдельные серверы cx23, так что посмотрим, как всё сложится, но я уверен, что всё будет в порядке.
Я не совсем понимаю это утверждение, так как mail-receiver занимается только получением почты, и учётные данные SMTP здесь не требуются.
Вы имеете в виду входящую или исходящую почту? Если речь об исходящей, то разве у каждого сайта не настроены свои учётные данные SMTP в app.yml?
Нет. Mail receiver — это отдельный компонент. Если вы используете multisite, то есть только один файл YML, и именно в нём задаются учётные данные SMTP для отправки. Если же вы используете mail receiver, у вас другая проблема, так как для каждого сайта нужен отдельный mail receiver (по крайней мере, это единственное решение, которое я нашёл).
Если что-то пойдёт не так, удалю всё и вернусь к одной установке на сервер. Всё будет хорошо 
