Blue Green Deployment is one of the mainstays of deployment strategies that conquers the limitations of traditional approach to application deployment. How much do you know about Blue Green Deployment? How is Blue Green Deployment in Drupal implemented?
Yes, you read that right. Having to take your application offline for updates or while launching a newer version is a daunting task and a real pain. True that you can mitigate this with scheduled downtimes, but that is not something that will bring make the customers happy. Some sites actually lose thousands of dollars every minute they are down! Should deployment or upgrading your application be the real reason behind your loss?
Learn about why blue green deployment is the best strategy to reduce downtime and mitigate other risks involved in application deployment. Discover more about blue green deployment & Drupal.
What is Blue-Green Deployment?
Blue-Green Deployment is a technique for releasing applications by shifting or moving the traffic between two identical environments running two different versions of an application.
In a brief, there is a version of an application, lets call it "blue version" in production. And then, there is a router that is used to route the traffic to the app. Now you need another version. the "green version" with some more goodies added, to be deployed. However, you also want to ensure that while this deployment is happening, a user can still look at your application, press a button or do whatever he wants, without your application going down! More like secretly deploying the "green version" while the "blue version" handles all the traffic in the meantime, before eventually swapping out the connections.
With near zero downtime release and rollback capabilities, the fundamental idea of the Blue-Green Deployment is to shift the traffic between two identical environments that are running two different versions of the application. While the current version of the application is represented by the Blue environment, the green one is staged running a different version.
Why Blue-Green Deployment?
One of the major challenges with automating the deployment process is the cut-over itself, i.e moving the application from the final stage of testing to the live stage. And this has to be taken care of quickly in order to minimize any sort of downtime. This is exactly what blue-green deployment does. With two production environments (as identical as possible in nature), at any given point of time, one of them is live. And as you prepare for a new release, you do all your testing on the other environment which is not live. Once you are ready to roll, all you have to do is switch the router so that all your traffic is directed towards your latest release & the other environment just goes idle.
Also, Blue-Green deployment provides one of the most important features, a rapid rollback. Suppose if anything goes wrong with your latest release, you just have to switch back the router. While there might still be an issue with the lost transactions when the faulty environment was live, you could also design it in a way that both of your environments are fed with the transactions and one acts as a backup for the other one.
How Blue-Green Deployment?
Now that we know about the two environments of Blue-Green Deployment, let us look at some of the best practices to implement the same.
Load Balancing over DNS Switching
Keep in mind that while switching environments, make your domain to eventually point to different servers. Instead of going to the DNS records & making changes in DNS management interface, use load balancing.
The problem with making changes in the DNS records will just result in a long traffic trail. This means that while some of your users will still be served by the old environment, you won't even have full control on where your traffic is routed to.
However, load balancers will allow you to set your new servers up immediately and you wouldn't have to depend on the DNS mechanism. This way, you will have full control on the traffic and you can be absolutely sure that all the traffic is routed to the new environment.
DO NOT switch all your servers at once. Execute a rolling update instead. That is, instead of switching over to the Green servers from the Blue ones all at once, work with an integrated environment. Add one new server, retire an old one. Repeat until every new server is in place. This will reduce your downtime by a huge margin!
While monitoring the live environment is obvious, you do not want to end up being caught off guard by not monitoring the other environment. Yes, the monitoring of the other environment is less critical. However, since the same environment can act as both states, you will need an easier way to switch the alerting between the two. Set up different API tokens for the two environments reporting back, or programatically change the alert policy on the environment when its role is changed/switched.
Manual set of actions will just increase your work. Instead, script every action in the switch process. Automating the switch process will result in a quicker, easier and safer implementation of Blue-Green Deployment.
Blue Green Deployment for Drupal Websites
- During code deployments, Drupal needs to run database updates to operate and this is a major problem since the Drupal updates sets the website in maintenance mode and your users are greeted with this beautiful white screen.
If the deployment fails, then a rollback is only possible by restoring the database from dump, considering the database schema may have been modified. This means downtime!
Solution: Blue Green Deployment!
Let us look at some of the infrastructure overview to implement Blue Green Deployment with Drupal. Any kind of ops in Drupal requires Nginx and a php server (to mainly run Drupal), we need a database, a file storage, some cache, and the stack is designed in a way that it is highly available.
With Blue Green Deployment, you need to deploy a new stack with a new codebase and copy all of your database and the different states from the previous codebase, preferably using Drush.
Once the two different stacks are set up, the staging stack has to be tested independently from the production stack. Basically, you need your users to go to the stack (production stack) and test out the version of the website that is deployed. And when the other version (the staging stack) is ready, you just need to flip the versions. Now the users are being directed to the new stack and the older version is available for testing.
Blue Green Deployment with Docker
Deployments in Drupal is not easy. While you have to make sure that the code is deployed, composer dependencies are handled, schema updates are up-to-date and all the caches are cleared, you also need to ensure that the "responsive website" is up and running. And what happens if there is a problem and the deployment fails? Do you rollback? Or stop the deployment?
The phrase you are looking for, is Blue Green Deployment
During Drupal deployment, Docker ensures an easy shift between applications, and makes it easy to build and run different versions of the same. On the EC2 instance, there is always a set of raised docker containers of blue and green, and nginx works as a reverse proxy server. Blue green deployment with Docker allows a user to build a Drupal website which runs parallel in the two different environments.
Blue Green Deployment with AWS
While historically, blue green deployment was not the first choice to deploy software on-premises because of its high cost and complexity involved, containers have changed this perception for good.
Containers ease the adoption of blue green deployment because of their easy package and consistent behaviour as they switch between environments. And to change the configuration of a container, you just have to update its dockerfile and rebuild and redeploy the container in place rather than updating the software.
Amazon ECS performs these rolling updates when you update an existing Amazon ECS service. The rolling update for ecs blue green deployment involves replacing the existing version of the container with the latest one. This number of containers that the Amazon ECS adds or removes during the update is controlled by adjusting the maximum and minimum number of healthy tasks allowed during the service deployments.Once the update the service's task definition is updated with the latest version of the container image, Amazon ECS automatically starts replacing the old version of the container with the latest one.
Blue green deployment with AWS ECS will also provide optimization benefits since you are not tied to the same set of resources. That is, when the performance envelope of the application changes from one version to the other, you simply launch the new environment with the optimized resources (can be fewer in number or a completely different set of resources).
Blue green deployment in AWS also fits well with the continuous integration and deployment workflows, keeping a check on their complexities by allowing deployment automation to consider fewer dependencies on an existing environment.
This solution allows the users to easily manage the deployment and scalability of web platforms without wasting any time. This deployment helps in configuring a high-availability environment that will run a Drupal website without any problems.