Skip to content

Latest commit

 

History

History
284 lines (238 loc) · 13.9 KB

File metadata and controls

284 lines (238 loc) · 13.9 KB

Blue-Green Deployment Strategy

Blue-green deployment is a technique that reduces downtime and risk by running two identical productive environments called Blue and Green.

At any time, only one of the environments is live, with the live environment serving all productive 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 incoming requests now go to Green instead of Blue. 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 acomplish blue-green deployment using MTA.

MTA blue-green deployment is separeted in three phases. First phase is used to setup the next color environment, in order to be tested. The new environment version, in this case GREEN, is not accessible on the productive routes but on temporary -idle routes.

After this phase, the process enters second phase, so called testing phase. During that phase the user can verify that the new version of environment is operational by executing simple smoke tests or extensive testing. The user can decide to skip this phase with specifying the option '--skip-testing-phase'. The option is useful for CI/CD or other automated approaches.

During third phase all new applications are assigned to productive routes and the new MTA color become productive.

Requirements

Official documemtation

Try out

The example will demonstrate blue-green deployment of one MTA comprised of two applications. The first applcation, called "hello-backend", serves as backend 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 frontend, backend and backing services. In the example "hello-backend" will play the combined role between backend and backing services, where the customer data is stored.

In terms of the example, we are using Java applications which communicate using the REST interface. Both applications are simple web projects containing only one servlet.

Table 1. Applications REST endpoints and logic
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

Execute initial blue-green deployment of the BLUE environment

Initial blue green deployment is very similar to standard deployment because there are no existing applications. One difference is that temporary routes will be added during the deployment. Finally, the standard routes are assigned to the applications.

At the end of this part, you will have a similar environment:

initial bg deploy blue

Deploy

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 deploymnet is trigger.

Using existing .mtar

  $ cf deploy hello-blue/hello.mtar -f --strategy blue-green
  ...
  No deployed MTA detected - this is initial deployment
  ...
  Starting application "hello-backend-idle"...
  Application "hello-backend-idle" started and available at "<org>-<space>-hello-backend-idle.cfapps.sap.hana.ondemand.com"
  ...
  Starting application "hello-router-idle"...
  Application "hello-router-idle" started and available at "<org>-<space>-hello-router-idle.cfapps.sap.hana.ondemand.com"
  ...
  Application "hello-backend-idle" started and available at "<org>-<space>-hello-backend.cfapps.sap.hana.ondemand.com"
  ...
  Application "hello-router-idle" started and available at "<org>-<space>-hello-router.cfapps.sap.hana.ondemand.com"
  ...
  Renaming application "hello-backend-idle" to "hello-backend"...
  Renaming application "hello-router-idle" to "hello-router"...
  ...

Using deploy from directory with .mtad

The approach will use deployment descriptor hello-blue/mtad.yaml and already built application bineries hello-blue/router.war and hello-blue/backend.war

  $ cf deploy hello-blue/ -f --strategy blue-green

Build and deploy

The approach will use development descriptor hello-blue/mta.yaml to build binaries from source code folders hello-blue/router/ and hello-blue/backend/. Then the built MTAR will be deployed.

Note
The Cloud MTA Build Tool is using 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
  $ cf deploy hello-blue/mta_archives/hello_0.1.0.mtar --strategy blue-green

Examine the result

Verify that the front-end hello-router returns BLUE:

  $ curl https://<org>-<space>-hello-router.cfapps.sap.hana.ondemand.com/router
  BLUE

Execute blue-green deployment of the GREEN environment and entering the testing phase

At the end of this part, you will have a similar environment:

bg deploy green validation

Deploy

You can try 3 different approaches, that will lead to the same result

Using existing .mtar

  $ cf deploy hello-green/hello.mtar -f --strategy blue-green
  ...
  Renaming application "hello-backend" to "hello-backend-live"...
  Renaming application "hello-router" to "hello-router-live"...
  ...
  Starting application "hello-backend-idle"...
  Application "hello-backend-idle" started and available at "<org>-<space>-hello-backend-idle.cfapps.sap.hana.ondemand.com"
  ...
  Starting application "hello-router-idle"...
  Application "hello-router-idle" started and available at "<org>-<space>-hello-router-idle.cfapps.sap.hana.ondemand.com"
  Process has entered testing phase. After testing your new deployment you can resume or abort the process.
  Use "cf deploy -i xxxx -a abort" to abort the process.
  Use "cf deploy -i xxxx -a resume" to resume the process.
  Hint: Use the '--skip-testing-phase' option of the deploy command to skip this phase.

Using deploy from directory with .mtad

The approach will use the deployment descriptor hello-green/mtad.yaml and already built application binaries hello-green/router.war and hello-green/backend.war

  $ cf deploy hello-green/ -f --strategy blue-green

Build and deploy

The approach will use the development descriptor hello-green/mta.yaml to build binaries from the source code folders hello-green/router/ and hello-green/backend/. Then the built MTAR will be deployed.

  $ mbt build -p cf -s hello-blue
  $ cf deploy hello-blue/mta_archives/hello_0.1.0.mtar --strategy blue-green

Examine the result

Verify that both application versions are now available

  $ cf a
Getting apps in org xxx / space xxx as xxx...
OK

name                 requested state   instances   memory   disk   urls
hello-router-live    started           1/1         512M     256M   <org>-<space>-hello-router.cfapps.sap.hana.ondemand.com
hello-backend-idle   started           1/1         512M     256M   <org>-<space>-hello-backend-idle.cfapps.sap.hana.ondemand.com
hello-router-idle    started           1/1         512M     256M   <org>-<space>-hello-router-idle.cfapps.sap.hana.ondemand.com
hello-backend-live   started           1/1         512M     256M   <org>-<space>-hello-backend.cfapps.sap.hana.ondemand.com

Verify that the BLUE environment is still the productive one:

  $ curl https://<org>-<space>-hello-router.cfapps.sap.hana.ondemand.com/router
  BLUE

Verify that the GREEN environment can be accessed and validated on the temporary -idle routes:

  $ curl https://<org>-<space>-hello-router-idle.cfapps.sap.hana.ondemand.com/router
  GREEN
Note
In case of a problem, the deploy can be aborted without influencing the productive environment. To stop the process copy-paste the suggested command by MTA CF CLI plugin: cf deploy -i xxxx -a abort

Make the GREEN environment the productive one

At some point in time, you will have a similar environment, where both BLUE and GREEN applications are mapped to productive routes.

bg deploy green temp

At the end of this part, you will have a similar environment:

bg deploy green final
  $ cf deploy -i 1b59ca36-007e-11ea-bbed-eeee0a9e6b19 -a resume
Executing action 'resume' on operation xxxx...
...
Updating application "hello-backend-idle"...
Stopping application "hello-backend-idle"...
Starting application "hello-backend-idle"...
Application "hello-backend-idle" 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-idle"...
Updating application "hello-router-idle"...
Stopping application "hello-router-idle"...
Starting application "hello-router-idle"...
Application "hello-router-idle" 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-idle"...
Renaming application "hello-backend-idle" to "hello-backend"...
Renaming application "hello-router-idle" to "hello-router"...
Deleting routes for application "hello-router-live"...
Deleting routes for application "hello-backend-live"...
Stopping application "hello-router-live"...
Deleting application "hello-router-live"...
Stopping application "hello-backend-live"...
Deleting application "hello-backend-live"...
Process finished.

Examine the result

Verify that the old BLUE applications are deleted and the new GREEN applications are assigned to productive routes:

  $ cf a
Getting apps in org xxx / space xxx as xxx...
OK

name            requested state   instances   memory   disk   urls
hello-backend   started           1/1         512M     256M   <org>-<space>-hello-backend.cfapps.sap.hana.ondemand.com
hello-router    started           1/1         512M     256M   <org>-<space>-hello-router.cfapps.sap.hana.ondemand.com

Verify that the GREEN environment is the productive one and serves on the productive routes:

  $ curl https://<org>-<space>-hello-router.cfapps.sap.hana.ondemand.com/router
  GREEN

Execute blue-green deployment of the BLUE environment without confirmation

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.

At the end of this part, you will have a similar environment:

initial bg deploy blue
  $ cf deploy hello-blue -f --strategy blue-green --skip-testing-phase
...
Renaming application "hello-backend" to "hello-backend-live"...
Renaming application "hello-router" to "hello-router-live"...
...
Starting application "hello-backend-idle"...
Application "hello-backend-idle" started and available at "<org>-<space>-hello-backend-idle.cfapps.sap.hana.ondemand.com"
...
Starting application "hello-router-idle"...
Application "hello-router-idle" started and available at "<org>-<space>-hello-router-idle.cfapps.sap.hana.ondemand.com"
...
Application "hello-backend-idle" started and available at "<org>-<space>-hello-backend.cfapps.sap.hana.ondemand.com"
...
Starting application "hello-router-idle"...
Application "hello-router-idle" started and available at "<org>-<space>-hello-router.cfapps.sap.hana.ondemand.com"
...
Renaming application "hello-backend-idle" to "hello-backend"...
Renaming application "hello-router-idle" to "hello-router"...
...
Process finished.
Use "cf dmol -i xxx" to download the logs of the process.

Examine the result

Verify that the old GREEN applications are deleted and the new BLUE applications are assigned to productive routes:

  $ cf a
Getting apps in org xxx / space xxx as xxx...
OK

name            requested state   instances   memory   disk   urls
hello-backend   started           1/1         512M     256M   <org>-<space>-hello-backend.cfapps.sap.hana.ondemand.com
hello-router    started           1/1         512M     256M   <org>-<space>-hello-router.cfapps.sap.hana.ondemand.com

Verify that the BLUE environent is the productive one and serves on the productive routes:

  $ curl https://<org>-<space>-hello-router.cfapps.sap.hana.ondemand.com/router
  BLUE