This lab is part of the DevOps Engineer Learning Path - DevOps Fundamentals course made by Cloud Academy.
The objective of this lab is to create a rolling and a blue-green deployment in order to better understand the differences between the two. Let's start by describing what those two types of deployments are.
Rolling Deployment
"... is a deployment strategy that slowly replaces previous versions of an application with new versions of an application by completely replacing the infrastructure on which the application is running." AWS (source)
This strategy aims to gradually update or replace the application gradually in batches until all of the servers are updated. It reduces the downtime and the risk of unavailability when compared to an all-at-once deployment. The deployment can also be paused or rolled back in case of errors. However, rolling deployments generally take longer to complete and can result in two versions of the app being available to users at the same time.
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." - AWS
This strategy aims to enable quick deployment of a new version of the application without any downtime as the blue environment can already be tested and validated before switching to green and routing users to it. However, it is more resource intensive since both environments need to mirror each other.
Going into the Lab
The following illustration shows the app architecture with a blue-green deployment strategy. The app has two identical versions with one being used as the live environment (green) and the test/dev environment (blue) wherein the V2 of the app is in the blue meaning the update was already made. Users can access the app via Route 53 (R53) and R53 is used to route traffic to the active load balancer. However, the lab does not go into R53 routing.
The lab uses a pre-built to-do list application using Node.js. Found below is the screenshot of the webpage of the app.
The first step of the lab is to create the web app in Elastic Beanstalk (EB) using the pre-built code. Once uploaded to EB, a custom configuration is used to configure load balancing and auto-scaling. Then, rolling updates and deployments are set to, "rolling" instead of, "all at once" which causes downtime for the application when updates are pushed. Batch size is set to 30% which determines how many instances are updated at a time.
In the Network section, a separate VPC is used for the application for easier management. The CIDR block is set to 10.0.0.0/16, load balancer subnets 10.0.100.0/24 (us-west-2a) and 10.0.101.0/24 (us-west-2b) are selected as well since the application load balancer requires two subnets in different AZs. Database subnets are set with CIDR blocks of 10.0.1.0/24 and 10.0.2.0/24.
These settings allow for the application to be accessible only through the load balancer. However, this only uses one availability zone for the application for lab purposes.
Security groups could be set to none as EB automatically creates a security group for the instances and load balancer to allow for inbound traffic on port 80 if none is set. After this step, the EB could be created.
Once done, the application could be accessed through the URL on the upper left hand of the image and is shown below.
Let's consider this the live URL:
http://myapp-env.eba-cwpg2ahw.us-west-2.elasticbeanstalk.com/#/
Deploying a new version of the app
This step uses a rolling deployment strategy which upgrades a portion of the instances into the new version thereby rendering them unusable. The update continues one after the other until all instances are serving the new version of the app.
Doing this with EB is quite simple. The new version of the app is simply uploaded onto EB and with the proper settings in place, the Rolling deployment proceeds until finished.
Refreshing the previous window will display the new version of the app:
Since there is only 1 instance running, the only instance will be updated right away. If the lab demonstrated multiple instances running and a rolling deployment was commenced, the old and new applications may be both accessible at the same time.
Preparing a Blue Green Deploy
The blue-green deployment strategy entails that two environments are working at the same time when the deployment process is active. One is being updated and the other is the live accessible version. In the case of this lab, the blue environment is the original and the green one is created running the new version. Once the green environment is running, the traffic can be routed to that environment.
The first step is to clone the environment:
The cloned environment will be used as the green environment where the new version of the app will be created.
The image above shows the creation of the environment for the new version of the app.
Once created, the new environment will have the same application as the original one since it's a clone. But it is now accessible for the deployment of the new application.
http://myapp-env-1.eba-cwpg2ahw.us-west-2.elasticbeanstalk.com/#/
Both versions of the applications are still accessible and imaginarily, with traffic still being routed to the original one.
Performing a DNS Swap
This step is where the DNS entry for the two environments (blue/original, green/new) will be swapped so that the new environment will be accessible to the clients.
The following images show the steps done to interchange the DNS entries.
Using the (live) URL of the original app, the new version is now accessible. As you can notice below, the title changed to the new version but kept the data of the original app. In my opinion, this should not be the case but there may be a database setting that needs to be modified. At this point, my time for the simulation has ended and I will have to redo the lab to test the issue. I have reached out to Cloud academy for support as well and will update this blog once I have an answer.
Update from CA (March 27, 2023)
The code of the app is beyond the scope of the lab but it would be very helpful to have used a database as the backend of the app to ensure consistency of the deployment. It would also have been an opportunity to see how the applications connect to a database considering the deployments. I think that clearing the browser's cache would solve this issue of content remaining in the old deployment. I forwarded my feedback to CA.
Cleaning Up Old Resources
Currently, there are still two versions of the app that are running and can run up costs in the AWS account. Eventually, the environment with the old version has to be terminated once it is assured that the new version of the app is working as expected for all users.
To terminate the unused environment, it simply has to be terminated from the console. It can be confirmed that the compute resources, in this case an EC2 instance, is not present anymore in the account.
That's it! The lab is a simple demonstration of how rolling and blue-green deployments can be done using AWS Elastic Beanstalk. The article still has t o be updated with why old data showed up in the new app but will have to do more research, possibly redo the app, and wait for advice from Cloudacademy.