一个服务器支持两个 Discourse 社区?

它比 DigitalOcean 及其同类产品要好,所以是的,这是一件好事。

还可以,但我也强调了限制,这些网站的流量和活动量都非常低。如果你期望这些网站有大量的活动,你需要更多的资源,随着活动量的增加,Discourse 的资源利用率也会增加。

这真的取决于你是否需要将某些站点与其他站点隔离。商业 Discourse 托管通常只是大型多站点集群,上面有一些特殊的“酱料”来适应它们的计费系统等。

嗯,除非你配置了某些高级设置,否则所有站点将共享 站点的凭据。也就是说,如果没有配置任何高级设置,如果 站点配置了 noreply@example.com 作为其 noreply 电子邮件,它也将被所有 站点使用。如果你想要每个站点都有唯一的电子邮件,你需要一些额外的设置。

很大程度上取决于你如何定义“问题”。

1 个赞

app.yml 用于多站点是可行的,但我建议迁移到 2 容器安装(单独的 Web 和数据)以实现多站点。

您将不得不克服一些挑战,更改 yml 文件中的路径,然后启动它们。本质上就像 /var/discourse-a 有自己的配置,而 /var/discourse-b 有自己的配置一样。

需要指出的是,这些概念技术性很强,您真的需要对 Discourse 及其内部工作原理有一定的经验才能托管多站点。如果您对此感到不安,可以考虑使用托管式 Discourse 托管服务,或请专业人士为您设置。这会大大减轻您日后的烦恼。如果您有预算,可以考虑在 Marketplace(市场)中发帖。

3 个赞

是的,但这就是我所说的,随着时间的推移,我总是可以升级到具有更多资源的更高套餐。我从来没打算长期使用那个……套餐。我只是想在试水的时候避免不必要的开销,你懂吗?

除了服务器资源之外,你能指出一些我想要将它们分开的原因吗?目前,我看不到将它们放在单独服务器上的好理由,但我总是愿意学习一些关于我不了解的事情的不同观点。

这是一个非常有趣的观点,我以前不知道。所以看来这确实是已经做过并且有效的事情。很高兴知道。

你说的站点是什么意思?每个安装不应该是独立的吗?哪个会被认为是站点?

我有点困惑,因为当我查看 app.yaml 文件时,有一个专门用于 Brevo 电子邮件和凭据的部分。你说过我可以选择为每个社区使用单独的 app.yaml 文件。那么,这不意味着每个社区都有自己的 Brevo 凭据,包括通知电子邮件吗?

那些会阻止我正确备份的事情,或者通知邮件无法正常发送之类的事情。再说一次,作为一个非专家,而且对 Discourse 来说还是新手,有些人可能会认为有问题,但我现在还没有看到。

是的,我就是这么想的。唯一共享的就是服务器本身。其他一切都将作为单独的安装运行,因此有了关于电子邮件的问题(如上所述)。

我认为对我来说最具挑战性的步骤已经完成了,那就是几个月前深入研究安装 Discourse。我对它一无所知。我甚至不知道“docker”是什么意思。到目前为止,我的看法更清晰了,尽管在自托管方面我仍然认为自己是“Discourse 基本用户”。在社区和 ChatGPT/Claude 的帮助下,我学到了一些东西,并记录了事物的工作原理和安装方式。我能接受挑战,老实说:这真的只是安装软件。又不是我要制造核弹 :laughing: 如果出了问题,就删除所有内容,回到每台服务器一个安装。一切都好 :slight_smile:

正如我所说,我已经安装了自己的社区,所以我认为最难的部分已经过去了。我擅长遵循说明和提问,所以当我在尝试新事物时,我可以随时暂停并进行研究、做笔记等等。

我现在更关注的是理解它的机制、优缺点、什么是可能的和什么是不可能的,这样我就可以做出一些明智的决定,而不会后悔以后需要花费太多时间来修复问题,你懂吗?

所以,你们今天分享的所有信息都非常有价值,因为它让我对需要考虑的事情有了一个很好的了解。特别是当你提到 Discourse 团队提供的托管服务是多站点的时。这真的让我看到了这是可能的。也许需要多做一些步骤,但一切都可以完成。

非常感谢你们的反馈 :raising_hands:

3 个赞

您首先需要决定您想要一个单一的多站点(multisite)还是一个托管多个独立站点的单一服务器。在您决定选择哪一个之前,我将暂缓回答您上面提出的任何问题。有很多需要理解的地方,仅仅在虚拟机上安装Discourse并不会自动让您免于多站点设置的麻烦,例如,我花了3年时间才为自己完善了多站点安装体验。诚然,文档在很多方面不够清晰,我不得不“自己动手解决”(FTFO,即 figure things the f*** out)很多事情才做对。而且我从2016-17年就开始使用Discourse了(到现在将近9-10年了)。

所以请您退后一步,重新思考您想要实现的目标,然后我们再专注于实现它。

再次提醒,安装Discourse并不是最大的障碍,您仍然有很多东西要学,即使在使用和部署Discourse九年后,我仍然认为自己每天都在学习新东西。

2 个赞

这始终是我的目标。对于我正在构建的内容,我没有看到使用单一多站点有什么优势。我的目标只是通过使用具有独立安装的一台服务器来节省成本。

我理解你说的复杂性。这就是我所说的,尽管我能够安装它并且现在能够理解一些概念,但在安装方面我仍然认为自己是一个基础用户。

在制作音乐近 35 年后,我仍然每天都在学习新事物,所以这没问题。我乐于每天学习,而且我从不期望停止学习 :slight_smile: 这就是我在这里的原因。与大家一起学习新事物。

3 个赞

所以,如果你只是想在同一台服务器上拥有多个 Discourse 站点,而它们不共享代码或容器,你可以尝试以下方法:

仔细阅读 app.yml 并理解 mounts(挂载)部分。每个站点都需要不同、可预测的挂载点,至少你需要手动编辑这些目录。

我上次做这件事时(而且我认为我是以最不符合人体工程学的方式做的),我将 Discourse 代码克隆到了两个不同的目录中,这可能不是必需的,但我没有尝试过,所以不确定。

在每个目录中,我使用一些标志运行了 ./discourse-setup 来跳过连接检查和重建。这为我提供了基线 app.yml 文件。下一步是手动编辑这两个文件,我更改了挂载点,注释掉了暴露端口的部分,并添加了 web.socketed 模板,让我的外部 nginx 负责 SSL 和内部转发。

然后,只需在每个目录中运行 ./launcher rebuild app 即可。

老实说,我不是很喜欢这种设置,所以在玩弄了几个月后就放弃了。但这表明你尝试做的事情确实是可行的,只是你需要自己摸索一下。

你可能还想降低工作进程的数量等,以便所有站点都有公平的机会使用资源,但这在你打下初步基础后再进行思考实验。

3 个赞

感谢您提供的详细信息!
我仍在考虑最佳方案,即使我最终采用此方案,仍有一些问题需要弄清楚。

您指的是这个吗?因为当我搜索“mount”一词时,什么都没有出现,但我假设它与卷(volumes)有关?

如果是这样,那么我是在这里创建不同的路径,例如
var/discourse/shared/website1
var/discourse/shared/website2
等等?

所以基本上您在一个路径中执行了标准安装,例如:
var/discourse/shared/website1
然后将这些文件复制到
var/discourse/shared/website2

如果是这样,为什么要运行 ./discourse-setup?那不会覆盖文件吗?
难道不在两个路径中都执行标准安装会更好吗?就像两次完全独立的安装?对于像我这样的人来说,特别是当您提到“标志”(flags)以及所有这些时,那是我需要担心的更多事情,也许标准安装会更好,然后在每个路径上手动编辑 app.yaml 文件?

编辑:算了。我做了一些研究,明白了您在这种情况下所说的“克隆”是什么意思。您克隆了仓库文件。我以为您是在说您在一个“路径”中安装了所有内容,然后将这些文件复制到另一个“路径”。

您是否已经运行了一个 Discourse 实例?您在这个论坛上待了一段时间了。您是否正试图在一台已经运行了一个实例的服务器上运行第二个实例?

学习的最佳方式是动手尝试。设置一个廉价的 VPS(虚拟专用服务器)并试一试。如果您还没有运行实例,只需设置一个常规的自托管支持安装并熟悉它。您将没有任何真正的访客,也没有理由需要保存任何东西。您可以随时删除安装并反复尝试,直到您掌握为止。如果您设置了两个甚至三个实例都运行在单个 VPS 上,并且它们都几乎没有流量,我敢打赌最便宜的 VPS 也能运行它们。

如果您成功了,请为我们其他人发布一个教程来学习!

1 个赞

是的,我已经运行了一个。我想安装额外的实例。

由于这个安装还是新的,还没有用户注册,所以没有问题。我会先备份它,然后在当前服务器上尝试所有操作。目前还没有真正的风险。

我肯定会这么做的。希望这对其他人有帮助。

@itsbhanusharma 我向 ChatGPT 和 Claude 问了一些额外的问题,因为我正在考虑将当前实例的路径从“discourse”重命名为网站名称,比如“website-name”,它们都指出了几件好事。其中之一是,由于每个安装都需要 2GB 的内存,如果我安装 5 个,例如,我将需要 10GB,对吗?

如果是这样的话,这个计划可能会更好:

CX43Intel ® / AMD
8 VCPU
16 GB RAM
160 GB NVMe SSD
20 TB Traffic incl.
€ 9.49 / month

对于 5 个实例来说,价格仍然非常划算,而不是 $5 x 5 = $25。

您对每个实例需要 2GB 的内存有什么看法?这种情况属实吗?您认为我分享的这个计划是否合适?

请不要这样做!

我遇到过好几起客户因为盲目听从 ChatGPT 的建议而对他们的 Discourse 站点造成更多损害而非益处的事件。

这个问题稍微复杂一些,不是像 2+2 这样可以直接得出答案的事情。这也是为什么采用多站点(multisite)方案是更好主意的主要原因。

我再次建议你停下来,休息一下,退后一步,重新思考你的需求。在这里(meta)有很好的资源可用,而且我唯一信任的关于 Discourse 建议的 AI 机器人是 https://ask.discourse.org

5 个赞

我同意,但请通过阅读机器人提供的来源来核实信息。这样你也能确保它没有编造链接(这种情况确实会发生!)。

6 个赞

这有点太夸张了……没有人是盲目地遵循 ChatGPT 的建议(至少我不是),这就是我在这里和大家进行这次对话的原因。:slight_smile:

我将这些工具用作工具。它们会提到一些能让我看到其他观点的东西,然后我会在网上进行研究,或者在这里向社区提问。在此过程中,它们还会向我展示一些与 Discourse 不完全相关但也有益的其他概念。工具的好坏取决于使用它的人。

而且我利用 ChatGPT 和 Claude 的建议做了很多事情。我们不能盲目地否定他们说的所有话…… :wink:

您能多分享一些关于这方面的信息吗?如果 ChatGPT/Claude 的信息不准确,也许您可以启发我,以及未来可能阅读此帖的其他人?

对我来说不是,有几个原因(除非我理解错了,它们是):

  • 我想能够在每个实例上进行自定义更改(如果需要),而不会影响其他实例。不是说我这样做,而是我想知道如果我这样做,我是可以做到的。
  • 在多站点中,如果主站点崩溃,它们都会崩溃,对吗?
  • 我只是喜欢事物独立。一个想法让我感到困扰,那就是 4-5 个实例都连接到一个可能会在某个时刻出现故障的东西上。

再说一次,也许我对多站点工作方式的看法是错误的,但据我所知,它似乎不适合我。

目前,我的需求是:

  • 建立我需要的所有社区
  • 尽可能少花钱,因为我不知道建立这些社区的决定在长期来看是否明智(我经历过很多次,花的钱比我希望的要多,用于“实验”)。

我不知道这个工具,所以感谢分享。已收藏。
我必须说,即使 Discourse AI 机器人更了解情况(我相信它在主题上有大量内容),我们也不应该盲目地(抱歉,我又来了哈哈)否决 ChatGPT 或 Claude 所说的一切。我也使用 ChatGPT 和 Claude,因为有时某些事情不仅仅与 Discourse 相关,而且我总是喜欢多了解一些其他方面的事情。

无论如何,我感谢您的反馈和时间。它已经帮了我很多。

3 个赞

根据我的理解,你正在过度思考你的设置。

从根本上说,你不应该同时启动尽可能多的 Discourse(以及由此衍生的任何其他软件)实例,来追求你所有的 1000 个绝妙的新社区想法。

社区建设是一个迭代的过程,需要专注,如果你同时分散精力在多个社区上,你最终会承担力所不能及的重担。

我的建议只是供你参考,正如我之前提到的,当我进行这些实验时,它们仅仅是我们一群朋友因为可以而做的事情。

这些做法之所以不常见,是有原因的(或者不止一个)?它们带来了巨大的维护和管理开销,这将在未来导致很多头痛和失眠,你已经被警告了。

鉴于你的目标,我将用以下陈述来总结我的观点:你试图实现的目标并非不可能,但今天不是实现所有可能目标的日子。专注于你手头的事情,建立你的第一个社区,其余的可以在时机成熟时跟进。

至于通过实验来学习,如果降低成本是你的主要目标,那么多站点(multisite)是可行的选择,尽管它会带来所有妥协。

3 个赞

再次感谢您的反馈。

我理解您的意思,相信我,如果我要为我参与的所有事情建立所有我需要的社区,那将不是4-5个,而是15个左右。

我最终确定了3个似乎非常重要并且现在应该建立的社区。在这一点上,这3个都需要自己的空间,以便为用户提供一个讨论他们在使用我拥有或正在构建的产品和服务的体验的地方。

正如我所说,多站点(multisite)并且它们都相互依赖,对我来说感觉不对,老实说,您提到的头痛和失眠,在这种情况下(至少根据我在其他领域相互依赖的事情上的经验)更有可能发生。我不知道……这是一种我的直觉说“不要这样做”的情况,我选择相信它。也许我是错的,随着时间的推移我会证明我是错的,但我首先相信我的直觉。

无论如何,再次感谢您的时间和帮助。非常感谢 :raising_hands:

2 个赞

那么祝您好运,先生!祝您新的冒险一切顺利。

1 个赞

朋友们,新年快乐!

这个话题对我来说非常及时,因为我正在调整我自己的设置,以节省一些时间和金钱。我有三个小型私人网站,它们的流量都非常少,但它们对我都很重要。我也想能够快速启动更多网站来测试新想法。所以多站点(multisite)我想我会感兴趣。

话虽如此,我刚把我的一个网站从 DigitalOcean 迁移到 Hetzner,并对节省的成本感到惊讶。Hetzner 最便宜的 cx23 配置每月仅需 3.49 美元,这对于一个小型网站来说几乎是理想的。我之前在 DigitalOcean 为类似配置支付了 15.60 美元。

在阅读了这篇和其他相关主题后,我对多站点的主要顾虑是,我希望为我的所有网站使用直接邮件发送(direct delivery email),并使用网站的域名作为电子邮件域名,这样网站成员就能轻松识别并信任它。设置它的说明似乎不是很直接。

所以目前我得出的结论是,对我来说最好的办法可能就是坚持使用独立站点(standalone sites),并将它们全部迁移到 Hetzner。我会省钱,但鉴于设置独立站点所花费的时间,节省的时间并不多。

3 个赞

你可以这样做,但前提是它们都使用相同的 SMTP 凭据。

由于你新的 Hetzner 便宜得多,即使有三个站点,你的花费也比按旧费率只使用一个站点要划算。

我不建议使用 1GB 内存的多站点(multisite),而且配置起来更麻烦,尽管新的主机名别名(hostname aliases)环境变量解决了一个最大的问题。

2 个赞

cx23 有 4gb 内存。我将我的另外两个站点迁移到它们各自独立的 cx23 服务器上,看看效果如何,但我感觉会没问题。

我对这一点感到困惑,因为 mail-receiver 只涉及接收电子邮件,而不需要 smtp 凭据。

您说的是接收邮件还是发送邮件?对于发送邮件,难道每个站点不在 app.yml 中配置了自己的 smtp 凭据吗?

3 个赞

不。邮件接收器是分开的。如果你使用的是多站点(multisite),那么只有一个 YML 文件,这就是设置 SMTP 发送凭据的地方。如果你使用的是邮件接收器(mail receiver),那么你遇到了一个不同的问题,因为你需要为每个站点设置一个邮件接收器(至少,这是我找到的唯一解决方案)。

3 个赞