您好，在安装/更新主题和插件时网站离线是否正常？
1 个赞
重建站点时站点离线是正常的。
解决方案是使用双容器安装，这样可以构建一个新容器，停机时间不到一分钟，或者想办法在站点关闭时显示“我们马上回来”页面，这并不会改变停机时间，但至少大家都会知道你意识到你的站点已关闭。
大家都认为这些解决方案要么太难，要么根本不值得麻烦。
4 个赞
另外，与插件不同的是，安装或更新主题和主题组件不需要停机时间。
4 个赞
您提到的方法有什么文档吗？另外，考虑到它在话语方面非常适合 SEO，但加载时却有中断，导致 Google 机器人无法抓取网站，这似乎有些讽刺。
您预计需要安装新插件多少次？这通常是一个非常罕见的事件。
您可以在线更新插件，服务中断时间极短，因为容器会进行切换。
2 个赞
谢谢您的回复。
1 个赞
When you feel brave, take a look at Add an offline page to display when Discourse is rebuilding or starting up.
2 个赞
你好 
我不确定，也许我错了（我还没有尝试过），但这现在是核心功能了吗？discourse/templates 中有一个几个月前的新模板，名为 offline-page.template.yml，它触发了 https://github.com/discourse/discourse-offline-page。这是 Discourse 加载期间的静态 HTML 站点。在 discourse_docker 中也有一个关于它的 PR FEATURE: add offline page template by featheredtoast · Pull Request #752 · discourse/discourse_docker · GitHub
3 个赞
这似乎只会命中一半？如果我理解重建是正确的话，它会在启动时显示，但不会在重建时显示：
添加一个模板，当 nginx 可用但 rails 不可用时，从 GitHub - discourse/discourse-offline-page: offline page for discourse 拉取和提供静态 HTML 文件。
^ github PR
2 个赞
但是，这是朝着正确方向迈出的一步，感谢 @Don（以及 @featheredtoast ! ）
是的 @Firepup650 我想知道为什么我没看到它，我相信你已经回答了原因！
这里有一些很棒的 
！ 
我想知道这是否是永久标准双容器设置（其中 nginx 容器单独构建）的前奏？！??! 
2 个赞
你抓到我了——有一些正在进行的努力，旨在让离线页面服务更广泛地可用——提到的提交和存储库是为此奠定基础，但目前（还）没有到位。
5 个赞
由于某种原因，我的任何用户在聊天中都看不到“正在重建”。这就是为什么会发生一些用户丢失已写消息的事件。
在我看来，不向已登录用户告知任何停机时间的情况是 Discourse 中最大的单一用户体验问题。当然，我可以理解这是该应用程序的本质所致，而且开发人员从一开始就将自己置于了某种困境（类似于草稿和一些其他情况），但这并不能消除问题本身。
我们有一些变通方法。在 Discourse 前面使用 Nginx 作为反向代理，显示经过调整的错误页面是其中一种。当管理员遇到问题时，答案将是“我们只支持标准的”。这实际上是我放弃它的原因。
两个不同的容器是一个解决方案。或者至少它可以大大缩短停机时间。这方面有太多的警告，所以我有点害怕走这条路。
或者我们可以偶尔升级，提前通知用户并关闭公共访问。是的，这是一个解决方案，但是……现在是 2024 年，在我所在的环境中只有银行系统使用这种方法 
使用暂存服务器是应该做的。嗯，这是一个企业级的解决方案，如果做得好，成本高昂且相当困难，并且需要自己的 IT 团队。
所以新的泄露计划 
确实是一个真正的改进。嗯，如果需要单独的容器，那么我想是时候深入研究了。
1 个赞
这完全一样，只是偶尔也需要重建数据容器。
1 个赞
但是停机时间比20分钟短得多，不是吗？
1 个赞
聊天内容可能与常规网站浏览有所不同，因为我认为它更像是实时访问，而不是能够缓存页面。
同意。我认为计划中的公告维护最好是像早期基于 DOS 的拨号 BBS 那样。当时有一个选项可以显示系统消息，警告计划中的维护关机即将到来，并将在指定时间注销用户。在那些日子里，这通常是为了在联网的 BBS 之间进行邮件包传输。
1 个赞
是的。停机时间通常不到一分钟，但您需要足够的内存或交换空间来在构建一个容器的同时构建另一个容器。
1 个赞