{"id":37326,"date":"2017-11-30T20:12:49","date_gmt":"2017-11-30T20:12:49","guid":{"rendered":"https:\/\/www.whizlabs.com\/?p=37326"},"modified":"2024-05-17T12:49:14","modified_gmt":"2024-05-17T07:19:14","slug":"blue-green-deployment","status":"publish","type":"post","link":"https:\/\/www.whizlabs.com\/blog\/blue-green-deployment\/","title":{"rendered":"AWS: Blue Green Deployment"},"content":{"rendered":"

Exam Objective<\/b><\/p>\n

The topic “Blue Green Deployment using Auto Scaling Launch Configurations” addresses the Continuous Delivery and Process Automation topic as highlighted in the AWS Blueprint<\/a> for the exam guide<\/p>\n

\"AWS<\/a><\/p>\n

One of the key requirements of this topic is the concept of Continuous Deployment. The Blue Green Deployment concept is an important concept. This now a widely held practice in many organizations that look towards continuous delivery.<\/p>\n

What is Blue Green Deployment?<\/h2>\n

The below diagram from AWS demonstrates the Blue Green deployment scenario.<\/p>\n

\"Blue<\/p>\n

Here the Blue environment is the production environment which is currently serving traffic to the end users. The Green environment is a parallel and duplicate environment which has the new release of the application. When the new application version needs to be released, the switch is made from the Blue environment to the Green environment. The users will then be directed to the new environment and get the new application version. The advantages of such a deployment are<\/p>\n

    \n
  1. Ease of deployment \u2013 Here the deployment of the new version is just a simple switch which can happen at the DNS level. This reduces the amount of downtime which would be rendered to the users when the application moves to the new version.<\/li>\n
  2. Risk reduction \u2013 Ideally before deployment the Green environment, a thorough check would be made to ensure that the environment was functionally working as per the requirements. This would make the release less prone to risk when the actual cutover is completed.<\/li>\n
  3. Easy to rollback \u2013 After the switch is made from the Blue environment to the Green environment, the Blue environment can be kept running until it is ensured that the Green environment is working as it should. This is so that if there are any issues with the newly deployed environment, it becomes easier to shift back to the older environment.<\/li>\n<\/ol>\n

    There are many ways to carry out Blue Green Deployment. This topic focuses on how it can be accomplished by modifying the launch configurations of the Autoscaling Group.<\/p>\n

    Implementing Blue Green Deployment with New Launch Configurations<\/b><\/h4>\n

    Now let\u2019s have a closer look at how we can achieve Blue Green deployments with a change in Launch configurations.<\/p>\n

    Step 1)<\/strong> Log into your AWS Console. Go to the EC2 section.<\/p>\n

    \"Auto<\/p>\n

    Step 2)<\/strong> Create a new launch configuration. Let\u2019s say a launch configuration is created with the Instance Type of t2.micro.<\/p>\n

    \"Creating<\/p>\n

    Step 3)<\/strong> Next, create an Autoscaling Group from the launch configuration. For the purpose of this demo, we can keep the initial number of instances to 2.<\/p>\n

    \"Autoscaling<\/p>\n

    So, in the above example, we have an Autoscaling group which has a Desired, Min and Max value of 2. You can also attach the Autoscaling Group to a load balancer if required.<\/p>\n

    If you were to the Instances section, you would see 2 instances InService.<\/p>\n

    \"Blue<\/p>\n

    Step 4)<\/strong> Now let\u2019s say you want to deploy the newer version of this application, but using a new Instance Type, let\u2019s say t2.small. Create a new Launch configuration. You can name this launch configuration as \u201cnewlaunch\u201d<\/p>\n

    Note:- Remember that you cannot change a launch configuration once it is created<\/b><\/em><\/p>\n

    \"Launch<\/p>\n

    Step 5)<\/strong> Now let\u2019s attach this new launch configuration to the Autoscaling Group.<\/p>\n

    Note:- Remember that the Autoscaling Group can only be associated with one launch configuration at a time.<\/b><\/em><\/p>\n

    Go to the details of the Autoscaling Group and click on the Edit button<\/p>\n

    \"Autoscaling<\/p>\n

    Step 6)<\/strong> Change the Launch configuration to the newly created Launch configuration and then click on the Save button<\/p>\n

    \"Launch<\/p>\n

    Step 7)<\/strong> Now increase the Max and Desired size of the Autoscaling Group to 4 by editing the Autoscaling Group. Then click on Save.<\/p>\n

    \"Autoscaling<\/p>\n

    Step 8)<\/strong> Now if you were to go to the Instances tab for your Autoscaling Group, you would see 2 new instances launching that are part of the new launch configuration.<\/p>\n

    \"AWS<\/p>\n

    This means that the ELB which is attached to the Autoscaling Group would now start registering the new instances<\/p>\n

    If you were to go to the ELB dashboard and check the ELB, you would see all four instances.<\/p>\n

    Step 9)<\/strong> Now to remove the older instances, you could either mark the older services in the Standby state by using the CLI so that requests are not routed to these instances. Or you can even terminate the instances if required.<\/p>\n

    Or you can perform the following steps to change the size of the Autoscaling Group.<\/p>\n

    \"Azure<\/p>\n

    Go ahead and change the Max and Desired values of the Autoscaling group back to 2.<\/p>\n

    You would then start seeing that the Instances of the \u201cInitial\u201d Launch configuration start getting terminated. This is because the default termination policy of the Autoscaling Group during a scale in the process is to remove the instances which have the older launch configuration.<\/p>\n

    \"Cloud<\/p>\n

    If you ever need to rollback, then you can do the vice versa of the above step1<\/p>\n

    1) Since you still have the older launch configuration, you can attach the Autoscaling Group to that launch configuration.<\/p>\n

    2) Change the Desired and Max values to 4 of the Autoscaling Group<\/p>\n

    3) Once the instances of the older launch configuration have been launched, change the Desired and Max values to 2 of the Autoscaling Group<\/p>\n

    Final Points to Remember\u00a0<\/b><\/h4>\n

    1) The Blue environment is the production environment which is currently serving traffic to the end users<\/p>\n

    2) The Green environment is a parallel and duplicate environment which has the new release of the application<\/p>\n

    3) The Blue Green deployment has the following advantages<\/p>\n