# 带自动缩放的 Discourse 版本控制

**URL:** https://meta.discourse.org/t/discourse-versioning-with-autoscaling/180381
**Category:** Support
**Created:** [2021年二月19日 19:06 UTC](https://meta.discourse.org/t/discourse-versioning-with-autoscaling/180381 "2021-02-19T19:06:49Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![hollyw](https://avatars.discourse-cdn.com/v4/letter/h/4da419/32.png) [@hollyw](https://meta.discourse.org/u/hollyw)
#### Post date: [2021年二月19日 19:06 UTC](https://meta.discourse.org/t/discourse-versioning-with-autoscaling/180381/1 "2021-02-19T19:06:50Z")

</div>

我们知道 Discourse 版本控制的默认/推荐做法是使用 `tests-passed`，但到目前为止，我们的团队一直在 `app.yml` 中明确指定 Discourse 版本，例如 `version: 2.7.0.beta1`。这样做是为了能够明确控制生产环境中部署的版本。

然而，我们从[这个主题](https://meta.discourse.org/t/shallow-git-fetch-regression-in-discourse-docker/172324)中发现了一个 bug，导致我们无法像以往那样指定版本。这给我们的论坛自动扩容带来了问题。例如，假设当前生产环境运行的是 2.7.0.beta1 版本。随后论坛迎来流量激增，我们需要启动另一个实例以进行扩容。如果 `app.yml` 中配置的是 `tests-passed`，且自上次生产更新以来 Discourse 已发布新版本，那么新启动的实例将会是 2.7.0.beta2，这与现有实例产生冲突。这样一来，生产环境中就会同时存在两个不同版本，可能伴随数据库变更及其他兼容性问题，导致生产环境无法正常运行。

此外，我们可能还有其他理由不希望系统以这种方式自动更新，例如插件兼容性问题，以及希望在发布到生产环境之前在测试环境中进行充分测试。

需要注意的是，我们一直尝试让[这个解决方案](https://meta.discourse.org/t/shallow-git-fetch-regression-in-discourse-docker/172324/18)生效，以便能够指定 Discourse 版本，但目前它在 2.7.0.beta3 版本上运行失败。我们遇到了与[此处](https://meta.discourse.org/t/running-launcher-rebuild-causes-bundler-error/99874)类似的 bundler 错误。据我所知，那位用户的解决方案是重新使用 `tests-passed`。

因此，我的问题是：在我们的自动扩容架构下，并且需要明确指定生产环境部署的 Discourse 版本，我们该如何有效地控制 Discourse 的版本？非常希望能听到其他人在类似情况下的经验。

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [2021年二月19日 19:16 UTC](https://meta.discourse.org/t/discourse-versioning-with-autoscaling/180381/2 "2021-02-19T19:16:20Z")

</div>

如果您想使用自动扩展，必须将引导后的镜像推送到容器注册表，并使用该镜像在所有自动扩展实例上运行 Discourse。
