Amazon CloudFront 是一种快速的内容分发网络 (CDN) 服务，可以在开发人员友好环境中以低延迟和高传输速度向全球客户安全分发数据、视频、应用程序和 API。在本篇博客文章中，您将学会如何使用 CloudFront 持续部署(Continuous deployment),
进行蓝绿部署/变更验证，进而根据业务高可用需求。
持续部署(Continuous deployment)示意图：
以下我们将分为几个部分进行功能讲解：
概念解析
环境准备
部署过程
配置验证及监控
注意事项
01
概念解析
通过使用 Amazon CloudFront 的持续部署，您可以灰度一部分生产流量至变更配置(Staging Distribution)来安全地部署对
CDN 配置的更改。
工作流程：
为了便于您使用 CloudFront 持续部署，下面对部署过程中所涉及的概念进行解释：
1. Primary Distribution：需要进行配置变更的 Distribution。
2. Staging Distribution：在启用持续部署功能的过程中，CloudFront 将单独创建一个 Staging
Distribution 配置，所有的配置变更将保存在 Staging Distribution 当中，在未进行Promote前，不影响Primary
Distribution。
3. Policy：您需要使用的流量策略，在持续部署中，您可以根据实际需求，使用两种方式中的其中一种进行流量灰度：
▪ 基于百分比(Weight-Based)将一部分流量进行引导至 Staging Distribution 中;
▪ 指定携带特定请求头的请求(Header-based)引导至 Staging Distribution 中。
基于百分比(Weight-based)：最高可指定至15%的生产流量引导至 Staging
Distribution，为了满足某些特定场景需要一部分用户固定访问至变更前或变更后的配置，基于百分比的 policy 支持 session
stickness，session stickness 的时间可指定，最大可调的 idle TTL 为1小时。需要注意的是，在 session
stickness 中，最大的 TTL(Maximum TTL)也是1小时，当启用 session stickness 时，无论您设置的 idle TTL
为多少，当一个用户的会话达到1小时时，将重新进入 Policy 环节进行 Weight-based 选择。
基于请求头(Header-based)：请求头名字格式需以 aws-cf-cd- 作为开头，比如 aws-cf-cd-jwtest 。
4. Promote：将 Staging Distribution 所保存的变更，下发至 Primary Distribution 中。
02
环境准备
我们基于部署小指南(二)的整体架构，来进行部署过程的演示：
需求是我们需将客户端 IP 通过 CloudFront Function 添加至自定义的请求头 True-Client-IP
中，并携带回源，我们可以使用官方示例代码来进行 CloudFront Function 的部署，您可在 CloudFront Console 的左侧找到
CloudFront Function 入口：
选择创建一个 function
为您的 function 命名并继续
将官方示例代码复制粘贴至代码框中，保存并继续
示例代码：
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/example-function-add-true-client-ip-header.html
我们来到 Test 标签，先进行代码逻辑的调试，查看输出结果是否符合预期
在下方的执行结果中，我们可以看到执行成功，并且 request header 符合预期
接下来我们将这个 function 进行发布
如 CloudFront 部署小指南(二)中回源请求及响应头策略章节中提到，如果您期望自定义头部成功被携带回源，那么您需要在回源请求策略(Origin
Request Policy)中对该头部信息进行白名单的添加，这边我们需要将 true-client-ip 添加至回源策略中，如下图所示：
至此，您已完成了将 CloudFront Function 部署至 Staging Distribution 的前置条件!
03
部署过程
我们在前序小指南的基础上，来到需要进行持续部署的 CloudFront Distribution 界面，您可以在 Distribution
界面下方找到创建持续部署的入口：
点击持续部署后，我们将进入到配置界面，此界面中您可以修改 Staging Distribution 的备注，如标注本次的变更内容等等。
进入到下一步，我们可以开始应用此次的变更配置，这边我们针对 “/” 这个 path pattern 进行变更：
变更页面中，将前序步骤准备的 CloudFront function 应用到该行为中，请确保此处应用的 origin request policy
需要包含我们实验用到的 true-client-ip 请求头，且 CloudFront function 应用到正确的 event 中，根据代码文档提到，这个
function event 类型为 viewer request，在对应的 event 中进行应用。
代码文档
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/example-function-add-true-client-ip-header.html
点击保存后，回到前序页面，这边点击下一步继续：
在接下来的页面中，我们可以选择灰度流量的方式，如前序章节中提到，持续部署可以支持两种流量灰度方式，为了方便展示测试效果，此处我们选择
Header-Based 的方式来进行配置：
确认配置无误后来到页面最下方创建 Staging Distribution
创建配之后，我们可以看到携带了 Staging 标识的 Distribution 被创建了出来，并且在 Distribution
列表中，也可以看到对应的 Staging 以及 Primary Distribution：
进入到 Primary Distribution 中，可以看到与之关联的 Staging Distribution：
至此，您已完成了持续部署配置的创建!
04
配置验证/监控
在本实际测试中，我们可以使用 Policy 中指定的 header 来进行测试，测试效果如下：
在上述截图中，从携带指定头部的 curl 请求 body 中，我们可以看到 echo server 所记录的 request header
已经可看到通过 CloudFront function 逻辑所指定携带的 True Client IP 请求头信息，同时，该变更仅影响 Staging
Distribution，不携带指定头部时，Distribution 配置逻辑保持不变，请求头未包含 True Client IP 请求头信息。
在 Cloudwatch 指标中，您可通过 Staging Distribution 的 ID 来进行指标的查询并观察部署后的效果，同时也建议您可以在
Cloudwatch 创建一个对比的 Dashboard，可以更直观的看到引导到 Staging Distribution 后的请求状态和 Primary
Distribution 请求状态的对比，以下为一个对比的 Dashboard 示例：
在验证测试效果符合预期后，我们可以来到 Primary Distribution 的页面，点击 Promote
按钮，将此次变更由灰度的方式变更为下发至生产环境中：
您需要确保 Staging 配置的测试结果符合预期，需要注意的是，一旦 promote 完毕后，配置无法进行回滚，需要确保验证结果无误方可进行
promote 操作：
在 Promote 之后，Staging Distribution 将会处于 Disable 的状态，如果您需要进行其他变更，可以在此 Staging
Distribution 上继续进行编辑，并且指定您所需要的流量调度 Policy。
05
注意事项
截止至现在(2023/5)，在使用 CloudFront
持续部署前，有些使用限制需要您这边进行注意，具体详情可参考官网说明文档，此处将罗列一些重要的注意事项：
Primary 和 Staging Distribution 的 Behavior 列表必须保持一致，这一点非常重要，否则将可能遇到 Staging
请求 403 的情况，如果您需要新创建一个 Behavior 中的 Path Pattern 匹配，可以先在 Primary
中创建，但配置内容与变更前保持一致，如缓存策略/请求头/响应头策略等等，创建完毕后，在此 Primary 的基础上创建 Staging
Distribution，然后将变更在 Staging Distribution 中进行应用。
并非所有的配置都可进行持续部署，如 HTTP 版本变更 / WAF 规则关联等，以下为支持持续部署功能的部分：
1. Behavior
2. Error pages
3. Geographic restrictions
4. Origins
5. Logging
每个 Primary Distribution 仅可关联一个 Staging Distribution。
Staging Distribution 无论是否启用，都不会过期，如果 Staging Distribution 的数量超限，您可以删除闲置不使用的
Staging Distribution。
持续部署流量调度是基于 CloudFront 内部逻辑实现(基于权重或基于请求 Header)，并不会影响实际域名的 DNS 解析，所以
Staging Distribution 中 CloudFront 生成的 Domain
Name(CloudFront.net)不可使用，如果需要进行流量灰度，还请选择持续部署中提供的两种 Policy 方式。
当您在创建持续部署配置时，如果意外中断 或 未保存直接退出，将会导致产生一个不与任何 Primary Distribution 产生关联的
Staging Distribution(如下图)，由于 Staging Distribution 的数量有最大上限限制(20个)，当您误操作产生了无用的
Staging Distribution 时，为了不占用额度，您可以选择删除该 Staging Distribution，以避免占用额度。
总结
通过本篇文章，如果未来您需要改动的配置具备一定的风险性，如修改业务逻辑，变更源服务器 等，为了避免变更造成业务中断/影响用户体验，使用
CloudFront 的持续性部署(Continuous
Deployment)功能，将支持您以蓝绿部署的方式进行配置变更，以降低配置变更给生产环境带来的风险。
