你好！
我无法弄清楚为什么在最新的更新中，我们的安装停止从 CDN 提供资源。我们使用的是 Cloudfront，之前它一直能很好地提供上传文件和资源，但看起来在最新的更新中，资源改由服务器提供。
我们遇到的另一个问题是，如果我们传递变量 DISCOURSE_CDN_URL，Discourse 开始请求那些并非由 s3:upload_assets 任务生成或上传的资源（例如样式表）。这会导致网站完全崩溃，显示为空白页面。这篇帖子提到了类似的情况。
任何帮助都将不胜感激。
谢谢！
1 个赞
这是 @falco 出现的新 bug 吗？我们在这里是不是破坏了什么？
2 个赞
@eatcodetravel 我们需要更多详细信息才能为您提供帮助。
与 S3 和 CDN 相关的设置和环境变量的确切值是什么？
1 个赞
@Falco 没问题，您需要哪些信息？我们的配置是开源的，以下是我们当前运行的设置：
- web.yml 容器模板 infra/modules/services/discourse/web.yml at master · debtcollective/infra · GitHub
- settings.yml - 我们在首次运行时应用此文件 infra/modules/services/discourse/settings.yml at master · debtcollective/infra · GitHub
- ec2 实例配置 infra/modules/services/discourse/cloud-config.yml at master · debtcollective/infra · GitHub
我移除了 DISCOURSE_CDN_URL，它之前被设置为与 DISCOURSE_S3_CDN_URL 相同的值，这导致网站出错（因为它试图拉取 S3 上不存在的资源）。
回顾我之前遇到问题的网站，我发现我在使用的 CDN URL 中漏掉了 https://。我不清楚它之前是如何工作的，或者如果它从未正常工作过，为什么我在添加这个错误值时没有注意到。
@eatcodetravel，你当然需要删除 SMTP 密码和 S3 密钥，但我觉得你需要至少分享 CDN 相关的值，这样别人才有可能猜测问题出在哪里。
好的，让我把这些写在这里。我认为只需要设置 CDN_URL，因为其他项已通过 AWS SDK 进行验证。
DISCOURSE_S3_CDN_URL: 'https://community-cdn-prod.debtcollective.org'
DISCOURSE_S3_REGION: 'us-west-1'
在我移除之前，DISCOURSE_CDN_URL 也曾设置为 ‘https://community-cdn-prod.debtcollective.org’。
我们的配置没有发生重大变化，只是迁移到了更大的 EC2 实例。
另外，如果你需要更多信息，请告诉我 @Falco，我很乐意回答你的问题。
所以您当前使用的是 S3 CDN，而不是普通的 CDN。我不确定这种配置是否受支持……
其他三种组合肯定可以正常工作：
- 不使用 CDN
- 仅使用
DISCOURSE_CDN_URL - 同时使用
DISCOURSE_CDN_URL和DISCOURSE_S3_CDN_URL。
3 个赞
我想这或许能解释我过去遇到的其他 CDN 问题。
2 个赞
是的，我不得不移除 DISCOURSE_CDN_URL，因为它开始请求那些并未通过 rake s3:upload_assets 任务上传到 S3 的资源，这导致网站完全无法运行。也许这是发生变化的部分，我们需要更新 rake s3:upload_assets 使其再次正常工作。
是的，可以为 DISCOURSE_CDN_URL 和 DISCOURSE_S3_CDN_URL 使用相同的 CDN URL，但这需要在 CDN 中进行大量登录配置，以便根据 URL 为每个资源使用正确的源。例如，CSS 来自应用，JS 来自 S3，而这只是一个案例，我们还有几十种类似的情况。
因此，预期的做法是同时设置两者：DISCOURSE_CDN_URL 作为您 Web 应用的“代理”，而 DISCOURSE_S3_CDN_URL 作为您对象存储桶的代理。
2 个赞
好的，这是最近才变化的吗？我不确定 CloudFront 是否支持作为我们应用的反向代理，而不是作为 S3 存储桶。
我看到你在 meta 中使用了 CloudFront，你们有什么特别的操作吗？还是 Discourse 本身会自动处理所有事情？
如果您检查此页面，会发现我们有两个不同的 Cloudfront URL。正如我之前所说，我们使用了两个分发：一个用于普通 CDN，另一个用于 S3。
标题中 OP 提到的问题是：CSS 来自应用，而 JS 来自 S3。您需要一个能够感知每个资源来源并能够访问相应位置的 CDN，或者使用两个 CDN。这就是为什么我们最终会有两套不同的配置。
1 个赞
虽然我现在理解了这完全合理，但我不确定是否有相关文档说明。而且你可能会遇到问题（至少我就遇到过！），因为将上传内容迁移到 S3 的 rake 任务要求你必须配置 s3_cdn。这也解释了我为什么多次尝试将内容迁移到 S3 却最终不得不放弃。
我觉得最好能在某个地方添加一条提示：“嘿，如果没有配置资源 CDN，就不能使用 S3 CDN。”
1 个赞
好的，现在我明白你的意思了，之前不知道这是必需的。请问为什么 CSS 必须来自应用？我们为什么不能通过 rake s3:upload_assets 任务来上传呢？
我会研究一下如何在 Cloudfront 上实现这一点，并将我的发现或遇到的阻碍更新在这里。
感谢 @Falco，这真的很有帮助。
好吧，我可能没解释清楚。技术上是可以的，但这会很麻烦，正如你的帖子以及这个帖子所展示的那样。
@eatcodetravel 的网站目前仅设置了 S3_CDN 就能运行，但随后会进入一种奇怪的状态：阻塞渲染的 CSS 文件仍由你的服务器提供，而帖子中的图片却没有，这毫无意义。
因为“管理 > 自定义”功能的存在。用户可以在管理面板中修改 CSS。此外，据我所知，托管在主题中的自定义 JS 片段也是由应用服务器提供的。
4 个赞
我们能否以某种方式更好地记录这一点，@falco？甚至可以用“此处有 
”的方式标注？
6 个赞
我最终通过提供第二个指向 Web 服务器的 CloudFront 分发来解决这个问题，而保留另一个仅用于 S3。感谢 @Falco 的反馈，但我同意这一点需要更好地记录。
9 个赞
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.