CloudFront的蓝色/绿色部署

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

有没有人有一个很好的解决方案，可以从一个CloudFront发行版迁移到另一个，或者每个人真的只是在创建他们的发行版，然后再也没有碰过它吗？

我的CloudFront发行版包含一个用于静态内容（JavaScript等）的S3 源和一个指向AWS ELB的自定义源。

CloudFront不变

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

两个CloudFront发行版

我尝试的第一个选项是拥有两个单独的CloudFront Web发行版，一个用于我当前的环境，即A环境，另一个用于我的新环境，即B环境。我尝试使用Route53 加权路由策略，在其中为我的www.domain.com Route53记录添加了两个记录，一个记录指向权重为1的CloudFront分布A，另一个指向权重为0的CloudFront分布B。我想从分配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 Invalidation进行后续操作，以便不提供缓存的内容来自旧环境以及新内容。

谢谢你的建议！

两个Cloudfront发行版

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

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

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

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

这里的游戏有点晚，但对于其他任何人来说都是这样。我相信可以使用lambda @ edge来完成。类似于A / B测试。 https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html。您可以实现当用户请求url时触发的lambda函数。选择提供来自不同来源或网址前缀的蓝色/绿色内容。Cookie值将确定将提供哪个部署。当第一个请求到达时（没有cookie），将cookie随机设置为95％蓝色5％绿色。

从臀部射击，在云锋分布内切换原点需要多长时间？1）在ELB后面部署新代码，对其进行预热2）将这个ELB作为新的原点添加到您的云前端分布中，同时删除旧的原点3）一旦转换，将旧的代码分解到旧的ELB后面。

为了摆脱与CloudFront更新或DNS更新相关的延迟，您可以在ELB后面交换自动伸缩组。1）在新的ASG中部署新代码，进行预热2）在此新的ASG中注册您现有的ELB 3）从您的ELB中注销旧的ASG 4）转换后，拆除旧的ASG。

我也一直在研究这个主题，并且有一个变通方法（见下文）。

背景：

CloudFront要求分发配置中的CNAME在整个帐户中必须唯一。因此，无法通过DNS控制蓝色/绿色到不同的发行版。有种破解方法会使用通配符，但不能保证会提供正确的文件。通过DNS和CloudFront控制蓝色/绿色是不可行的。

此外，在CloudFront（包括CNAME）中更改任何配置都会导致15-60分钟的等待，同时更改会传播到边缘服务器。另外，也不是理想的设置。

解决：

对于单页应用程序，此配置可以解决问题：

• 应用程式网址：app.mydomain.com/app
• S3结构：
  • 应用程序/（您的实时网站）
  • app2 /（您的网站不太活跃）

现在将CloudFront配置为使用您的存储桶来提供文件。此时，一切都取决于您的缓存设置。由于CloudFront永远占用时间，因此请在我们的S3对象上设置CacheControl标头。对于index.html，我们用5分钟，其他时间都是1天。切换时，请交换S3目录名称。在5分钟内，该应用程序便可以用于所有意图和目的。

对于已经运行的应用程序，我们在代码中内置了构建版本，并且在应用程序的根目录上具有构建配置json文件。然后，应用有时会请求json文件，检查版本，如果版本过旧，则提示刷新。

局限性

您不能很好地执行浸泡测试。我想可以将index.html的TTL增加到几个小时或几天（取决于您的需要），这将有助于确保客户端在其本地缓存到期时将获得新版本。

在这篇博客文章中，作者通过Lambda @ Edge实施了AWS测试，以处理AWS文档中的代码（您可以在此处查看其示例：https : //docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda- examples.html）。

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