设置一个预发布服务器

设置暂存服务器时,有几种技巧可以提供帮助。

什么是暂存服务器?

暂存服务器本质上是生产站点的克隆。它也驻留在服务器上,并且功能相同。它在 Docker 容器内运行,就像普通的 Discourse 站点一样。

它提供了一个可以尝试风险操作或试用那些不容易向用户隐藏的功能的地方。它对于试用广告(使用 https://meta.discourse.org/t/official-advertising-ad-plugin-for-discourse/33734)或进行论坛导入或合并等有趣的操作非常有用。

这与开发服务器形成对比,开发服务器通常运行在一个易于访问(且已沙盒化)的位置,以便开发人员可以安全地修改代码。

我需要什么?

  1. 标准自托管安装所需的一切

  2. 如果您设置了 S3 备份,您的生活将变得轻松得多

    • 否则,您需要一种通过 SSH 在服务器之间移动大文件的方法

步骤

按需设置您的服务器

通常在 Digital Ocean 上托管的 Ubuntu 虚拟服务器中,但您可以使用任何您熟悉的工具。

安装 Discourse

通过本指南(或可能通过 dashboard.literatecomputing.com)。我建议使用“垃圾邮件”电子邮件凭据(您不需要也不希望电子邮件正常工作)。

discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

确认您的安装正常工作:

建立管理员帐户(如果需要)

从命令行设置一个管理员帐户。这样可以跳过通过电子邮件进行身份验证的需要。

./launcher enter app
rake admin:create

这并非严格必需,除非是为了测试安装,因为您可以从命令行恢复备份。

编辑 app.yml 并进行一些调整

  1. 您可能想复制原始的 app.yml 文件(我称之为 app.vanilla.yml),以便在搞砸时可以恢复到该文件。

  2. env 部分的底部添加以下行:

      ## Staging server specific settings
      DISCOURSE_AUTOMATIC_BACKUPS_ENABLED: false
      DISCOURSE_LOGIN_REQUIRED: true
      DISCOURSE_DISABLE_EMAILS: 'yes'
      DISCOURSE_S3_DISABLE_CLEANUP: true
      DISCOURSE_ALLOW_RESTORE: true
    
  3. 如果您配置了 S3(或类似)备份,请也添加这些(使用主站点的设置)

      ## S3 Configuration
      DISCOURSE_S3_ACCESS_KEY_ID: 'your_key'
      DISCOURSE_S3_SECRET_ACCESS_KEY: 'your_secret'
      DISCOURSE_BACKUP_LOCATION: 's3'
      DISCOURSE_S3_BACKUP_BUCKET: 'your_backups_location'
      DISCOURSE_S3_REGION: 'your_s3_region'
      DISCOURSE_S3_DISABLE_CLEANUP: true
    

    如果您还进行 S3 上传:

      DISCOURSE_ENABLE_S3_UPLOADS: true
      DISCOURSE_S3_UPLOAD_BUCKET: 'your_uploads_location'
    
  4. 您可能还想在暂存服务器上添加与生产服务器相同的插件。

  5. 进行重建

    • ./launcher rebuild app

管理暂存服务器

现在您有了一个连接到 S3 备份(但不会覆盖它们)、易于恢复且在任何情况下都无法向任何人发送电子邮件的暂存服务器。完美!

您可以将新的备份恢复到暂存服务器上,然后随意操作。如果您不喜欢当前的状态,只需再次恢复即可。

关闭或开启

如果您长时间将暂存服务器保持“开启”状态,则有被 Google 索引的风险,并且您的用户可能会意外登录到它。由于他们的凭据是生产站点的克隆,因此这是非常可能的。

缓解这两个问题的简单方法是关闭 Discourse:

./launcher stop app

要重新开启以便使用它:

./launcher restart app

更新

如果您想确保插件和代码保持一致,则必须同时更新/重建暂存服务器和生产服务器。app.yml 更改也是如此。

如果您不使用 S3,则必须在服务器之间手动移动备份。而且它们很大!

填充测试服务器

如果您想要一个暂存服务器,那么您应该通过“恢复”将其填充您实际论坛的实际数据。有时是您特定的数据导致了问题,用其他数据集测试您的论坛可能会给您一种虚假的希望感。

但是,如果您想要一个测试服务器来了解 Discourse 的工作原理,那么您可能想用一些虚假数据进行检查,如果是这样,您可以这样做:

./launcher enter app
ALLOW_DEV_POPULATE=1 bundle install
ALLOW_DEV_POPULATE=1 rake dev:populate

这将用一些虚假数据填充您的论坛,以便您可以查看带有您想要的任何主题和插件的外观。如果您还没有开始您的论坛,这将让您大致了解可能的外观。

管理双因素身份验证

虽然您主站点的帐户用户名/密码在暂存站点上也能正常工作,但对于 2FA 来说就没那么方便了。如果您遇到问题,请关闭 2FA:

./launcher enter app
rake users:disable_2fa[<USERNAME>]
32 个赞

内森,整理这份指南是个好主意。

也许我错过了,但这里的哪个步骤禁用了电子邮件?

5 个赞

好问题。输入无效的 SMTP 凭据可以绝对阻止它,但通过以下方式关闭电子邮件也是有意义的:

DISCOURSE_DISABLE_EMAILS = yes

另外,恢复时会自动启用此设置,因此并非真正必要。

8 个赞

已在 OP 中添加了有关关闭应用的说明。

2 个赞

对了,而且,通常能够获得登录链接会很方便,所以我建议

 DISCOURSE_DISABLE_EMAILS = 'non-staff'
6 个赞

关于创建假用户的一个部分怎么样?一些管理员可能不希望在暂存服务器上有任何个人身份信息。人们在更大规模地创建假用户或删除 PII 时使用了什么?

我想过使用生产环境导入,然后对每个用户运行匿名化任务,但这会导致暂存站点看起来非常单调!

我能建议将 OP 变成一个 Wiki 吗?

一些链接:

https://hackernoon.com/ruby-on-rails-and-the-complexity-of-fake-user-profiles-made-simple-mf4j31gv

我把它做成了一个 wiki。

通常,我希望暂存站点使用与生产站点相同的数据,以便您可以测试在实际数据中是否能正常工作。但也许人们想要虚假数据来了解 Discourse 在开始使用它之前能做什么?(哦,我猜那些链接有一些更复杂的解决方案。)

我猜你可以用一个循环中的 User.create,其中包含来自某处的名字列表。

2 个赞

显然不是我的强项 :slightly_smiling_face:,但这是否是使用 rake dev:populate 的好机会?

cd /var/www/discourse
ALLOW_DEV_POPULATE=1 bundle install
ALLOW_DEV_POPULATE=1 rake dev:populate

我认为这也可以用于更像是暂存环境/测试站点的生产站点。

4 个赞

这似乎不成问题!

这是一个很棒的建议:

任务代码:discourse/populate.rake at 1472e47aae5bfdfb6fd9abfe89beb186c751f514 · discourse/discourse (github.com)

用户特定操作:

1 个赞

太棒了!确实,有人已经考虑过这个问题了!

编辑:为了好玩,我在最近安装的测试站点上试了一下;我粘贴了你的 bundlerake 任务,它做了这个:

root@test2-app:/var/www/discourse# ALLOW_DEV_POPULATE=1 rake dev:populate
OK
I did no detect a custom `config/dev.yml` file, creating one for you where you can amend defaults.
There are 9 group records. Creating 6 more.
......
There are 3 user records. Creating 27 more.
...........................
There are 4 category records. Creating 26 more.
..........................
discourse-solved enabled on category 'Recipes' (12).
Creating 30 sample tag records
..............................
There are 6 topic records. Creating 24 more.
........................
root@test2-app:/var/www/discourse# 

3 个赞

这方面存在一个很大的问题,那就是你的数据集将不再能代表你的真实(live)数据。

暂存服务器需要能够代表真实环境,否则你将无法在计划对生产环境进行任何更改之前测试所有内容。

我曾目睹过一些相当严重的失败案例,这些案例是因为测试数据不具代表性而未能识别出后来在真实环境中出现的问题。这些问题更多时候是由于数据质量问题造成的。

例如,双词姓氏(带或不带连字符)和带音标的字符曾引起了巨大的麻烦。

如果这是一个真正的暂存服务器,那么它就需要精确地模仿真实环境。这些副本不需要对普通用户可见,并且禁用非员工的电子邮件也是相当明智的,但除此之外,这样做只会招致问题。

5 个赞

我同意。我的问题是客户担心在暂存环境中包含真实的客户身份。

理想情况下,我们应该有一个脚本来打乱姓名和电子邮件地址,而保持其他所有内容不变。

1 个赞

听起来这是一次相当直接的对话。如果他们没有代表性的副本,那么他们就没有暂存站点。

如果它的部署和安全性与实时站点相同,那么他们认为的风险是什么?

2 个赞

我和 Stephen 在一起。客户是更担心在暂存网站上有真实数据,还是没有一个实际测试真实数据的暂存网站?

如果你不使用生产环境的实际实时数据进行测试,那么你就不知道当使用实时数据时会发生什么。

而且这个讨论已经离题太远了。 :slight_smile:

2 个赞

我认为应该设置成30天或更长时间后删除帖子。我已将其添加到 OP。有时虚假数据很有用。我们之中最偏执的人(包括我自己)有现实世界的原因,如果暂存服务器没有用您的实际数据进行过测试,就无法信任它。

4 个赞

在对我们的网站实施 2FA 后遇到了一些问题,我添加了以下内容:

1 个赞

哇——太棒了!一气呵成!

导入这些模拟数据后,我感觉效率倍增……突然间,我的测试论坛自动填充了许多用户、帖子、标签、类别和群组……天哪!

非常感谢 @nathank@pfaffman@merefield@JammyDodger@Stephen……天哪!

Happy So Excited GIF

5 个赞

我很想阅读有关如何通过命令行禁用轮询的建议。

最佳方法是设置环境变量 DISCOURSE_POP3_POLLING_ENABLED=false

你需要将整个变量名大写,但我无法在手机上操作。

2 个赞

我最近将我的生产论坛迁移到了 S3 和 CloudFront。我已经有一个已启动并运行的暂存服务器,但它现在与生产环境和 S3 不同步,因为我不确定是否需要单独的存储桶和 CDN 连接——我不太想为暂存服务器额外产生 AWS 费用。假设将两个服务器指向同一个 S3 存储桶不推荐?正确的方法是什么?

1 个赞