Blue-green deployment

Blue-green deployment is a technique that's used to reduce downtime to deploy a new version of the application. Martin Fowler described this technique at the beginning of 2010 on his site at https://martinfowler.com/bliki/BlueGreenDeployment.html. The following is a quote taken from this site:

"One of the challenges with automating deployment is the cut-over itself, taking software from the final stage of testing to live production. You usually need to do this quickly in order to minimize downtime. The blue-green deployment approach does this by ensuring you have two production environments, as identical as possible. At any time one of them, let's say blue for the example, is live. As you prepare a new release of your software you do your final stage of testing in the green environment. Once the software is working in the green environment, you switch the router so that all incoming requests go to the green environment - the blue one is now idle."

Here is a logical architecture of the blue-green deployment:

The key point in blue-green deployment is to have a route or load balancer that's able to switch from the blue environment to the green environment on demand:

This will surely have some benefits, such as zero downtime and a ready-to-use rollback environment. On the other hand, this new environment will also be fresh and new in terms of session application, thus all user sessions will be lost. To mitigate such loss, setting the application in read-only mode could help, or waiting for all of the sessions to drain.

However, blue-green deployment is about testing the production environment, not testing the application itself, which should be done in test and/or UAT.

Let's try a blue-green deployment with an example:

  1. First of all, if you don't have your OpenShift platform up and running, start it as follows:
oc cluster up
  1. Once everything has started, open your browser and point it to https://127.0.0.1:8443/console/.
  1. Log in as developer, and click on the Nginx icon in Browse Catalog, as follows:

  1. In the pop-up wizard, click Next and fill in the next form, as shown in the following screenshot:

  1. In the last step, the platform confirms the creation of the application, which is already being deployed in your project.
  1. Click on the link labeled Continue to the project overview to see its overview and progress:

The overview of the application created
  1. Once the application has been successfully deployed in the platform as a container in a pod, click on the route  stating http://blue-green-app-myproject.127.0.0.1.nip.io, which should load our example application.

The page should display some text in blue, as follows:

  1. To simulate our new version of the application, and thus simulate a switch between the two versions—the blue (the one we just deployed) and the green (the one we are about to deploy)—go back to the catalog and select the Nginx icon, and click Next in the pop-up wizard.
  2. This time, click on the Advanced options link and fill in the form, as follows:

The Advanced options page

The difference from the previous deployment is, of course, the name, which is blue-green-app-2. Furthermore, the deployment is now pointing to the branch named green of our Git repository, and so we do not create a route automatically for our application.

In this way, the application will not be exposed externally. However, without sharing the route, users will not know the new URL, but as this is an automated task, the URL is predictable based on application names, and curious users might be able to spoil your new features. For this reason, we will disable automatic route creation:

  1. Once the application has been deployed, we can test how it behaves in the new environment, and once we are satisfied, we can proceed with the switchover.

To achieve that, we click on the left-hand side vertical menu Applications | Routes and then click on the route named blue-green-app.

We should now see the detail of the route, as follows:

  1. On the page, in the top-right corner, there is a drill-down menu called Actions; click on it and select Edit.

On the Edit page, we change all the settings for the route, even the service layer that is pointing to, which is the one that we need to change to switch from the blue environment to the green environment, as depicted in the following screenshot:

  1. Then, click Save, and refresh the page of our application. We should now see the web page displaying some text in green, as follows:

The URL for your current application didn't change, and the new fancy version is finally online.

Congratulations! You successfully performed a blue-green deployment.

Remember that if the data model between the two version changes even slightly, the blue-green deployment should be done in a different way, that is, by putting the blue version of the application in read-only mode and waiting for it to drain all the pending write requests, then switching to the new green version.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset