Amazon S3 Cloudfront 部署最佳实践

Posted 2023-03-27

【中文标题】Amazon S3 Cloudfront 部署最佳实践

【英文标题】：Amazon S3 Cloudfront Deployment Best Practice

【发布时间】：2011-10-05 13:46:17

【问题描述】：

我们目前的网站计划是使用 Amazon 的 Cloudfront 服务作为资产文件（如 CSS、javascript 和图像）以及任何其他静态文件的 CDN。

我们目前在 S3 中有 1 个存储桶，其中包含所有这些静态文件。这些文件根据它们是什么被分成不同的文件夹，“脚本”是 JS 文件，“图像”是图像，等等 yadda yadda yadda。

所以，我从一开始就没有意识到，一旦您将存储桶从 S3 部署到 Cloudfront 分发版，那么对该存储桶的每个后续更新都不会再次部署到同一个分发版。因此，每次进行静态文件更新时，您似乎都必须将存储桶重新部署到另一个 Cloudfront 实例。

这对于图像来说很好，因为我们可以很容易地确保如果图像发生更改，那么我们只需创建一个新图像。但是，这对于 CSS 和 JS 来说很难做到。

所以，这让我想到了最佳实践问题：

最佳实践是为每个生产部署创建另一个 Cloudfront 发行版吗？这里的问题是会导致 CNAME 记录出现问题。 最好不要在 Cloudfront 中存储 CSS 和 JS，因为这些文件的性质以及它们需要轻松修改？似乎对此的答案是否定的，因为这就是 CDN 的目的。 还有其他一些我不知道的 Cloudfront 方法吗？

【问题讨论】：

您好，您能告诉我您是如何将您的 css 部署到 CDN 的吗？您是如何将 css、js 文件发送到您的 CDN 的？你在用 capistrano 吗？

去使用 cloudflare，它是免费的 :D

【参考方案1】：

您可以向 CloudFront 发出失效请求。

http://docs.amazonwebservices.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html

不过，我们使用自己的服务器作为自定义源，而不是 S3 存储桶。我们有.htaccess 别名style_*.css 到style.css，我们在HTML 中注入style.css 的文件修改时间。由于 CloudFront 看到完全不同的 URL，它会获取新版本。

（注意：一些 CDN 允许您通过查询字符串执行此操作，但 CloudFront 会忽略所有查询字符串数据进行缓存，因此采用了 .htaccess 解决方案。）

编辑： CloudFront 现在可以（可选）配置为使用查询字符串。

【讨论】：

两者都是很好的解决方案，但我认为你的第二个是完美的。在 CDN 之前，我们将“?v=2.0.x”（无论版本号是多少）附加到所有资产 URL 以进行缓存清除，但如果我们使用 CloudFront 将其更改为“stylesheet-v2.0.x.css”服务器作为来源，我认为这会很好。谢谢！

很高兴能帮上忙！在我们明智之前，我们被 CF 丢弃了几次查询字符串所困扰。 :-)

失效对一次可以处理的文件数量有限制，可能会很慢，所以第二种方案肯定更好。

【参考方案2】：

CloudFront 已开始支持查询字符串，您可以使用这些字符串使缓存无效。 http://aws.typepad.com/aws/2012/05/amazon-cloudfront-support-for-dynamic-content.html

【讨论】：

如何，您究竟是使用它来使特定文件上的缓存无效吗？也许它在某个地方的链接中，但不是很清楚。

当您激活查询字符串时，Cloudfront 会缓存每个参数组合的资源。所以你可以附加一个版本。 img.jpg?version=1 和 ?version=2 更多细节请查看手册docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/…