Canary deployment with Citrix ADC’s application insights | Citrix Blogs
This post originally appeared on the Citrix blog.
With the velocity of code and the frequency of software releases today, sustaining the quality of a shipped application is a challenge. Enterprises don’t want to compromise on quality, and, as a result, they’re automating the entire life cycle of software development right after code check-in.
No matter how in-depth the in-house test coverage is, there’s no replacement for exposure to production traffic. Because of this, canary deployment has become one of the most widely followed deployment approaches for new versions of applications. It helps uncover run-time issues that would have been difficult in regular functional and integration testing. This helps improve code quality and increases the confidence in newly checked-in code for the developer and the consumer of the product. This blog details how to use Citrix ADC to implement canary deployments for your applications.
In canary deployment, when a new version of an application is checked in, the image is installed and exposed in phases to production traffic. Initially a small percentage of production traffic is sent to the newer version and the remaining traffic to the older production version.
DevOps engineers constantly monitor the health of the newer version. If it’s deemed healthy and the performance is on par with the production version, the engineers can increase the percentage of production traffic going to the newer version. This process continues until the application owner is confident of the quality of the newer version. The old production version of the application is replaced with the newer version graciously.
Content Switching for Canary Deployments
A primary characteristic of a canary deployment is the categorizing of traffic and routing of a subset of that traffic to the canary (the newer version of an application). Categorizing traffic based on one of the application attributes and routing it to a particular set of back-end servers is a battle-tested feature on Citrix ADC known as content switching (CS). Content switching uses Citrix ADC’s rich policy infrastructure to inspect the incoming traffic and route it to one of the load-balancing virtual servers attached to the CS virtual server.
Canary Deployment Using Random Distribution
One strategy for canary deployments is to randomly pick a percentage of traffic and route it to the canary version of the application. This can be achieved easily using sys.random expressions in the Citrix ADC policy infrastructure.
For example, an e-commerce company wants to implement this canary-deployment strategy for its e-commerce portal application shoppingCart. Here’s the Citrix ADC configuration to achieve this canary deployment:
1. Create a CS virtual server entity dedicated for the application. Use the following command:
add cs vserver shoppingCartCSvserver SSL 10.102.1.2 443
2. Create a Load Balancing (LB) virtual server and service group entity specific to the application deployment or version. If the version is V1, use the following commands:
add lb vserver shoppingCartV1 SSL
add servicegroup shoppingCartV1 SSL
bind lb vserver shoppingCartV1 shoppingCartV1
3. Bind the back-end instance IP address and port running version V1 to service group shoppingCartV1. Use the following command:
bind servicegroup shoppingCartV1 <IP> <port>
Alternately, bind a domain-based server (DBS) to the service group if the set of instances is running a particular version that is represented by a domain name on a DNS nameserver. For more information on DBS in service group, see Configure automatic domain-based service group scaling.
4. Add a CS policy and action with appropriate expressions and target the LB virtual server. Also, bind it to the application’s CS virtual server. Use the following commands:
add cs action shoppingCartActionV1 -targetLBvserver shoppingCartV1
add cs policy shoppingCartPolicyV1 -rule “sys.random.mul(100).lt(80)” -action shoppingCartActionV1
bind cs vserver shoppingCartCSvserver -policyname shoppingCartPolicyV1 -priority 1
5. Repeat steps 1- 4 if you are adding a newer version of the application, for example V2. The expressions in CS policy differ for V2, and the CS policy for V2 will be as follows:
add cs policy shoppingCartPolicyV2 -rule “sys.random.mul(20).lt(20)” -action shoppingCartActionV2
bind cs vserver shoppingCartCSvserver -policyname shoppingCartPolicyV2 -priority 2
Note: Ensure that you give a priority value for the V2 policies higher than the value that you have given to the V1 Also, only the CS policy expression or rule changes across the use-cases described in the blog. The rest of the configuration remains the same.
In this configuration the traffic is distributed in an 80:20 ratio between the production and canary versions. If you want to change the traffic distribution to a 60:40 ratio after you determine the canary version is healthy, then you need to change the CS policies as follows:
set cs policy shoppingCartPolicyV1 -rule “sys.random.mul(100).lt(60)”
set cs policy shoppingCartPolicyV2 -rule “sys.random.mul(40).lt(40)”
Canary Deployment Using Application Attributes
It’s common to use one of the application attributes to categorize the clients. Using one of the HTTP header attributes, we can uniquely identify a set of clients. For example, categorize incoming traffic based on mobile/desktop device (using user-agent header) and expose the canary version to only one type of device. Similarly, we can use one of the URL attributes or authorization headers to categorize the incoming clients. For more information on Citrix ADC policy capabilities, see policies and expressions
The following is a sample Citrix ADC configuration to achieve a canary deployment using the User-Agent header:
add cs policy shoppingCartPolicyV1 -rule ‘HTTP.REQ.HEADER(\”User-agent\”).CONTAINS(\”Mobile\”).not’ -action shoppingCartActionV1
add cs policy shoppingCartPolicyV2 -rule ‘HTTP.REQ.HEADER(\”User-agent\”).CONTAINS(\”Mobile\”)’ -action shoppingCartActionV2
Note: Follow the CS vserver, LB vserver, servicegroup, and CS action configurations as instructed in the Canary Deployment Using Random Distribution section above.
The sample configuration directs the traffic for mobile clients to version V2 of the application by inspecting the user agent header for Mobile string. The remaining traffic is directed to version V1 of the application.
Canary Deployment Using Client Location
For global web applications, you can use the client location to categorize traffic and route users from a particular geography to the canary version. Citrix ADC policy infrastructure includes policy expressions to obtain the client location, and you can leverage this to achieve the use case.
The following is a sample Citrix ADC configuration to achieve a canary deployment using the client location:
add cs policy shoppingCartPolicyV1 -rule ‘CLIENT.IP.SRC.MATCHES_LOCATION(\”NA.US.CA.*.*\”).not’ -action shoppingCartActionV1
add cs policy shoppingCartPolicyV2 -rule ‘CLIENT.IP.SRC.MATCHES_LOCATION(\”NA.US.CA.*.*\”)’ -action shoppingCartActionV2
Note: Follow the CS vserver, LB vserver, servicegroup, and CS action configurations as instructed in the Canary Deployment Using Random Distribution section above.
The sample configuration routes the client traffic from California region to version V2 of the application. The remaining traffic is directed to version V1 of the application.
For more information on location databases, see static proximity database.
For more such content visit Citrix ADC blogs