同意，这些说明确实需要调整。数据部分不再起作用似乎很奇怪。
每年都有一次较长的停机时间也不是什么大问题……
没有，除了我错误地编辑了 web_only.yml 并使用了现有的 app.yml 配置所造成的问题外，没有其他问题。
1 个赞
很高兴地报告，对于这个双容器设置，现在它似乎可以正常工作了！
唯一剩下的问题是用于告知您如何从命令行（“app”）重建的网站文本，但这只是一个小问题。
抄送：@pfaffman
是的，那是硬编码的。如果您不记得了，则需要自定义文本。
1 个赞
5 个帖子被拆分到新主题：Build fails due to ruby version mismatch
那永远行不通。抱歉我之前错过了。我已经更新了 OP。如果你需要重建数据，那么你需要
./launcher stop web_only; ./launcher rebuild data && ./launcher rebuild web_only
没有。这正是预期的。你不能在另一个 postgres 访问文件时重建 postgres。如果创建了一个新的数据容器，你需要销毁并启动一个新的 web_only 容器，因为 docker 某种程度上链接到确切的容器而不是对名为 data 的容器的引用。
1 个赞
感谢 OP 的编辑 
以及在 Build fails due to ruby version mismatch 中的帮助
1 个赞
我是疯了吗，还是 discourse-install 脚本不再包含 –two-container 参数了？我直接从推荐位置（https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse）在一个全新的 Ubuntu 24.04 VPS（在 Hetzner 上）上运行它，它只安装了一个常规的单容器设置，带有一个 app.yml。我以为也许我需要运行它生成的 discourse-setup，但它又做了同样的事情。
使用手动安装方法和 ./discourse-setup --two-container 在我上次使用时对我来说运行良好。
或者使用巧妙的安装脚本进行安装，然后如原帖（OP）中所述转换为两个容器。
@Falco 和 @pmusaraj 你们认为是否应该将旧的 INSTALL-cloud.md 的部分内容保留在某处，并在当前的 INSTALL-cloud.md 中引用？
1 个赞
它确实被移除了，我已经从上面的 wiki 中删除了相关引用。
感谢您的信息。它为什么被移除了？它曾是一个非常方便的方法。
由不熟悉 Docker 的人进行的两次容器安装产生了过多的支持负担。这是一个高级安装设置，应该留给那些了解其操作的人。
1 个赞
所以你们让使用该功能的人感到困难。你们事先有征求过任何人的意见吗？考虑到即使有人错误地使用 OP 方法也会给自己带来一些问题，你们本可以保留它。
谁的负担？在这个帖子里？支持是由志愿者/用户提供的，而不是团队提供的。
1 个赞
那么您会把 web_only 和 data 保留在 samples 中，而想要使用两个容器的人将不得不手动复制和配置它们？之前唯一需要的额外支持是帮助那些从不关心更新数据容器的人。
现在我们需要告诉一堆人如何使用 cp 和 nano。可以说，如果你不知道 cp 和 nano，你就不应该运行双容器设置。Jeff 曾争辩说，如果你不知道 cp 和 nano，你就不应该安装 Discourse，但当我编写 discourse-setup 时，我成功地改变了他的想法。
在接下来的时间里，我将重写我的 dashboard.literatecomputing.com，使其停止进行标准安装（因为它不能再将答案通过管道传输到 discourse-setup 中），并将在那里继续提供双容器安装作为选项。
4 个赞
我不太喜欢。这感觉像是离完全放弃对双容器的支持又近了一步，那将是一件非常遗憾的事情。
5 个赞
这就是开源的伟大之处；人们可以选择自己的冒险！
数十个运行着被完全遗忘的过时容器的人，每次 PostgreSQL 需要进行重大更新时都会造成很多困惑，这反过来又减少了我们进行 PostgreSQL 更新的频率，从而使整体产品变差。
我同意 
实际上不可能放弃对双（或 N）容器安装的支持；Discourse 原生连接到外部数据库，如 Configure Discourse to use a separate PostgreSQL server 中所述。
没有删除任何灵活性，但类似于 https://blog.codinghorror.com/the-power-of-defaults/，我们创建的每个选项都成为需要考虑的事情。
删除数千行脚本并简化安装程序以覆盖更常见的使用场景是一个有意识的选择，但 Discourse 仍然支持所有相同的用例，并且如果人们选择，他们可以自由地选择自己的道路。
2 个赞
感谢您保证这种生产模式在没有大量定制的情况下仍能继续运作 
1 个赞
为了强制所有人都遵循一条路径，牺牲了使用被移除方法的用户的便利性。这是一个人做的决定，还是有其他人参与？
来自 codinghorror
“默认设置可以说是您作为软件开发人员所做的最重要设计决策。选择好的默认设置，用户会赞扬您的软件以及它有多么易于使用。选择糟糕的默认设置，您将不得不面对用户的配置焦虑，可能还有一堆技术支持电话。”
依我看，选择的默认设置很糟糕，而且这个选择/更改是在没有与抱怨此更改的用户群体进行任何参与、讨论或考虑的情况下做出的。
再次询问，这是谁的有意识的选择？
该用户认为这条评论是傲慢和不尊重的。这感觉就像一个人被看不起和无视时会有的感觉。我怀疑意图是引起这种反应，但现在我们就在这里。
总的来说，这个事件与我几周前在与 @nat 的私人消息中抱怨的内容一致。CDCK/Meta 有两个不平等的客户群体：付费托管的客户和自托管的用户。这个事件中的处理方式是这个两级制度的最新、也许是最过分的例子。
尽管说了这么多……
我赞扬新的安装程序。它在处理安装问题和由此产生的自第一天以来的支持需求方面做得很好。
至于更改，CDCK 有权按其认为合适的方式构建/更改。对此没有异议。我希望他们能以一种不会疏远人们的方式进行操作。
最后，重读 codinghorror 的帖子让我想起了 Jeff 参与帖子时的情况。他的帖子经常带有轻蔑、不尊重和轻微傲慢的味道。幸运的是，我从未成为那种态度的直接目标，但其中一些帖子读起来很痛苦。我最近与工作人员就如何处理帖子进行的互动以及这个事件感觉非常相似。也许只是我自己的感觉。
这听起来有点苛刻。团队每天都在这个论坛上帮助自托管用户，即使是那些属于 unsupported-install 的用户 
4 个赞