← All Articles

Achieving zero-downtime deployments with Docker

Philip KallbergPhilip Kallberg
May 15th 15Updated Jun 17th 15

achieving-zero-downtime-deployments-with-docker

We all aim to achieve zero-downtime deployments, and as with typical web servers, doing so with Docker requires some orchestration to ensure a smooth transition between code versions. At Cloud 66, we provide health checks to achieve that result. This allows you to determine whether your new containers are healthy before switching traffic from the old ones.

As an example, let's say you have a simple stack running two services, a web frontend and an API. For illustration purposes, these services are running on V1 of your code, and you want to deploy V2. To ensure zero downtime, you can setup either an inbound or outbound health check - the former asking Cloud 66 to cURL your service on a specific endpoint, and the latter allowing your container to tell us its health state.

The health checks we setup for these services may look like this:

services:
    web:
        health:
          type: inbound
          endpoint: "/"
          protocol: "http"
          timeout: "45s"
          accept: ["200"]
    api:
        health:
          type: outbound

As you can see, our health check for the web service is inbound, and will cURL the / endpoint on HTTP, and wait up to 45 seconds to see a HTTP 200. The api service will let us know itself - we inject an environment variable called CONTAINER_NOTIFY_URL where it can POST a JSON payload with its health ({"ready":true} being healthy).

If for any reason the health check fails, the deployment is deemed to have failed, so we'll kill these V2 containers and keep the V1 containers running. Similarly, if everything goes well, we'll drain V1 of traffic and direct any new traffic to your V2 containers.

This feature also ties into our ElasticDNS service. At some point during your deployment, you'll have 2 versions of each service running, and our DNS service keeps track of this. If V1 of your web container asks for api.cloud66.local, it will get the address for the V1 version of that service, but if V2 of your web container asks for the same thing, it will get the address to the V2 version of the api.

In addition to providing zero-downtime deployments with health checks, we also provide notifications on various channels should your containers die at any point during their execution.

We've seen lots of different use cases of running Docker so far, and are building our service to support these and more. We'd love to hear from you if you have any thoughts on how we can be better!

Update : Check out our introductory video on how you can use health checks to achieve zero-downtime deployments with Docker.


Try Cloud 66 for Free, No credit card required