如何在没有短暂不可用的情况下部署新的 cloudfront s3 版本？

Question

我正在使用具有 S3 源的 AWS Cloudfront。我正在使用 webpack 插件使用 chunked hash file names 缓存除 index.html 之外的所有静态文件，我将在每个新版本中使用 cloudfront 功能使其失效。

我计划使用 jenkins 构建来运行 aws s3 sync ./dist s3://BUCKET-NAME/dist --recursive --delete，它将根据需要换出新的分块文件。然后我将覆盖index.html 文件以使用新的分块引用。在将旧文件换成新文件所需的几秒钟（最大）内，用户可能会从云端尚未缓存资源的区域向网站发出请求，此时它们将不可用，因为我刚刚删除了它们。

我找不到任何关于避免这种极端情况的信息。

Answer 1

是的，靠近不同边缘位置的人可能会遇到丢失的文件。为了解决这个问题，您需要更改进行新部署的方法，因为缓存破坏和时间在请求-响应级别是不可预测的。一种常用的模式是为 S3 中的每个新部署保留不同的目录（路径），如下所示。

For release v1.0
/dist/v1.0/js/*
/dist/v1.0/css/*
/dist/index.html <- index.html for v1.0 release which has reference for js & css in /dist/v1.0 path

For release v1.1
/dist/v1.1/js/*
/dist/v1.1/css/*
/dist/index.html <- index.html for v1.1 release which has reference for js & css in /dist/v1.1 path

每次部署后，用户将收到 index.html 的旧版本 (v1.0) 或新版本 (v1.1)，它们在过渡期间仍然有效，直到边缘缓存被破坏。

您可以使用 Jenkins 自动执行版本控制，增加版本或使用 parameterize build plugin。

这对于执行不可变部署也很有用，在出现严重问题的情况下，您可以回滚到以前的部署。除此之外，您还可以配置 S3 生命周期管理规则来归档旧版本。

Answer 2

名为Stout 的库可以自动为您完成这一切。这是一个重要的节省时间。我和他们没有任何关系，我只是很喜欢。

一些好处：

• 如果您愿意，可以帮助您创建新的存储桶
• 版本在每次部署期间您的脚本和样式文件，以确保您的页面在部署期间或之后不会使用不一致的文件集
• 支持回滚到任何以前的版本
• 正确处理 缓存标头，例如 TTL
• 压缩文件以加快交付速度

用法：

stout deploy --bucket my-bucket-name --root path/to/website

Answer 3

这是我解决这个问题的方法。

仅仅删除 flat 并不能解决问题。 由于您已分块散列文件名，我假设您只有 index.html 不是散列文件名。

收集所有需要删除的旧文件

aws s3 ls s3://bucket

部署新版本中的所有文件。

aws s3 cp ./dist s3://bucket

现在使用 mv 或 delete 删除旧文件

aws s3 rm files you collected before except index.html

您的新网站现在将与新应用一起提供。

希望对你有帮助。