Before we discuss the Blue Green Deployment in Cloud Foundry, here are a couple of prerequisites:
- Account in Pivotal web services
- Successfully deployed application in cf pivotal
- Hands-on CF’s cl
- Writing of manifest.yml files (Added advantage)
What is Blue-Green deployment?
Blue-green deployment is a technique that reduces downtime and risk by running two identical production environments called Blue and Green.
At any given time, only one of the environments will be live, with the live environment serving all production traffic. For this example, Blue is currently live and Green is idle.
As you prepare a new version of your software, deployment and the final stage of testing takes place in the environment that is not live – in this example, Green. Once you have deployed and fully tested the software in Green, you switch the router so all the incoming requests now go to Green instead of Blue. Green is now live, and Blue is idle.
This technique can eliminate downtime due to application deployment. In addition, blue-green deployment reduces risk. If something unexpected happens with your new version of Green, you can immediately roll back to the last version by switching back to Blue.
If your app uses a relational database, blue-green deployment can lead to discrepancies between your Green and Blue databases during an update. To maximise data integrity, configure a single database for backwards and forward compatibility.
In the following tutorial, we are going to take an example of “blue” project deployed in Pivotal Cloud Foundry.
In the above screen, observe that the blue app is running in the development space.
We’ve made a few changes to the blue application locally so the new version of the app is available on our local machine. To push a new project with “Zero down time”, follow the below procedure. In this example, we’ve defined the jar or war file path in manifest.yml file. If you haven’t specified, use the following:
cf push (app-name) -p path/to/war or jar -n (route-name)
From the above image see the route-name of the app:
Now push the latest app with name green and different route-name
-> cf push green -n wavelabs-temp
In the above screen, you can observe that the green project is deployed with route name wavelabs-temp.cfapps.io
- Map the route of the blue project to green project.
- Route of the blue project is wavelabs.
- Route of the green project is wavelabs-temp
- Change the green project’s route also as wavelabs using the command:
>cf map-route green cfapps.io -n wavelabs
Now check the routes screen in the Development space:
-> wavelabs.cfapps.io shared by both blue and green projects.
So, the router sends the traffic to both blue and green projects. At this stage, some users experience old version of the project and some users experience new version of the project. Sometimes, it’s an added advantage as any problem with the new version project stability can be removed from mapping.
The green project also has its own route name wavelabs-temp.cfapps.io
Now un-map the wavelabs.cfapps.io to blue project using the command:
cf unmap-route blue cfapps.io -n wavelabs
This will un-map the route to blue project, making all requests to go through the green project.
In the below screen check the blue project routes, they’re empty.
Let’s check the green project routes.
It has wavelabs.cfapps.io and wavelabs-temp.cfapps.io
Now, let’s remove the unused wavelabs-temp.cfapps.io route to green project using command:
cf unmap-route green cfapps.io -n wavelabs-temp
Now green has only wavelabs.cfapps.io mapping.
We’re successfully able to deploy the latest version of the project with zero down-time.
Delete the unused routes in space using command:
We can delete the previous blue project also:
cf delete blue -f
Canary blue-green deployments:
In this canary blue-green deployment, we directly map the new version of project to the older version of route.
Suppose blue project mapping is → wavelabs.cfapps.io, we directly deploy green project also with mapping wavelabs.cfapps.io
But initially we have more instances to the older project (blue) and one instance to new project (green). Now scale the traffic by increasing the number of instances of new project (green) and decreasing number of instances of older project (blue). Finally, remove the older project (blue).
Here’s a brief procedure:
- Step 1: You have a running blue project with instances 4
- Step 2: Deploy the green project with number of instances 1 using command
cf push green -n wavelabs -i 1
- Step 3: Start scaling the traffic as follows
cf scale green -i 2
cf scale blue -i 3
b) cf scale green -i 3
cf scale blue -i 2
c) cf scale green -i 4
cf scale blue -i 1
Now the newer project (green) has four running instances while the old one has just one.
Remove the old project:
cf delete blue -f
With this, we’ve achieved a zero downtime deployment.
Plug-in for blue-green deployment:
cf-blue-green-deploy is a plugin for the CF command line tool that automates a few steps involved in the zero-downtime deployment.
The plugin takes care of the following steps packaged into one command:
- Pushes the current version of the app with a new name
- Optionally runs smoke tests against the newly pushed app to verify the deployment
- If smoke tests fail, newly pushed app gets marked as failed and is left around for investigation
- If smoke tests pass, remap the routes from the currently live app to the newly deployed app
- Cleans up versions of the app that are no longer in use.Installment:cf add-plugin-repo CF-Community https://plugins.cloudfoundry.org
cf install-plugin blue-green-deploy -r CF-CommunityDeployment:cf blue-green-deploy app_nameDeploying with specific manifest file:cf blue-green-deploy app_name -f <path to manifest>
After a successful running of this command, it’s going to create your old project as app_name-old and it also removes all the route mappings to this project.