- Requirements
- Try it out
Blue-green deployment is a technique that reduces downtime and risk by running two identical production environments called Blue and Green.
At any time, only one of the environments is live, with the live environment serving all production traffic. In this example Blue is live and Green is idle.
As you prepare a new version of your software, the deployment and final stage of testing take place in a non-live environment: in this example, Green. This way, your regular operations on Blue, containing the current version, stay uninterrupted. Once you have deployed and fully tested the software in Green, you switch the router so all incoming requests now go to Green instead of Blue. In other words - Green is now live, and Blue is idle.
This technique can eliminate downtime due to app deployment. In addition, blue-green deployment reduces risk: if something unexpected happens with your new version on Green, you can immediately roll back to the last version by switching back to Blue.
The example will demonstrate how to accomplish blue-green deployment using an MTA.
MTA blue-green deployment is separeted in two phases:
The first phase, known as validation, involves setting up the new color environment, in this case Green, for testing. Green is not accessible via the production routes but rather via temporary -idle
routes. The purpose of the validation phase is to ensure the new version of the environment is fully operational.
During the second phase all new applications are assigned to production routes and the new MTA color, in this case Green, becomes productive.
-
Awarenes of blue-green deployment in Cloud Foundry: Using Blue-Green Deployment to Reduce Downtime and Risk
-
Installed MultiApps CF CLI Plugin v2.3.0 and above
-
Installed Maven
-
Installed Cloud MTA Build Tool ## Official documemtation
-
SAP Help Portal: Legacy Blue-Green Deployment
The example will demonstrate blue-green deployment of one MTA comprised of two applications. The first application, called hello-backend
, serves as back end and the second one, called hello-router
, serves as front end.
The idea is to have sample MTA which seems very similar to standard business applications that are comprised of front end, back end and backing services. In the example hello-backend
will play the combined role of back end and backing services, where the customer data is stored.
In terms of the example, we are using Java applications which communicate using REST interface. Both applications are simple web projects containing only one servlet.
Application Color | hello-router | hello-backend |
---|---|---|
blue |
GET /router → calls <hello-backend>/backend |
GET /backend → returns BLUE |
green |
GET /router → calls <hello-backend>/backend |
GET /backend → returns GREEN |
Initial blue green deployment is very similar to standard deployment because there are no previously existing applications. One difference is that temporary routes will be added during the deployment. Finally, the standard routes are assigned to the applications.
In the end of this part, you will have a similar environment:
You can try 3 different approaches that will lead to the same result and the same output during the deployment. The differences are how the deployment is triggered.
$ cf bg-deploy hello-blue/hello.mtar -f
...
No deployed MTA detected - this is initial deployment
New MTA color: BLUE
...
Starting application "hello-backend-blue"...
Application "hello-backend-blue" started and available at "<org>-<space>-hello-backend-idle.cfapps.sap.hana.ondemand.com"
...
Starting application "hello-router-blue"...
Application "hello-router-blue" started and available at "<org>-<space>-i076083-2-hello-router-idle.cfapps.sap.hana.ondemand.com"
...
Application "hello-backend-blue" started and available at "<org>-<space>-hello-backend.cfapps.sap.hana.ondemand.com"
...
Application "hello-router-blue" started and available at "<org>-<space>-hello-router.cfapps.sap.hana.ondemand.com"
The approach uses deployment descriptor hello-blue/mtad.yaml
and already built application binaries hello-blue/router.war
and hello-blue/backend.war
:
$ cf bg-deploy hello-blue/ -f
The approach uses development descriptor hello-blue/mta.yaml
to build bineries from source code folders hello-blue/router/
and hello-blue/backend/
:
Note
|
The Cloud MTA Build Tool is usiing maven to build Java applications by default. |
$ mbt build -p cf -s hello-blue
...
INFO validating the MTA project
INFO building the "hello-router" module...
INFO executing the "mvn -B package" command..
...
INFO the build results of the "hello-router" module will be packed and saved in the "/mta_examples/blue-green-deploy/hello-blue/.hello-blue_mta_build_tmp/hello-router" folder
INFO building the "hello-backend" module...
INFO executing the "mvn -B package" command...
...
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.301 s
[INFO] Finished at: xxxx
[INFO] ------------------------------------------------------------------------
INFO the build results of the "hello-backend" module will be packed and saved in the "/mta_examples/blue-green-deploy/hello-blue/.hello-blue_mta_build_tmp/hello-backend" folder
INFO generating the metadata...
INFO generating the MTA archive...
INFO the MTA archive generated at: /mta_examples/blue-green-deploy/hello-blue/mta_archives/hello_0.1.0.mtar
The built MTAR archive is then deployed:
```bash
$ cf bg-deploy hello-blue/mta_archives/hello_0.1.0.mtar
In the end of this part, you wil have a similar environment:
You can try 3 different approaches, that will lead to the same result.
$ cf bg-deploy hello-green/hello.mtar -f
...
Deployed MTA color: BLUE
New MTA color: GREEN
...
Starting application "hello-backend-green"...
Application "hello-backend-green" started and available at "<org>-<space>-hello-backend-idle.cfapps.sap.hana.ondemand.com"
...
Starting application "hello-router-green"...
Application "hello-router-green" started and available at "<org>-<space>-hello-router-idle.cfapps.sap.hana.ondemand.com"
Process has entered validation phase. After testing your new deployment you can resume or abort the process.
Use "cf bg-deploy -i xxxx -a abort" to abort the process.
Use "cf bg-deploy -i xxxx -a resume" to resume the process.
Hint: Use the '--no-confirm' option of the bg-deploy command to skip this phase.
This approach uses deployment descriptor hello-green/mtad.yaml
and already built application bineries hello-green/router.war
and hello-green/backend.war
:
$ cf bg-deploy hello-green/ -f
Verify that both application version are now available:
$ cf a
Getting apps in org xxx / space xxx as xxx...
OK
name requested state instances memory disk urls
hello-router-blue started 1/1 512M 256M <org>-<space>-hello-router.cfapps.sap.hana.ondemand.com
hello-backend-green started 1/1 512M 256M <org>-<space>-hello-backend-idle.cfapps.sap.hana.ondemand.com
hello-router-green started 1/1 512M 256M <org>-<space>-hello-router-idle.cfapps.sap.hana.ondemand.com
hello-backend-blue started 1/1 512M 256M <org>-<space>-hello-backend.cfapps.sap.hana.ondemand.com
Verify that BLUE environment is still the productive one:
$ curl https://<org>-<space>-hello-router.cfapps.sap.hana.ondemand.com/router
BLUE
Verify that GREEN environment can be accessed and validated on temporary -idle
routes:
$ curl https://<org>-<space>-hello-router-idle.cfapps.sap.hana.ondemand.com/router
GREEN
Note
|
In case of a problem, the bg-deploy can be aborted without influencing the production environment. To stop the process copy-paste the suggested command by MTA CF CLI plugin: cf bg-deploy -i xxxx -a abort
|
At some point in time, you wil have a similar environment, where both BLUE and GREEN applications are mapped to production routes.
In the end of this part, you wil have similar environment:
$ cf bg-deploy -i 1b59ca36-007e-11ea-bbed-eeee0a9e6b19 -a resume
Executing action 'resume' on operation xxxx...
...
Updating application "hello-backend-green"...
Stopping application "hello-backend-green"...
Starting application "hello-backend-green"...
Application "hello-backend-green" started and available at "<org>-<space>-hello-backend.cfapps.sap.hana.ondemand.com"
Publishing publicly provided dependency "hello:backend"...
Publishing publicly provided dependency "hello:hello-backend"...
Deleting discontinued configuration entries for application "hello-backend-green"...
Updating application "hello-router-green"...
Stopping application "hello-router-green"...
Starting application "hello-router-green"...
Application "hello-router-green" started and available at "<org>-<space>-hello-router.cfapps.sap.hana.ondemand.com"
Publishing publicly provided dependency "hello:hello-router"...
Deleting discontinued configuration entries for application "hello-router-green"...
Deleting routes for application "hello-router-blue"...
Deleting routes for application "hello-backend-blue"...
Stopping application "hello-router-blue"...
Deleting application "hello-router-blue"...
Stopping application "hello-backend-blue"...
Deleting application "hello-backend-blue"...
Process finished.
Verify that old BLUE applications are deleted and new GREEN applications are assigned to production routes:
$ cf a
Getting apps in org xxx / space xxx as xxx...
OK
name requested state instances memory disk urls
hello-backend-green started 1/1 512M 256M <org>-<space>-hello-backend.cfapps.sap.hana.ondemand.com
hello-router-green started 1/1 512M 256M <org>-<space>-hello-router.cfapps.sap.hana.ondemand.com
Verify that GREEN environent is the production one and serves on the production routes:
$ curl https://<org>-<space>-hello-router.cfapps.sap.hana.ondemand.com/router
GREEN
There is an option to run end-to-end blue-green deployment without user interaction. The option is useful for CI and CD, where one MTA is continuously re-deployed without downtime.
In the end of this part, you wil have similar environment:
$ cf bg-deploy hello-blue -f --no-confirm
...
Deployed MTA color: GREEN
New MTA color: BLUE
...
Starting application "hello-backend-blue"...
Application "hello-backend-blue" started and available at "deploy-service-i076083-2-hello-backend-idle.cfapps.sap.hana.ondemand.com"
...
Starting application "hello-router-blue"...
Application "hello-router-blue" started and available at "deploy-service-i076083-2-hello-router-idle.cfapps.sap.hana.ondemand.com"
...
Application "hello-backend-blue" started and available at "deploy-service-i076083-2-hello-backend.cfapps.sap.hana.ondemand.com"
...
Starting application "hello-router-blue"...
Application "hello-router-blue" started and available at "deploy-service-i076083-2-hello-router.cfapps.sap.hana.ondemand.com"
...
Process finished.
Use "cf dmol -i xxx" to download the logs of the process.
Verify that old GREEN applications are deleted and new BLUE applications are assigned to production routes:
$ cf a
Getting apps in org xxx / space xxx as xxx...
OK
name requested state instances memory disk urls
hello-backend-blue started 1/1 512M 256M <org>-<space>-hello-backend.cfapps.sap.hana.ondemand.com
hello-router-blue started 1/1 512M 256M <org>-<space>-hello-router.cfapps.sap.hana.ondemand.com
Verify that BLUE environent is the production one and serves on the production routes:
$ curl https://<org>-<space>-hello-router.cfapps.sap.hana.ondemand.com/router
BLUE