为上传配置与 S3 兼容的对象存储提供商

文档 自我托管
, , ,
415

@Falco - 最好为 Scaleway 添加一个警告，说明它仅支持 1,000 个分片进行分片上传，而 AWS 支持 10,000 个。这对于常规上传不是问题，但对于超过一定大小的备份上传来说却是个问题，因为 S3 SDK 将使用 10,000 个分片，除非手动修改，否则会失败。

4 个赞
416

太棒了！如果可以的话，请将其添加到 OP wiki 中。

4 个赞
417

谢谢，另外我想补充的是，您可以使用以下任何工具将数据从云复制到云，特别是复制到/从 S3 兼容对象存储，例如 Rclone、Shargate、Gs Richcopy360 和 GoodSync。所有这些都与类似的云兼容。

1 个赞
418

我们刚刚发现了一个问题，Cloudflare R2 不允许从 S3 端点 URL 进行公共读取，而只允许自定义域名或随机的 r2.dev 域名。
（预签名下载可以工作，只是不支持直接公共访问。）
但是 Discourse 只为嵌入式图像使用 CDN URL，而不为使用 S3 端点 URL 的直接下载使用。
有没有办法让它为所有文件使用 CDN URL，或者强制使用预签名 URL？

相关：

该帖子中提到的解决方法有效，添加 ?dl=1 可以解决此问题，因为它强制 Discourse 使用预签名的 S3 URL。

1 个赞
419

已在 2023-03-16 中修复，现在 R2 配合 Discourse 免费套餐运行得非常顺畅。

3 个赞
420

我也经常（每隔几个月）遇到这种情况，尽管我的 Discourse 运行在 AWS Lightsail 上，并且我正在上传到 AWS S3。所以我不确定这是否是 wasabi 的问题。

是否有可能捕获此错误并通知管理员？我确实会检查磁盘空间并在升级时删除旧备份，但有时为时已晚，论坛会因为磁盘空间不足而宕机。

1 个赞
Notification when uploading backup to cloud storage fails
421

我相当确定问题在于安全更新的自动操作系统重启发生在备份运行时。请确保您安排操作系统重启和备份在不同的时间进行。我是在将该网站从 wasabi 迁移出来之后才想出这个解释的，但我很确定就是这个原因。

2 个赞
422

uptime 显示已运行 300 天，所以我认为那不是问题。但类似地，我在凌晨 2 点安排了 Discourse 备份，在凌晨 2:30 安排了 Lightsail 快照，所以也许上传有时未完成，快照会干扰它。我已将这两个操作分开一小时——我们拭目以待它是否会产生影响。

无论如何，我认为如果上传因任何原因失败，都应该向管理员发出警告是合理的。

2 个赞
423

是时候进行内核升级并重启了。 :slight_smile:

您是不是内存快用完了？

424

实施远程 Backblaze 备份后，我在仪表板中看到此错误：

服务器配置为将文件上传到 S3，但未配置 S3 CDN。这可能导致高昂的 S3 成本和较慢的网站性能。请参阅“使用对象存储进行上传”了解更多信息。

我没有配置文件的上传，我只通过以下配置配置了备份：

DISCOURSE_S3_REGION: "s3.us-west-00X"
DISCOURSE_S3_INSTALL_CORS_RULE: false
DISCOURSE_S3_ENDPOINT: https://s3.us-west-00X.backblazeb2.com
DISCOURSE_S3_ACCESS_KEY_ID: mykeyid
DISCOURSE_S3_SECRET_ACCESS_KEY: myaccesskey
DISCOURSE_S3_BUCKET: community-forum
DISCOURSE_S3_BACKUP_BUCKET: community-forum/backups
DISCOURSE_BACKUP_LOCATION: s3

我是否做错了什么？

似乎有些配置错误，我注意到当我尝试将文件上传到帖子时，我收到了此错误：

罐装 ACL ‘public-read’ 的值不受支持

如果您能提供任何帮助，我将不胜感激。

2 个赞
425

如果您不希望上传到 s3，请删除此项。

4 个赞
426

哥们，你帮了大忙。:+1:t3: 非常感谢！

2 个赞
427

这样做有效吗？

1 个赞
428

自从我将两个进程分开一小时以来，上个月发生了一次，所以它没有“修复”它，而且它发生的频率不够高，无法判断它是否有帮助。

从好的方面来看，我注意到管理页面上有一个备份状态部分，显示可用磁盘空间，这使我不必一直打开终端并执行 df 来检查卡住的备份。我自定义了文本，提醒自己预计有 80 GB 的可用空间。

image
image282×203 2.86 KB

1 个赞
429

这是个好主意。

在我读到你自定义了文本之前，我看到了这张图片，当时就在想，是什么逻辑判断出这是“好的”！

1 个赞
430

我无法使用 Scaleway 和 Bitnami Discourse 镜像来完成此操作。
环境变量已设置，但显然没有被正确读取/应用（或者根本没有？）。

因此，我在管理员面板中设置了 S3 变量，并在 rails 控制台中直接设置了区域（仍然希望这只是一个文本字段）：
SiteSetting.s3_region="fr-par"

这给了我一个验证错误，但在更新设置之前，我只是注释掉了验证检查，然后又将其放了回去。

1 个赞
431

Bitnami 镜像不是由我们打包的，也不遵循我们的建议。此处记录的所有内容仅针对官方安装进行了测试。

4 个赞
432

这已通过启用“s3 use cdn url for all uploads”得到解决，这是 discourse 最近添加的一个选项。
由于我们之前使用的是 R2，因此我们需要使用 discourse remap 手动替换损坏的链接，并同步 s3 文件以防万一，然后我们重新烘焙了所有帖子。

1 个赞
434

我正在尝试使用 idrive e2 进行设置，它是 s3 兼容的。但是，在 ./launcher rebuild app 的末尾，我收到了一条非常有帮助的错误/堆栈跟踪：

I, [2023-10-14T15:08:08.026184 #1]  INFO -- : cd /var/www/discourse & sudo -E -u discourse bundle exec rake s3:upload_assets
rake aborted!
Aws::S3::Errors::InternalError: 我们遇到了内部错误，请重试。
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/dualstack.rb:27:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/accelerate.rb:56:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/checksum_algorithm.rb:111:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:22:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/idempotency_token.rb:19:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/param_converter.rb:26:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/request_callback.rb:71:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/response_paging.rb:12:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/response_target.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/request.rb:72:in `send_request'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/client.rb:12369:in `put_object'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/object.rb:1472:in `put'
/var/www/discourse/lib/s3_helper.rb:78:in `upload'
/var/www/discourse/lib/tasks/s3.rake:41:in `block in upload'
/var/www/discourse/lib/tasks/s3.rake:41:in `open'
/var/www/discourse/lib/tasks/s3.rake:41:in `upload'
/var/www/discourse/lib/tasks/s3.rake:197:in `block (2 levels) in <main>'
/var/www/discourse/lib/tasks/s3.rake:197:in `each'
/var/www/discourse/lib/tasks/s3.rake:197:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => s3:upload_assets
(See full trace by running task with --trace)
I, [2023-10-14T15:08:16.413098 #1]  INFO -- : Installing CORS rules...
skipping
Uploading: assets/admin-2ebebf57104b0beb47a1c82fe5a8c6decd07f60a706640345fed296a094d1536.js

这是我一直在使用的配置，但我也尝试过使用 DISCOURSE_S3_CONFIGURE_TOMBSTONE_POLICY 和 DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: Dallas
  DISCOURSE_S3_ENDPOINT: https://y0o9.tx21.idrivee2-4.com
  DISCOURSE_S3_ACCESS_KEY_ID: <snip>
  DISCOURSE_S3_SECRET_ACCESS_KEY: <snip>
  DISCOURSE_S3_BUCKET: discourse
  DISCOURSE_S3_INSTALL_CORS_RULE: false

请注意，我没有将其用于备份（这已经在 UI 中使用 backblaze 设置好了），也没有使用 DISCOURSE_CDN_URL，因为我不确定 idrive 是否支持该功能——我计划在将实际文件放入存储桶后进行实验。

1 个赞
435

它似乎与 S3 的兼容性不足，无法满足 Discourse 的需求。

如果您想进一步研究，下一步是在开发环境中重现此问题，并找出失败的确切 API 调用。

2 个赞