生产升级 - 应遵循的正确流程

支持 安装
1

您好，

我们即将升级生产环境的 Discourse 服务器（我们按照官方安装说明在 EC2 上自建托管），想确认推荐的升级方法。

我们在 UI 中未启用升级按钮，因此升级将在 EC2 实例上手动执行。据我了解，主要有两种方法：

  • 重建我们的 EC2 服务器，拉取 discourse_docker GitHub 仓库的最新副本，并使用其中的模板。例如，当前 web.template.yml 引用的基础镜像为 discourse/base:2.0.20260209-1300。此方法将停止当前运行的服务器并启动新服务器。
  • 登录到现有的 EC2 服务器，执行以下命令以重建当前镜像并重启容器：
    • ./launcher rebuild app

我有两个问题：

  1. 对于常规维护，应采用哪种方法？
  2. 如果执行 rebuild app 命令，是否仍会拉取 discourse_docker 仓库的 main 分支？

我已查阅 https://releases.discourse.org 网站，发现版本 2026.3.0 尚未发布。我的理解是，在生产环境中不应使用处于活跃开发中的主分支最新版本。

非常感谢您的帮助。谢谢。

2

如果你想升级到最新版，那么管理后台手动升级就可以了。
如果想升级到esr版本，只需要在containers/app.yml的最后面指定esr

params:
  version: esr

然后重新构建即可。

请确保网络一切正常。

1 个赞
3

感谢您的回复。

那么，将版本设置为 esr 是否会覆盖模板中使用的基础镜像？

我们不希望在管理 UI 中启用升级功能，因此需要一种在实例中实现此目的的方法，或者简单地重建实例并让 AutoScaler 进行管理。

如果我们使用 esr，当推送关键修复时，它是如何更新的？同样，我们是否只需每月通过启动器/新的 EC2 实例重建，以纳入对 esr 版本的任何更新？

4

您是否阅读过 Understanding Discourse release channels 和 https://meta.discourse.org/t/configure-a-supported-tracking-branch-to-get-discourse-software-updates/17014？我更倾向于将两者的区别描述为：是立即获得最新变更，还是稍后接收。后者对于需要首先进行适配的自定义开发非常有用。否则，我更倾向于获得最新的功能和修复。当然，这存在引入新错误的风险，但三周前冻结的版本也包含错误，这些错误可能已在最新版本中修复，但通常严重性不足以支持向后移植到上一个发布版本。

此外，请记住降级不受支持，因此如果您使用的版本在当前 ESR（延长支持版）之后，您需要等待下一个 ESR 发布。

1 个赞
5

如果您当前使用的是非常旧的版本，在执行启动器命令之前，您可能受益于执行 git pull。

6

啊，我错过了 Configure a supported tracking branch to get Discourse software updates 这篇帖子。

根据目前的回答，我认为我们将使用 release 分支，因为我们会进行月度更新。

非常感谢。

1 个赞