Introduction
Blue/green deployments provide releases with near zero-downtime and rollback capabilities. The fundamental idea behind blue/green deployment is to shift traffic between two identical environments that are running different versions of your application. The blue environment represents the current application version serving production traffic. In parallel, the green environment is staged running a different version of your application. After the green environment is ready and tested, production traffic is redirected from blue to green. If any problems are identified, you can roll back by reverting traffic back to the blue environment.
Problems faced due to on-premises servers and why cloud computing serves a greater purpose?
In a traditional approach to application deployment, you typically fix a failed deployment by redeploying an earlier, stable version of the application. Redeployment in traditional data centers is typically done on the same set of resources due to the cost and effort of provisioning additional resources.
Although this approach works, it has many shortcomings. Rollback isn’t easy because it’s implemented by redeployment of an earlier version from scratch. This process takes time, making the application potentially unavailable for long periods. Even in situations where the application is only impaired, a rollback is required, which overwrites the faulty version. As a result, you have no opportunity to debug the faulty application in place.
Applying the principles of agility, scalability, utility consumption, as well as the automation capabilities of Amazon Web Services can shift the paradigm of application deployment. That is why blue/green deployments with zero-downtime on On-premises servers is not feasible as you have to pay more, and the additional resources eventually will be treated as redundant for deployments only.
Implementation
Creating Application Version 1 and ALB
1. Open AWS Console and navigate to EC2 dashboard then Launch templates. After this, click on Create launch template. Provide template name and version as given below.
2. Select AMI, Instance type and Key Pair.
3. Now configure Network Settings and specify security group rules for ssh, http and https.
4. Now you can keep the rest of the settings as default and go into Advanced Details Settings and under User Data paste the below code to deploy the application version 1 website.
#!/bin/bash
# Use this for your user data (script from top to bottom)
# install httpd (Linux 2 version)
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo \”<html><head></head><body style=\\\”height:100vh;background-color:blue; display:flex;flex-direction:column;justify-content:center;align-items:center;align-content: center;\\\”><h1>Hello World from $(hostname -f)</h1><h1>Application Version 1</h1><h1>(Blue Version)</h1></body></html>\” > /var/www/html/index.html
5. Now click on Create launch template and from EC2 dashboard navigate to Auto Scaling Groups and click on Create. Specify Name and select Launch template we configured in above step.
6. In the next step, create a new internet facing Application Load Balancer and create a new target group with this ASG. Optionally check the ELB health check.
7. Keep all other settings as default and make the desired,min and max capacity as 1 and click on Create.
After creation of the auto scaling group navigate to Load Balancers from the EC2 dashboard and copy its DNS name from the description. Open the DNS in the new tab of your browser and you will see the Website served on the ec2 launched by the auto scaling group with the specified user data.
Creating Application Version 2
1. For creating version 2 of our application you have to edit the same launch template user data by creating a new version of the template and paste the code as given.
#!/bin/bash
# Use this for your user data (script from top to bottom)
# install httpd (Linux 2 version)
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo \”<html><head></head><body style=\\\”height:100vh;background-color:green; display:flex;flex-direction:column;justify-content:center;align-items:center;align-content: center;\\\”><h1>Hello World from $(hostname -f)</h1><h1>Application Version 2</h1><h1>(Green Version)</h1></body></html>\” > /var/www/html/index.html
2. Now navigate to Target Groups from the EC2 dashboard and create a new target group. Select Instances in target type, provide target group name, http protocol, port 80, vpc and protocol version as HTTP1. Leave the rest as default and click on create.
3. Now navigate to load balancer and select your load balancer, then edit listeners and finally add rule for “/” path and forward to “App-v1-tg” and “App-v2-tg” and assign weights in percentage which we will see in next section below, but for now assign 50-50% and save rule.
4. Now create a new Auto Scaling Group with this new launch template version. Select the Attach Existing Load Balancer and select the target group(App-v2-tg) we created above, keep other settings as default and launch the ASG with the same capacity as before.
5. Now open the same Load Balancer DNS in the new tab of your browser and you will see both the application versions upon reload, distributed equally through ALB.
6. As you can see now our ALB serves both the application versions, the older one (blue) and the new one (green). Now let\’s go to the strategy of implementing weights to both the target groups on your ALB for a smooth blue/green application deployment.
Blue/Green Strategy
1. Rolling:
In rolling blue/green deployment you usually start with ‘x’ percent of weighted target group 1 and ‘100-x’ percent of weighted target group 2. After this you shift traffic slowly to the newer version in increments of ‘x’ percent which is known as rolling. This is a great strategy to test the newer version for bugs and its capability to withstand the traffic and incase of error/bug, you can always rollback and shift all of your traffic to the current version of the application.
2. Canary:
Canary deployment is similar to rolling in which we first test the newer version by ‘x’ percent of weighted target group and then after successful testing at the particular percentage only we shift all of the traffic directly to the newer version ( no increments as in rolling). This is also a good strategy for testing bugs.
In both rolling and canary, we can also apply the strategy of rolling of ec2 instances in both autoscaling groups by keeping the overall desired capacity same. You can refer to the following diagram.
3. All At Once:
As the name suggests, you shift all the traffic i.e. 100 percent from current version to newer version of application. This strategy has a drawback as we cannot test the newer version for bugs or any other deployment errors. This is usually used for the development phase of an application.
Closing Words:
As you can see, the blue/green deployment technique is very useful in the deployment of newer application versions with near-zero downtime and rollback in case of any failure, all of this possible due to the advent of cloud computing. Blue/green deployment can also be implemented with Updating DNS Routing with Amazon Route 5, Swap the environment of an Elastic Beanstalk application, Clone a Stack in AWS OpsWorks, and Update DNS, Code deploy deployment strategy, weighted Aws Lambda Aliases, etc.
Written by – Mohammed Shahid AdoniPost navigation
