Jump to content
Welcome to our new Citrix community!
  • Blue-Green and Canary Deployments with Netscaler and Terraform


    Guest
    • Validation Status: Validated
      Has Video?: No

     

    Application developers want to quickly release new features and enhancements to application end users. But speed comes with the risk of compromised user experience, unforeseen product issues, performance slow down etc. Hence,blue-green and canary deployment techniques are employed for well-planned product updates, to avoid downtime, and easier roll-back when required. In this post, I’ll explain how you can integrate Citrix Application Delivery Controller (NetScaler) capabilities and automation with CI/CD pipelines to facilitate blue-green and canary deployment for apps.

     

    The solution example covered in this post contains the various components:

     

    • NetScaler deployed in Azure cloud
    • CI/CD pipelines built with Azure DevOps
    • Terraform used for configuring NetScaler through Azure pipelines
    • GitHub used as source code management
    • GitOps for declarative application delivery management

    Now, let see how all the above tools come together to set up seamless blue-green and canary deployments using NetScaler and Terraform.

     

    NetScaler and Terraform for Application Deployments

    There are three components to the solution: deployment configurations, NetScaler configurations, and pipeline configurations.

     

    Deployment Configurations

    In the deployment configuration, the app admins or DevOps will declare  the target application version, such as v1 or v2, and the traffic weight to that deployment version. As shown in the below config, 100 percent of the traffic will go to v2 version of the deployment.

    {  "TRAFFIC_WEIGHT": "100",  "ADC_CONFIG": "ci_cd/deployment_config/v2.conf",  "DEPLOYMENT_VERSION": "v2"}

    Information on the backend application is defined in a separate file v2.conf as shown below.

    backend_service_ip = "10.0.0.9"	priority = 100

    backend_service_ip denotes the IP to your backend application and priority determines the precedence of traffic to be served among multiple versions of applications. The priority value for a newer version of the application must be set with a lower value than that of the existing version of the application. The reason is that the lower the value, the higher the priority of the policy considered by the NetScaler for a given vserver and vice versa.

     

    NetScaler Configurations

    NetScaler configurations scripts are defined in Terraform, which can be found here. NetScaler configurations include Content Switching vserver, Load Balancing vserver, Content Switching policies, backend services, and more with the appropriate priority set for each version of the backend application.

     

    The configuration below shows the Content Switching policy in NetScaler for each application version. User traffic to demo-bg.webapp.com will land on content switching vserver named demo_csvserver, which then gets routed to either blue load balancing vserver or green load balancing vserver. We achieve blue green deployment by adjusting the traffic_weight and priority of the Content Switching policy to switch the traffic between blue and green version of the application.

     

    #cs_lb --Connecting to CSVServer to both LB Serversresource "citrixadc_csvserver" "demo_csvserver" {  ipv46       = "10.0.0.5"  name        = "demo_csvserver"  port        = 80  servicetype = "HTTP"}resource "citrixadc_lbvserver"  "lbvs"{  name        = format("%s-lbvs", var.resource_prefix)  servicetype = "HTTP"}resource "citrixadc_service"  "service"{    lbvserver = citrixadc_lbvserver.lbvs.name    name = format("%s-service", var.resource_prefix)    ip = var.backend_service_ip    servicetype  = "HTTP"    port = 80}#policy based on that target lbvserverresource "citrixadc_cspolicy" "cspolicy"{  csvserver       = citrixadc_csvserver.demo_csvserver.name  targetlbvserver = citrixadc_lbvserver.lbvs.name  policyname      = format("%s-cspolicy", var.resource_prefix)  rule            = format("HTTP.REQ.HOSTNAME.SERVER.EQ(\"demo-bg.webapp.com\") && HTTP.REQ.URL.PATH.SET_TEXT_MODE(IGNORECASE).STARTSWITH(\"/\") && sys.random.mul(100).lt(%s)", var.traffic_weight)  priority        = var.priority  # Any change in the following id set will force recreation of the cs policy  forcenew_id_set = [    citrixadc_lbvserver.lbvs.id,    citrixadc_csvserver.demo_csvserver.id,  ]}

    Pipeline Configurations

    Pipeline configurations includes the Azure pipeline script and the simple python script which reads the user configurations in the deployment_config directory and triggers the pipeline based on the user request to introduce new version or switch the traffic between blue and green version of application or teardown a version of an application.

     

    With all above configuration files in place, any update to the files under deployment_configs directory in GitHub, would trigger the pipeline in Azure.

    Achieving Blue-Green Deployment with NetScaler and Terraform
    Assuming that the backend services are up and ready to take user requests and that the corresponding IPs are available, let’s explore the steps involved in setting up a blue-green deployment.

     

    Setting up Azure Pipelines and Introducing Blue version of the application- V1:

    1. Clone the repo and update NetScaler configurations in adc_configs/provider.tf
    2. Create two Azure Pipelines using the existing YAML "deploy.yaml" and "teardown.yaml" for deploying and tearing down the applications. Update the subscription details, agent pool details in the pipeline YAML and save the pipeline. Refer to Azure Pipelines for creating a pipeline.
    3. Create v1.conf under deployment_configs directory as shown below: 
      backend_service_ip = “<IP of backend service with version v1>” priority = 101 // This is used to set the priority of the traffic to be served by ADC when we introduce new version of application in production environment

    4. Update setup_config.json with version and traffic weight percentage 
      {    "TRAFFIC_WEIGHT": "100",    "ADC_CONFIG": "ci_cd/deployment_config/v1.conf",    "DEPLOYMENT_VERSION": "v1"}

    5. Git commit setup_config.json and v1.conf to trigger the pipeline to deploy v1 version of application. Now you can try accessing the application via NetScaler.

    Introducing Green version of the application-v2

    1.  Introduce the v2 version of application by creating v2.conf
      backend_service_ip = "<IP of backend service with version v2>" priority = 100 // This should be lesser than the v1 version of application, in order to set the higher priority to the traffic served by version v2 

    2. Deploy version v2 by upating setup_config.json
      {       "TRAFFIC_WEIGHT": "100",    "ADC_CONFIG": "ci_cd/deployment_config/v2.conf",    "DEPLOYMENT_VERSION": "v2"}

    3. Now the traffic is completely switched to version v2 and we can go ahead and teardown the version v1 by updating the file deployment_configs/teardown_config.json as below  teardown_config.json   "DEPLOYMENT_VERSIO
      {       "DEPLOYMENT_VERSION": "v1"}

    Once the pipeline build is completed, version v1 deployment will be teared down and we will have only version v2 running.

     

    We can continue introducing newer versions such as v3 and v4 later by simply following th three steps above.

     

     

    Achieving Canary Deployment with NetScaler and Terraforms

    Above solution can be used to achieve canary deployment for your applications as well and the steps remains same as in Blue-Green Deployment.

     

    You need to set the "TRAFFIC_WEIGHT" to the desired traffic percentage that you want to route user request to your latest app version -v2. For example, as per below configuration 20% traffic goes to v2 version of application and the rest i.e., 80% of traffic continues to get routed to older version-v1 of application without any manual changes.

    {    "TRAFFIC_WEIGHT": "20",    "ADC_CONFIG": "ci_cd/deployment_config/v2.conf",    "DEPLOYMENT_VERSION": "v2"}

    Now you can evaluate your latest version v2 release to end users, monitor user behavior, app performance, and more. After the evaluation, you can increase the traffic to v2 version gradually to 40 percent or , 60 percent, or whatever threshold you choose just by setting “TRAFFIC_WEIGHT" variable.

     

    In canary deployment, because you have two application versions (v1 and v2) co-existing and both serving user requests, you don’t tear down v1 version unless you have successfully routed all user requests to v2.

     

    Conclusion

    You can use the NetScaler and Terraform solution for green-blue and canary deployments as is or customize it to fit with the tools and technologies that you use for your infrastructure and CI/CD. NetScaler Terraform modules enable an infrastructure-as-code approach and seamlessly integrate with your automation environment to provide self-service infrastructure.

     

    To automate your NetScaler infrastructure using Terraform, see the following resources:


    User Feedback

    Recommended Comments

    There are no comments to display.



    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

×
×
  • Create New...