OpenShift Container Platform and Kubernetes give application instances time to shut down before removing them from load balancing rotations. However, applications must ensure they cleanly terminate user connections as well before they exit. 

On shutdown, OpenShift Container Platform sends a TERM  signal to the processes in the container. Application code, on receiving SIGTERM , stop accepting new connections. This ensures that load balancers route traffic to other active instances. The application code then waits until all open connections are closed, or gracefully terminate individual connections at the next opportunity, before exiting. 

After the graceful termination period expires, a process that has not exited is sent the KILL  signal, which immediately ends the process. The terminationGracePeriodSeconds  attribute of a pod or pod template controls the graceful termination period (default 30 seconds) and can be customized per application as necessary. 

## 3.4.4. Blue-green deployments 

Blue-green deployments involve running two versions of an application at the same time and moving traffic from the in-production version (the blue version) to the newer version (the green version). You can use a rolling strategy or switch services in a route. 

Because many applications depend on persistent data, you must have an application that supports N-1 compatibility , which means it shares data and implements live migration between the database, store, or disk by creating two copies of the data layer. 

Consider the data used in testing the new version. If it is the production data, a bug in the new version can break the production version. 

## 3.4.4.1. Setting up a blue-green deployment 

Blue-green deployments use two DeploymentConfig  objects. Both are running, and the one in production depends on the service the route specifies, with each DeploymentConfig  object exposed to a different service. 

## NOTE 

Routes are intended for web (HTTP and HTTPS) traffic, so this technique is best suited for web applications. 

You can create a new route to the new version and test it. When ready, change the service in the production route to point to the new service and the new (green) version is live. 

If necessary, you can roll back to the older (blue) version by switching the service back to the previous version. 

## Procedure 

1. Create two independent application components. 

a. Create a copy of the example application running the v1  image under the example-blue service: 

$ oc new-app openshift/deployment-example:v1 --name=example-blue 

b. Create a second copy that uses the v2  image under the example-green  service: 

