Blue-Green deployment with Cloud Foundry

You have a fully automated deployment process which gets automatically triggered by your commits. Downtime? No there’s not, just a few seconds when you replace your application. But that few seconds can be critically and let’s face it, how cool would it be to deploy without any downtime at all.

What is blue-green deployment?

Blue-green deployment is a straightforward way to achieve deployments without any downtime, especially in those fancy, cloudy times we’re living in.

In this example, the blue instance is productive now. You deploy your new application-instance (green) besides the actual running one, wait until it is up and running, execute some automated tests on it, and if everything is fine, switch the route to the new instance, and we’re done.

I highly recommend this article about Blue-Green Deployment by Martin Fowler.

Step by step

Ok, let’s do this step by step. We assume, there’s already one application-instance running (the blue one :-)). Let’s push our new fancy update out to the world:

cf login -a https://super.cloud -u me -p my-password
cf push myapp-green -p "myapp_publish" -u http --endpoint /healthcheck --hostname "myapp-green"

The important parts here are:

• Implement a useful naming-scheme for the blue/green containers. The name shouldn’t be generated. It should be a predictable name, and it makes it much easier to work with it during your CI/CD pipeline.
• With -u http --endpoint /healthcheck we can tell Cloud Foundry how to check if our app is ready. The health check endpoint is part of your application so that you can define your logic in there (e.g. check if some initial jobs are done). There are more options to implement a health check, see the Cloud Foundry docs for more information. So now our application is pushed and reachable through the “myapp-green”-route (as defined with the hostname-parameter), but it’s not yet productive, because you’re using the “green-route”.

Now you can execute some verifications against the green container:

• Execute some Smoke Tests on UI and API Level
• Measure some performance KPI’s

If everything is ok, you’re ready to take the green container to production. Basically, we are just telling the CF Router to map the production route to the green-container now.

# map the production route to the new green container
cf map-route myapp-green --hostname myapp
# unmap the green route from the green container
cf unmap-route myapp-green --hostname myapp-green
# unmap the production route from the original outdated container
cf unmap-route myapp --hostname myapp

Last but not least, we’re doing some housekeeping. We rename the green-container to match our production naming convention and then clean up everything that is not needed anymore.

cf rename myapp myapp-tmp
cf rename myapp-green myapp
cf delete myapp-tmp -r -f

That’s it. The described scenario is relatively simple. Of course, we can think of far more complex ones, for example, we could run the (new) green and the old (blue) container in parallel and do some verifications in production, like check performance KPI’s, monitor logging-events, etc.

And what about user sessions?

Of course, you cannot use InProc-Sessions in such a setup because you would just kill them by taking the production container down. You definitely should use a distributed solution to store user sessions, like Redis.