Zero Downtime Deployments on anynines

Table of Contents

• Preface
• Step by Step
  • 1) Deploy your application as usual
  • 2) Deploy an updated instance
  • 3) Re-map the routes to the updated instance
  • 4) Remove the live route from the outdated deployment
  • 5) Remove the staging route
  • 6) Stop the outdated instance
• Additional thoughts

Preface

As a software provider you want to avoid downtimes for your application. On the other hand you have to ensure the growth and quality of your applications by providing new features and adjustments and deploy them as soon as possible.
anynines allows you to deploy your changes without any downtime by using two different application deployments.
One deployment will offer the live application to your customers while the other deployment can be updated to a new version. After finishing the update you just have to switch your application’s routes to the updated deployment and all of the live traffic will hit the updated application deployment.  

Step by Step

This section will guide you through your first zero downtime deployment. Feel free to use our Sinatra example application for experimentation purposes. This guide assumes that you bind all needed services to both application instances so both deployments can access live data.

1) Deploy your application as usual

At first you will have to push your application to anynines using the following command:

cf push <first_instance_name> -n <live_subdomain>

e.g.: cf push sinatra_a -n sinatralive

After finishing the deployment process your application will be available under .de.a9sapp.eu (sinatralive.de.a9sapp.eu).

2) Deploy an updated instance

When code changes have been commited and tested through your production pipeline you can start with the zero downtime deployment process.

You will have to push a second instance with a different application name to your current space by issuing the following command:

cf push <second_instance_name> -n <staging_subdomain>

e.g.: cf push sinatra_b -n sinatrastaging

After finishing the deployment process your updated application instance will be available under <staging_subdomain>.de.a9sapp.eu (sinatrastaging.de.a9sapp.eu). You can use this url to perform a last check on your new features and bugfixes.

3) Re-map the routes to the updated instance

At this time both application deployments are accessible via the urls <live_subdomain>.de.a9sapp.eu and <staging_subdomain>.de.a9sapp.eu .
It’s time to remap the live route to the updated application deployment:

cf map-route <second_instance_name> de.a9sapp.eu -n <live_subdomain>

e.g.: cf map-route sinatra_b de.a9sapp.eu -n sinatralive

Right now all traffic to <live_subdomain>.de.a9sapp.eu will be load balanced between your two application instances.

4) Remove the live route from the outdated deployment

Now we can remove the route from the outdated application deployment:

cf unmap-route <first_instance_name> de.a9sapp.eu -n <live_subdomain>

e.g.: cf unmap-route sinatra_a de.a9sapp.eu -n sinatralive

From now on all requests to <live_subdomain>.de.a9sapp.eu will be routed to the updated application instance.

5) Remove the staging route

As we don’t need the staging route we can delete it from the updated deployment using the unmap-route command:

cf unmap-route <second_instance_name> de.a9sapp.eu -n <staging_subdomain>

e.g.: cf unmap-route sinatra_b de.a9sapp.eu -n sinatrastaging

6) Stop the outdated instance

Finally, let’s stop the outdated instance to save resources:

cf stop <first_instance_name>

e.g.: cf stop sinatra_a

If we run into any problems with the new application version we can easily fall back to the old state by starting up the deployment and remapping the live route to it again.

Additional thoughts

A lot of updates to your application can be deployed without any downtime using the instructions above, but this scenario is not applicable for each kind of application update. If you need to do changes on your databases or have complicated changes that don’t allow a parallel run of two different versions you will have to make a plan suitable for your application structure to perform updates. Even in those scenarios downtime can be avoided or kept really small.

Since the cf CLI is made for scripting the no downtime deployment process can be automated by writing a simple bash script customized to your application’s needs.