☰

使用 CloudFront 进行蓝/绿部署

tag-icon • tag-icon deployment amazon-cloudfront
使用 CloudFront 进行蓝/绿部署

我正在寻找一种使用蓝绿部署的方法CloudFront。

是否有人有从一个 CloudFront 分发转移至另一个 CloudFront 分发的好解决方案，或者每个人实际上只是创建他们的分发然后再也不会触碰它？

我的 CloudFront 分配由一个 S3起源用于静态内容（javascript 等）和指向 AWS ELB 的自定义来源。

CloudFront 没有变化

在正常情况下，我们根本不会对 CloudFront 发行版进行任何更改。我们通过更改 S3 中静态内容文件的名称来对 S3 源中的静态内容进行版本控制，并对 Elastic Load Balancer (ELB) 下的 EC2 实例进行滚动部署。但是，有时我们需要测试并更改 CloudFront 发行版本身，或者对我们的环境进行足够大的更改，以至于我们需要在新环境中指向新的 ELB。

两个 CloudFront 发行版

我尝试的第一个选项是使用两个独立的 CloudFrontWeb 发行版，一个用于我当前的环境（即 A 环境），另一个用于我的新环境（即 B 环境）。我尝试使用 Route53加权路由策略我为我的 www.domain.com Route53 记录添加了两条记录，一条指向 CloudFront 分布 A，权重为 1，另一条指向 CloudFront 分布 B，权重为 0。计划是在我想要从分布 A 移动到分布 B 时更改权重。但是，一次只有一个 CloudFront 分布可以拥有 www.domain.com备用域名 (CNAME)注册或者您收到以下错误：

com.amazonaws.services.cloudfront.model.CNAMEAlreadyExistsException: One or more of the CNAMEs you provided are already associated with a different resource. (Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists; Request ID: ef84a5f0-44e7-11e5-9315-0ba167bb108a)

一个 CloudFront 分配

第二种选择是保留一个 CloudFront Web 分发。我有指向 A 和 B 环境的 S3 和自定义源，然后我更新 CloudFront缓存行为当我想从一个环境移动到另一个环境时，指向另一个源。这非常麻烦，因为这些更新需要 15-60 分钟，无法查看更新进度，并且根据更改的性质，您可能需要跟进CloudFront 失效因此您不会将来自旧环境的缓存内容与新内容一起提供。

谢谢你的建议！

答案1

两个 Cloudfront 发行版

由于 AWS 允许同一 AWS 账户中的通配符备用 CNAME 之间重叠，因此您可以按照以下方式在两个 cloudfront 分布之间切换：

  • 使用 www.domain.com 作为产品分发 1 的备用 CNAME
  • 使用 *.domain.com 作为 Prod 分发 2 的备用 CNAME
  • 将您的 CNAME DNS www.domain.com 指向分布 1 或分布 2。(*.cloudfront.net)。
  • 从分发中删除您不想再提供内容的备用 CNAME。

但是，两个不同的分发 DNS (*.cloudfront.net) 可能指向相同的边缘节点，这意味着提供内容的方式是将 cloudfront.net CNAME 与为其提供服务的边缘节点进行匹配，然后按主机名进行匹配。在这种情况下，如果您的两个分发都使用相同的边缘节点（例如，可以使用 进行检查dig），则切割将不干净。

例如，如果两个发行版共享一个或多个边缘节点，则具有 Alt CNAME www.domain.com 的发行版 1 将优先于具有更通用的 *.domain.com 的发行版 2，直到 CNAME 从所有边缘节点的发行版 1 配置中删除。因此，在过渡期间，从一个请求检索到的版本可能与另一个请求不同。

答案2

有点晚了，但对于其他正在寻找这个的人来说。我相信这可以使用 lambda@edge 来完成。类似于 A/B 测试。 https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html。您可以实现在用户请求 URL 时触发的 lambda 函数。选择从不同的来源或 URL 前缀提供蓝色/绿色内容。cookie 值将确定将提供哪个部署。当第一个请求到达时（没有 cookie），随机设置 cookie，例如 95% 蓝色 5% 绿色。

答案3

随意猜测一下，在云端分布中切换原点需要多长时间？1) 在 ELB 后面部署新代码，预热 2) 将此 ELB 作为新原点添加到云端分布，同时删除旧原点 3) 切换后，拆除旧 ELB 后面的旧代码。

为了避免与 CloudFront 更新或 DNS 更新相关的延迟，您可以交换 ELB 后面的自动缩放组。1) 在新的 ASG 中部署新代码，对其进行预热 2) 使用此新 ASG 注册您现有的 ELB 3) 从您的 ELB 中取消注册旧的 ASG 4) 切换后，拆除旧的 ASG。

答案4

在这篇博文作者根据 AWS 文档中的代码通过 Lambda@Edge 实现了 ab 测试（你可以在这里看到他们的示例：https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html）。

基本上，您要做的就是创建一个指向两个不同来源的 Cloudfront 分布。然后，您可以使用 Lambda@Edge 将流量定向到任一来源（通过 Cookies），当然，您还可以通过 Lambda 实现其他操作，例如加权流量或翻转流量等。添加更多来源和逻辑也很容易。

相关内容