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文件以使用新的chunked引用。在将旧文件换成新文件所花费的几秒钟（最大值）期间，用户可能会从cloudfront尚未缓存资源的区域向网站发出请求，此时他们可以使用该文件。因为我刚刚删除了它们，所以将不可用。

我找不到任何有关避免这种边缘情况的信息。

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），这些版本在过渡期间仍然有效，直到边缘缓存被终止。< / p>

您可以使用Jenkins自动化版本控制，无论是递增版本还是使用parameterize build plugin。

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

Answer 2

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

删除flat不会解决问题。由于你有分块的哈希文件名，我假设你只有index.html不是哈希文件名。

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

aws s3 ls s3://bucket

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

aws s3 cp ./dist s3://bucket

现在使用mv或删除

删除旧文件

aws s3 rm files you collected before except index.html

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

希望它有所帮助。

Answer 3

名为Stout的库可以自动为您完成所有操作。这是节省时间的主要方法。我和他们没有关系，我真的很喜欢。

一些好处：

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

用法：

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

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

3 个答案: