如果能实现这个功能就太棒了……
对于高流量的大型论坛来说，论坛宕机并不是好事，因为每次安装或卸载插件时，我都不得不执行
./launcher rebuild app
这会导致论坛暂时无法访问，让用户感到沮丧。
如果能在管理 GUI 中直接安装/卸载插件并重建/重启 Discourse，那就太好了。
我不认为这是可行的，因为插件是在构建时集成到应用资源中的，尤其是一些插件元素会影响后端。
以下是几种缓解措施：
-
尽可能使用主题组件进行自定义。这些组件可以在线替换和更新。
-
确定一组插件并坚持使用。为什么需要频繁更改配置？
-
如果只需更新插件，请使用在线升级工具。
-
将新插件的添加安排在与核心应用其他根本性变更需要重新构建时进行。
11 个赞
我们唯一能给出的切实建议就是提前规划。没有任何东西可以替代这一点。
使用小型实例来测试和验证您想要进行的任何插件更改，然后每周或每月安排一个时间窗口，将这些更改统一部署到您的生产站点。
这样，您的用户就不会受到此类活动的显著影响，同时您也能大幅降低因兼容性问题导致额外停机的风险。
4 个赞
在多 Web 容器的部署环境中，通过逐个重建/部署 Web 容器，完全可以避免重建期间的停机时间。
5 个赞
很抱歉，@Faizan_Zahid，但这个标题确实可以起得更好。也许你指的是“插件”而不是“Discourse”。我还以为有人是想要从服务器上移除 Discourse 呢；)。
你希望能够在不重新构建的情况下安装/卸载插件。可惜这似乎做不到：confused:
接下来，你可能希望在需要重新构建时尽量减少停机时间。这最近已经是一个讨论话题了：帮助实现“零停机”部署（但讨论并没有朝着应有的方向深入）。
我们这里可能需要一份详细的关于如何设置双 Web 容器部署的教程，以及如何使用它。这看起来是最有效的部署方案（可能也是最复杂的）。我目前没有足够的知识来编写这样的教程，否则我一定会写。有人愿意来做吗？
3 个赞
我计划着手编写一系列针对各种高级用例的简易指南，包括上述内容。这已在待办事项列表中了 
2 个赞
如果您的 Discourse 使用 Docker，您可以使用 Procourse 安装器。
它也会执行重建。
2 个赞
虽然它目前仍可使用，但据我所知，Procourse 已停止服务客户。在没有明确维护路线图的情况下，我会非常谨慎地推荐它。
4 个赞
我之前并不知道这一点。不过，只要 Discourse 的结构没有发生重大变化，它应该能继续正常工作。这里强调的是“应该”。我在想，如果作者已经不再参与这个项目，他是否愿意让其他人接手。
随着时间的推移，所有插件都需要更新。即使是微小的改动，偶尔也会给积极开发的 Discourse 插件带来问题。这是无法预测的，也绝对不是任何人可以依赖的。
一个本身负责管理插件安装却不再维护的插件，是一个非常高风险的选择。依靠乐观态度继续使用它，感觉是一个非常糟糕的主意。
我只接触过两位对此表示兴趣的客户。一旦明确 Procourse 已不复存在，这两位都急于迁移到其他方案。
1 个赞
归根结底，Dev 团队应该考虑将此类功能内置到 Discourse 中，即使出于安全考虑，可以将其设计为命令行中的可切换选项。
据我所知，挑战比这更根本。按目前的方式，该方法根本无法与多站点配合使用。
此外，如果您不小心安装了不兼容的插件，也无法直接卸载它们。这需要 SSH 访问权限。
我已经阅读了关于多站点的问题。其实只需添加一个检查，仅允许非多站点且使用 Docker 的情况即可。
因此，这确实可能需要一些调整。但这确实是他们应该为非多站点安装考虑的问题。
即使将其作为单站点容器的官方插件来采用。
如果您继续阅读该主题的下文，您会看到插件兼容性问题的基本故障排查会变得多么困难。
这只是路线图上需要添加的一项内容。在某些方面，使用 Linux 图形界面安装与命令行安装并无太大差异；不过，确实有一些方案已经实现了良好的效果。
任何时候使用非官方安装方式都存在导致系统崩溃的风险。因此，例如能够像切换主题或主题组件一样启用或禁用某个插件，将是一个理想的功能。
最近遇到一个问题，似乎是分类图标导致了一些故障。即使在使用基本主题且没有其他 CSS 修改或组件的情况下，问题依然存在。排查花费了一些时间。
奇怪的是，在我们单独运行的、搭载最新 Discourse 测试版的测试环境中，该功能却能正常工作。