brief introduction
In this blog post, you will learn how to use CloudFront continuous deployment (Continuous deployment) for blue-green deployment/change verification, and then according to business high availability requirements.
Continuous deployment (Continuous deployment) diagram:
We will divide it into several parts to explain the functions below:
Concept analysis
Environmental preparation
deployment process
Configuration verification and monitoring
Precautions
01
Concept analysis
By using Amazon CloudFront's continuous deployment, you can grayscale part of the production traffic to the change configuration (Staging Distribution) to safely deploy changes to the CDN configuration.
work process:
To facilitate your continuous deployment with CloudFront, the concepts involved in the deployment process are explained below:
1. Primary Distribution: Distribution that requires configuration changes.
2. Staging Distribution: During the process of enabling the continuous deployment function, CloudFront will create a Staging Distribution configuration separately, and all configuration changes will be saved in the Staging Distribution, and the Primary Distribution will not be affected before the Promote is performed.
3. Policy: The traffic policy you need to use. In continuous deployment, you can use one of two methods to grayscale traffic according to actual needs:
▪ Guide some traffic to Staging Distribution based on weight-based;
▪ Specifies that requests carrying specific request headers (Header-based) are directed to Staging Distribution.
Weight-based: Up to 15% of the production traffic can be specified to be directed to the Staging Distribution. In order to meet certain specific scenarios, some users need to access the configuration before or after the change. The percentage-based policy supports session stickness. The session stickness time can be specified, and the maximum adjustable idle TTL is 1 hour. It should be noted that in session stickness, the maximum TTL (Maximum TTL) is also 1 hour. When session stickness is enabled, no matter how much idle TTL you set, when a user's session reaches 1 hour, it will re-enter the Policy link for Weight-based selection.
Header-based: The name format of the request header must start with aws-cf-cd-, such as aws-cf-cd-jwtest .
4. Promote: Send the changes saved in Staging Distribution to Primary Distribution.
02
Environmental preparation
We demonstrate the deployment process based on the overall architecture of the deployment guide (2):
The requirement is that we need to add the client IP to the custom request header True-Client-IP through CloudFront Function, and carry it back to the source. We can use the official sample code to deploy CloudFront Function. You can find the CloudFront Function entry on the left side of the CloudFront Console:
Choose to create a function
Give your function a name and continue
Copy and paste the official sample code into the code box, save and continue
Sample code:
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/example-function-add-true-client-ip-header.html
Let's go to the Test tab, first debug the code logic, and check whether the output results meet expectations
In the execution result below, we can see that the execution was successful, and the request header is as expected
Next we will publish this function
As mentioned in CloudFront Deployment Guide (2) in the back-to-origin request and response header policy section, if you expect custom headers to be successfully carried back to the origin, you need to add the header information to the whitelist in the origin request policy (Origin Request Policy). Here we need to add true-client-ip to the back-to-origin policy, as shown in the following figure:
At this point, you have completed the prerequisites for deploying CloudFront Function to Staging Distribution!
03
deployment process
Based on the previous small guide, we come to the CloudFront Distribution interface that requires continuous deployment. You can find the entry for creating continuous deployment under the Distribution interface:
After clicking Continuous Deployment, we will enter the configuration interface. In this interface, you can modify the remarks of Staging Distribution, such as marking the content of this change and so on.
Going to the next step, we can start to apply the changed configuration. Here we make changes to the path pattern "/":
On the change page, apply the CloudFront function prepared in the previous steps to this behavior. Please ensure that the origin request policy applied here needs to include the true-client-ip request header used in our experiment, and the CloudFront function is applied to the correct event. According to the code documentation, the function event type is viewer request, and it is applied in the corresponding event.
code documentation
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/example-function-add-true-client-ip-header.html
After clicking Save, return to the previous page, click Next here to continue:
On the next page, we can choose the grayscale traffic method. As mentioned in the preamble, continuous deployment can support two traffic grayscale methods. In order to facilitate the display of test results, here we choose the Header-Based method for configuration:
After confirming that the configuration is correct, go to the bottom of the page to create Staging Distribution
After the distribution is created, we can see that the Distribution carrying the Staging logo is created, and in the Distribution list, we can also see the corresponding Staging and Primary Distribution:
Enter the Primary Distribution, you can see the Staging Distribution associated with it:
At this point, you have completed creating a continuous deployment configuration!
04
Configuration Verification/Monitoring
In this actual test, we can use the header specified in the Policy to test, and the test results are as follows:
In the above screenshot, from the curl request body carrying the specified header, we can see that the request header recorded by the echo server can already see the True Client IP request header information specified by the CloudFront function logic. At the same time, this change only affects Staging Distribution. When the specified header is not carried, the Distribution configuration logic remains unchanged, and the request header does not contain the True Client IP request header information.
In Cloudwatch metrics, you can use the ID of the Staging Distribution to query the metrics and observe the effect after deployment. It is also recommended that you create a Dashboard for comparison in Cloudwatch, so that you can more intuitively see the comparison between the request status after being directed to the Staging Distribution and the request status of the Primary Distribution. The following is an example of a Dashboard for comparison:
After verifying that the test results meet expectations, we can go to the Primary Distribution page, click the Promote button, and change the change from the grayscale mode to the production environment:
You need to ensure that the test results of the Staging configuration meet expectations. It should be noted that once the promote is completed, the configuration cannot be rolled back. You need to ensure that the verification results are correct before proceeding with the promote operation:
After Promote, the Staging Distribution will be in the Disabled state. If you need to make other changes, you can continue editing on this Staging Distribution and specify the traffic scheduling Policy you need.
05
Precautions
As of now (2023/5), before using CloudFront for continuous deployment, there are some usage restrictions that require your attention. For details, please refer to the official website documentation. Here are some important precautions:
It is very important that the Behavior lists of Primary and Staging Distribution must be consistent, otherwise you may encounter a 403 request from Staging. If you need to create a new Path Pattern match in Behavior, you can create it in Primary first, but the configuration content is consistent with that before the change, such as cache policy/request header/response header strategy, etc. After creation, create Staging Distribution on the basis of this Primary. The changes are then applied in the Staging Distribution.
Not all configurations are available for continuous deployment, such as HTTP version change/WAF rule association, etc. The following are the parts that support continuous deployment:
1. Behavior
2. Error pages
3. Geographic restrictions
4. Origins
5. Logging
Each Primary Distribution can only be associated with one Staging Distribution.
Whether Staging Distribution is enabled or not, it will not expire. If the number of Staging Distribution exceeds the limit, you can delete the unused Staging Distribution.
Continuous deployment traffic scheduling is implemented based on CloudFront's internal logic (weight-based or request header-based), and will not affect the DNS resolution of the actual domain name. Therefore, the Domain Name (CloudFront.net) generated by CloudFront in Staging Distribution cannot be used. If traffic grayscale is required, please select the two policy methods provided in continuous deployment.
When you are creating a continuous deployment configuration, if you accidentally interrupt or exit without saving, a Staging Distribution that is not associated with any Primary Distribution will be generated (as shown in the figure below). Since the number of Staging Distributions has a maximum upper limit (20), when you misuse a useless Staging Distribution, in order not to occupy the quota, you can choose to delete the Staging Distribution to avoid occupying the quota.
Summarize
Through this article, if the configuration you need to change in the future has certain risks, such as modifying business logic, changing the source server, etc., in order to avoid business interruption or affect user experience caused by the change, using CloudFront's continuous deployment (Continuous Deployment) function will support you to make configuration changes in blue-green deployment to reduce the risks brought by configuration changes to the production environment.
Amazon cloud technology
CloudFront deployment mini-guide series articles
Amazon CloudFront Deployment Guide (1) - Quickly build CDN content distribution:
https://aws.amazon.com/cn/blogs/china/amazon-cloudfront-deployment-handbook-part-one/
Amazon CloudFront Deployment Guide (2) - Advanced Deployment:
https://aws.amazon.com/cn/blogs/china/amazon-cloudfront-deployment-handbook-part-two/
Amazon CloudFront Deployment Guide (4) - CloudFront Function Basics and Diagnosis:
https://aws.amazon.com/cn/blogs/china/amazon-cloudfront-deployment-handbook-part-four/
Amazon CloudFront Deployment Guide (5) - Using Amazon Edge Technology to Optimize In-Game Resources Update release:
https://aws.amazon.com/cn/blogs/china/amazon-cloudfront-deployment-handbook-part-five/
Amazon CloudFront Deployment Guide (6) - Lambda@Edge Basics and Diagnosis:
https://aws.amazon.com/cn/blogs/china/amazon-cloudfront-deployment-handbook-part-six/
The author of this article
Wang Junxing
Amazon Cloud Technology Edge Product Architect, responsible for the technical promotion of Amazon Cloud Technology Edge services in China. He has many years of practical experience in the field of CDN content distribution and WAF, focusing on edge service design and experience optimization.
I heard, click the 4 buttons below
You will not encounter bugs!
