Uninterrupted Evolution: Mastering Blue-Green Deployment with AWS ALB for Seamless Application Updates
In this section, we will learn how to deploy new releases/updates of your application without affecting the performance by ensuring high availability and reliability. We will leverage the features of the Application Load balancer to implement blue/green deployment.
A Blue/Green deployment is a deployment strategy in which you create two separate, but identical environments. One environment (blue) is running the current application version and one environment (green) is running the new application version. Using a blue/green deployment strategy increases application availability and reduces deployment risk by simplifying the rollback process if a deployment fails. Once testing has been completed on the green environment, live application traffic is directed to the green environment, and the blue environment is deprecated.
In the below image, we have two production environments, Blue and Green. The Blue environment is one where the current (let’s say version 1) of the application is running and is live as well. All the traffic of the application is directed to Blue by the Router or load balancer (as per the infra setup). Meanwhile, version 2 of the application is deployed and tested on Green Environment.
Currently, at this stage, we can refer to the Blue environment as Live and Green as idle or at staging state.
Once the code for version 2 is tested and ready to be live for production, we redirect the traffic from the Blue Environment to the Green Environment, making Green Live and Blue a staging environment. If any problem is detected with the Infrastructure or application after version 2 is made live, we can roll back to the previous version just by swapping the environment.
Let's see how this can be done.
1. Deploying App Version 1
- Create Launch configuration (app-version1-lc)
- Create an Auto Scaling Group (app-version1-asg)
- Create a Target group (app-version1-tg)
- Attach Auto Scaling Group (app-version1-asg) to Target Group (app-version1-tg)
- Create Application Load balancer (app-alb)
- Forwarding traffic 100% to the target group (app-version1-tg) using ALB rules
2. Deploying App Version 2
Rolling out the App’s New version. Application with new features has to be deployed in other target groups
- Create Launch configuration (app-version2-lc)
- Create Auto Scaling Group (app-version2-asg)
- Create a Target group (app-version2-tg)
- Attach Auto Scaling Group (app-version2-asg) to Target Group (app-version2-tg)
- Forwarding 100% of traffic to a new target group (app-version2-tg) using ALB rules
3. Enabling group level stickiness
Glossary
Application Load balancer is used to route the requests to a specific target group(servers) based on the rules defined in it
The Target group is a group of servers/instances that process and serve the request back to the Application Load balancer
The auto-scaling group is used to automatically provision new instances so as to handle the peak requests. To what limit the Autoscaling group could create new instances is defined in min, max, and desired capacity. By using the scaling policies of the Autoscaling group, we can set to provision new instances based on resource utilization metrics (dynamic scaling policies).ASG is attached to the target group so that the new instances created by the Autoscaling group would be attached to the corresponding target group. So, the application load balancer would start to send requests to the new instance which is recently attached to the target group by the Autoscaling group
Launch configuration is a template that contains the configuration and specification of an instance which the Autoscaling group uses to provision new instances
Let’s first look at the deployment of version1 of the App under an Application Load balancer
1. Deploying App Version 1
Step 1: Create Launch configuration (app-version1-lc)
Login to AWS console >> EC2 >> Auto Scaling Groups >> Create Auto Scaling Group >> switch to launch configuration >> Create a new launch configuration
Launch configuration Name: app-version1-lc
AMI: ami-0xxxxxxx (You can get Amazon Linux ID from EC2 Instance Launch Panel)
Instance type: t2.micro
Advanced configuration >> Advanced details >> Userdata: Enter the set of commands that has to be executed automatically after the instance is provisioned
If your application is pre-packaged with a basic image, then you might choose that particular AMI. Otherwise, you can make use of user data to deploy the application
Storage(volumes): By default, 8GB Root volume is attached for t2.micro class
Security groups: Select from existing security groups. If you don’t have any existing security groups, you can create a new one using “create a new security group”
Key pair >> Choose an existing key pair
Existing key pair >> Select the keypair which you have already created and have the private key of the same in your local
Enable “I acknowledge that I have access to the selected private key file, and that without this file, I won’t be able to log into my instance.”
Click on Create launch configuration
Note: Launch configuration is deprecated now, hence AWS suggests using the Launch template instead.
Step 2: Create Auto Scaling Group (app-version1-asg)
To create AutoScalingGroup,
In the EC2 console, click on EC2 >> Auto Scaling groups >> Create Auto Scaling group
Name : app-version1-asg
Click on Switch to Launch configuration
Select the launch configuration in the drop-down as “app-version1-lc” >> click Next
Select the default VPC
Availability Zones and subnets: Select the subnets in which ASG can create the instances
Configure advanced options
Load balancing >> No load balancer
Health check grace period — 120 Sec
Click next
Configure group size and scaling policies
Min, Max, Desired capacity — 2
Scaling policies
Dynamic scaling policy — dynamically resize your Auto Scaling group to meet changes in demand
As of now, choosing None to use a static scaling policy
Add notifications
Add tags
Enter the name and value as tags to add to the new instances that the AutoScalingGroup creates so that we can understand the instances that are created by the AutoScalingGroup
Key: Name, Value: version1
Review
On this page, we can review the Auto-scaling group configuration and if any section that needs to be modified, click on the edit option on the same section to make changes
Click on Create Auto Scaling Group
The AutoScalingGroup is created.
The details section explains the capacity details of AutoScalingGroup
The instance management section shows the instances that are managed by the AutoScalingGroup
Step 3: Create Target group (app-version1-tg)
A Target group tells a load balancer where to direct traffic to: EC2 instances, fixed IP addresses; or AWS Lambda functions, amongst others.
EC2 management console >> Click on Target Group under Load Balancing >> Click on Create Target Group
Choose a target type: Instances
Target group name: app-version1-tg
Protocol: HTTP
Port: By default, a load balancer routes requests to its targets using the protocol and port number that you specified when you created the target group.
Instance Port: 80
Health checks: The associated load balancer periodically sends requests, per the settings provided, to the registered targets to test their status
Health check protocol: HTTP
Health check path: /index.php
Advanced health check settings
Healthy threshold: 2 (It is the number of consecutive health checks successes required before considering an unhealthy target healthy)
Unhealthy threshold: 2 (It is the number of consecutive health check failures required before considering a target unhealthy)
Timeout: 5 seconds (It is the amount of time, in seconds, during which no response means a failed health check)
Interval: 30 seconds (It is the approximate amount of time between health checks of an individual target)
Success codes: 200
Register targets: Do not select any specific instance as targets. Why registering instances as targets is not recommended here is, that we will be attaching an autoscaling group to the target group. If we select and register a particular instance from the list shown in the pic, when that particular instance is down ASG will create a new instance following the health check failed situation. But the new instance which is replaced by the ASG would need to be manually registered to the target group. Hence, We will attach an auto-scaling group to the target group so that the instances created by the ASG will automatically attached as targets for the load balancer.
Click on Create Target Group. A Target Group with the name “app-version1-tg” will be created.
We can see the Target Group with the name “app-version1-tg” is created with no registered targets. In the next section, we will register the targets that are created by the auto-scaling group indirectly by attaching the auto-scaling group to the target group
Step 4: Attach Auto Scaling Group to Target Group
EC2 management console >> Auto scaling Group >> Select the Auto scaling Group “app-version1-asg” >> Edit
Under the Load balancing option, select “Application, Network or Gateway Load Balancer target groups” select the Target group we created “app-version1-tg” and click on update.
Now the Instances created by the Auto scaling Group are added to the Target Group.
Step 5: Create Application Load balancer (app-alb)
In the EC2 management console, Click on Load Balancer >> Create Load Balancer >> Application Load Balancer >> Create
Load balancer name: app-alb
Network mapping: Select at least two Availability Zones and one subnet per zone. The load balancer routes traffic to targets in these Availability Zones only.
Security Group : Select an existing security group : freedom
Listeners and routing :
Application load balancer endpoint would listen only on this particular listener protocol and port number. Application load balancer won’t support any other protocol and port other than what is defined as a listener.
If a request comes with https protocol for the 443 port, the default Action we select is Forward to the Target Group we created app-version1-tg which means HTTP requests that come to the load balancer, would be forwarded to the underlying target group.
Using AWS Certificate Manager (ACM) we can provision and manage SSL/TLS certificates for your AWS-based websites and applications.
Since ALB is configured to listen on HTTPS port only, We are loading the certificate created for chandika.tech domain from ACM. This certificate will automatically be added to the listener certificate list.
Now Click on Create Load Balancer.
Step 5(1): Add HTTP listener to redirect to HTTPS
Another listener for HTTP(80) is added to ensure the requests that come with HTTP protocol are also served properly.
EC2 >> Load Balancer >> Select the load balancer “app-alb” >> Under Listeners tab >> Add Listener
Protocol: HTTP
Port: 80
Default action: Redirect to HTTPS: 443
Click on Add
Step 6: Forwarding traffic to target group 1 (app-version1-tg) using ALB rules
EC2 >> Load Balancer >> Select the load balancer “app-alb” >> Under Listeners tab >> Select the Listener “HTTPS:443” >> Actions >> Manage rules
Click on the + icon to add rules, and Click on the pencil icon to edit existing rules
To add a new rule, Click on Insert Rule
Add condition >> Select “Host header” >> Host header : shopping.chandika.tech
Add action >> Select “Forward to” >> Select target group “app-version1-tg”
Click on Tick to save the rule >> Click on Save
The requests that come with the shopping.chandika.tech host header would be subjected to the first rule which forwards the request to the target group containing the version instances.
All other requests (not containing shopping.chandika.tech host header) would be subjected to the “default action” rule(second rule in the pic). By default, it is also set to redirect to app-version1-tg. We will edit it to return fixed responses as “Site not found”.
Click on the pencil straight to the default action rule
IF (all match): Requests otherwise not routed Forward To delete the current rule
Click on Add action >> Return Fixed Response
Response code: 503
Content-Type: text/HTML
Response body: Site Not Found
Click on the Tick
The Default rule was successfully updated.
Step 7: Pointing my domain “shopping.chandika.tech” to the ALB endpoint in route 53
Navigate to Route 53 Dashboard >> Click on Hosted Zone
Click on the Domain’s zone (chandika.tech) Click on “Create record”
Record name: shopping
Enable: Alias
Route traffic to Alias to Application and Classic Load Balancer
Choose Region: Asia Pacific Mumbai [ap-south-1]
Choose Load Balancer: dualstack.Shopping-app-xxxxx.ap-south-1.elb.amazonaws.com
Click on Create.
Calling https://shopping.chandika.tech is working fine
2. Deploying App Version 2
Step 8: Create Launch configuration (app-version2-lc)
EC2 >> Auto Scaling groups >> Create Auto Scaling group
Click on Create a Launch configuration
Launch Configuration Name: app-version2-lc
AMI: ami-0xxxxxxx (You can get Amazon Linux ID from EC2 Instance Launch Panel)
Instance type: t2.micro
Advanced configuration >> Advanced details >> Userdata: Enter the set of commands that has to be executed automatically after the instance is provisioned
If your application is pre-packaged with a basic image, then you might choose that particular AMI. Otherwise, you can make use of user data to deploy the application
Storage(volumes): By default, 8GB Root volume is attached for t2.micro class
Security groups: Select from existing security groups. If you don’t have any existing security groups, you can create a new one using “create a new security group”
Key pair >> Choose an existing key pair
Existing key pair >> Select the keypair which you have already created and have the private key of the same in your local
Enable “I acknowledge that I have access to the selected private key file, and that without this file, I won’t be able to log into my instance.”
Click on Create launch configuration
We can see 2 launch configurations, One is for version 1 and another is for version 2.
Step 9: Create Auto Scaling Group (app-version2-asg)
To create AutoScalingGroup,
EC2 >> Auto Scaling groups >> Create Auto Scaling group
Name : app-version2-asg
Click on Switch to Launch configuration
Select the launch configuration in the drop-down as “app-version2-lc” >> click Next
Choose instance launch options >> Select the default VPC.
Availability Zones and subnets: Select the subnets in which ASG Provides the instances.
Configure advanced options >> Load balancing >> No load balancer
Health check grace period: 120 Sec
Configure group size and scaling policies.
Min, Max, Desired capacity — 2
Scaling policies
Dynamic scaling policy — dynamically resize your Auto Scaling group to meet changes in demand.
As of now, choosing None to use a static scaling policy.
Add tags
Enter the name and value as tags to add to the new instances that the Auto Scaling Group creates so that we can understand the instances that are created by the Auto Scaling Group
Key: Name, Value: version2
Review
On this page, we can review the AutoscalingGroup configuration and if any section needs to be modified, click on the edit option on the same section to make changes.
Click on “Create Auto Scaling Group”
Now we can see the AutoScalingGroup is created.
The Details section explains the capacity details of AutoScalingGroup
The instance management section shows the instances that are managed by the Auto Scaling Group
Step 10: Create Target group (app-version2-tg)
A Target group tells a load balancer where to direct traffic to: EC2 instances, fixed IP addresses; or AWS Lambda functions, amongst others.
In the EC2 management console >> Click on Target Group under Load Balancing >> Click on Create Target Group
Target type: Instances
Target group name: app-version2-tg Protocol: HTTP Port: By default, a load balancer routes requests to its targets using the protocol and port number that you specified when you created the target group. Instance Port: 80
Health checks: The associated load balancer periodically sends requests, per the settings provided, to the registered targets to test their status
Health check protocol: HTTP Health check path: /index.php
Healthy threshold: 2 (It is the number of consecutive health checks successes required before considering an unhealthy target healthy)
Unhealthy threshold: 2 (It is the number of consecutive health check failures required before considering a target unhealthy)
Timeout: 5 seconds (It is the amount of time, in seconds, during which no response means a failed health check)
Interval: 30 seconds (It is the approximate amount of time between health checks of an individual target)
Success codes: 200
Register targets: Do not select any specific instance as targets. Why registering instances as targets is not recommended is, that when that particular instance is down ASG will create a new instance following the health check failed situation. But the new instance which is replaced by the ASG would need to be manually registered to the target group. Hence, We will attach an auto-scaling group to the target group so that the instances created by the ASG will automatically act as targets for the load balancer.
Click on Create Target Group. A Target Group with the name “app-version2-tg” will be created.
Select the target group “app-version2-tg” from the list, you can see no targets under “Registered targets.”
Step 11: Attach Auto Scaling Group to Target Group
EC2 management console >> Auto-scaling Group >> Select the Auto-scaling Group “app-version2-asg” >> Edit.
Under the Load balancing option, select “Application, Network or Gateway the Load Balancer target groups” Select the Target group we created “app-version2-tg” and click on update.
The instances of the auto-scaling group are attached to the target group now.
Step 12: Forward 100% of traffic to the new target group (app-version2-tg) using ALB rules.
EC2 console >> Load Balancers >> Click on app-alb
Under Listener tab >> Choose HTTPS:443 listener >> Actions >> Manage rules
Click on edit (pencil icon) option >> Edit the rule number 1 where IF = Host is shopping.chandika.tech
Click on Edit of Forward to where IF = Host is shopping.chandika.tech
Select a second target group from the dropdown >> Choose app-version2-tg
Enter the weightage in the small box next to the target group box app-version1-tg: 0 (0%) app-version2-tg: 1 (100%)
This allows the ALB to forward 100% of the traffic to the app-version2-tg target group and No traffic to the app-version1-tg target group.
Click the tick to save the rule
The website/application shopping.chandika.tech is served fully by the app-version2-tg target group and not by the app-version1-tg target group as in the screenshot
All other requests having a host header other than shopping.chandika.tech are served with a “Site Not Found” fixed response.
For a cost-effective solution, reduce the auto-scaling group version-1’s (app-version1-asg) capacity to 0. When there is a revert needed to version 1, we can increase the capacity to the need so the auto-scaling group 1(app-version1-asg) will launch new instances from the launch configuration 1(app-version1-lc).
Advantages & Disadvantages of Blue/Green Deployments
Advantages:
- Debugging: In Blue-green deployment, rollbacks always leave the failed deployment intact for analysis.
- Zero downtime: no downtime means that we can make releases at any time. There is no need to wait for maintenance windows.
- Instant switch: users are switched to another environment instantaneously.
- Instant rollback: we can easily go back to the previous version in an instant.
- Replacement: we can easily switch to the other environment if a data center containing our live environment goes down. This will work as long we have had the precaution of not putting blue and green in the same availability zone.
Disadvantages:
- Data Migration: database migrations are harder, even to the point of being a showstopper. Database schema changes must be forward and backward-compatible. We may need to move back and forth between the old and new versions
- Sudden Delays: If users are suddenly switched to a new environment, they might experience some slowness.
- Expenses: Compared to other methods, the blue-green deployments are more expensive. Provisioning infrastructure on-demand helps. But when we’re making several scaled-out deployments per day, the costs can snowball.
- Time & Effort: setting up the blue-green deployment process takes time and effort. The process is complex and has a great deal of responsibility. We may need to do many iterations before we get it working right.
- Handling transactions: while switching the environment, some user transactions will get interrupted.
- Shared services: databases and other shared services can leak information between blue and green. This could break the isolation rule and interfere with the deployment.
In this blog, we learned about how to deploy the application’s new versions without downtime, without affecting the performance ensuring user satisfaction.
Thank you. Hope the post is useful! See you again!!
