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 NetScaler 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 SSLbind servicegroup shoppingCart <V1 application instance IP> 443 -order 1bind 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 DNSadd server shoppingCartV1_server shoppingcart_v1.company.combind 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> 443bind 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 the 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 2add lb policy shoppingCartPolicyV2 -rule sys.random.mul(100).lt(20) -action shoppingCartActionV2bind 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 NetScaler 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 NetScaler 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 NetScaler 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 NetScaler ADC.

Learn more about the priority load balancing feature in NetScaler ADC.