Users expect zero downtime for critical applications, and app failures can happen when an app is being upgraded to a newer version.
To reduce the risk of production failures, DevOps teams use various deployment approaches like blue-green and canary. It is imperative that ADC appliances deployed in front of the application instances help in easing the implementation and automation of these deployment patterns with few configuration API calls.
In this blog post, we’ll look at how easy it is to implement blue-green and canary deployments for apps on Citrix ADC using the priority load balancing (LB) feature.
Sample Application Deployment
Assume we have a shopping cart app, and a DevOps engineer wants to upgrade the existing version 1 (V1) instances to version 2 (V2).
Create a service group entity and bind instances corresponding to versions V1 and V2 to it. Assign a unique order value to each version as shown here:
add servicegroup shoppingCart SSL
bind servicegroup shoppingCart <V1 application instance IP> 443 -order 1
bind servicegroup shoppingCart <V2 application instance IP> 443 -order 2
Please note, if the app instances are autoscaling based on the load and are represented by a domain name, use the autoscale service group with domain based server, as shown here:
add servicegroup shoppingCart SSL -autoscale DNS
add server shoppingCartV1_server shoppingcart_v1.company.com
bind servicegroup shoppingCart shoppingCartV1_server 443 -order 1
Create an LB vserver with the required load balancing settings for the app deployment and bind the app-specific servicegroup to it.
add lb vserver shoppingCart SSL <Virtual server IP> 443
bind lb Vserver shoppingCart shoppingCart
Blue-Green Deployment, Simplified
In a blue-green deployment, when a new version of an app is ready for production deployment, client traffic shifts gracefully to the newer version while the app instances running the older version is kept on standby. A DevOps engineer constantly monitors the health and performance of the newer version. If there are any issues with the new version, traffic is immediately shifted to the older version to avoid a poor user experience.
If the service group member corresponding to newer version of the app is bound with higher ‘Order’ value, as shown in the sample deployment above, the DevOps engineer can switch the traffic to the newer version by setting the ‘toggleOrder’ parameter on LB virtual server to ‘Descending’ as shown below. With this configuration change, the load balancing algorithm, if healthy, prefers the service group members with higher ‘Order’ value.
set lb Vserver shoppingCart -toggleOrder Descending
The DevOps engineer can divert the clients back to older version in case of an issue in V2 by setting the ‘toggleOrder’ parameter on LB virtual server to ‘Ascending’ as shown below. With this configuration change, the load balancing algorithm, prefers the service group members with lesser ‘Order’ value.
set lb Vserver shoppingCart -toggleOrder Ascending
Canary Deployment, Simplified
In a canary deployment, when the new version of an app 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 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, which eventually replaces the old production version of the app.
For a canary deployment, you’ll need to create the load balancing policy and action dictating the traffic distribution ratio between V1 and V2.
add lb action shoppingCartActionV2 -type SelectionOrder -value 2
add lb policy shoppingCartPolicyV2 -rule sys.random.mul(100).lt(20) -action shoppingCartActionV2
bind lb Vserver shoppingCart -policyName ShoppingCartPolicyV2 -Priority 10 -gotoPriorityExpression END -type Request
The DevOps engineer can increase the traffic to version V2 by firing the below single command on Citrix ADC:
set lb policy shoppingCartPolicyV2 -rule sys.random.mul(100).lt(40)
In case of an issue, all you need to do is remove the newer version V2 and divert traffic back to V1 by executing this command:
unbind servicegroup shoppingCart <V2 application instance IP> 443
If the newer version V2 is deemed fit for production above command need to be fired for older version V1 instances.
Please note, canary and blue-green deployments can be implemented across datacenters with Citrix ADC’s GSLB feature. The above configuration pattern should work for GSLB by replacing the LB vserver with GSLB vserver and serviceGroup with GSLB serviceGroup entities. The LB policies and actions should also work in a GSLB context.
Learn More
The priority LB feature simplifies app deployment configuration on Citrix ADC by reducing the number of configuration API(NITRO) calls needed to implement the required deployment pattern. You can implement runtime changes in a deployment using a single command or an API call to the Citrix ADC.
Learn more about the priority load balancing feature in Citrix ADC.
