The Wayback Machine - https://web.archive.org/web/20160305023932/https://docs.docker.com/compose/startup-order/
Get Started
Quickstart containers Understand the architecture
Migrate to Engine 1.10 Breaking changes Deprecated Engine Features FAQ
Release Notes
Learn about Dockerfiles and Docker Cloud Back up data volumes Create a proxy or load balancer Install the Deploy to Docker Cloud button Integrate with Slack Push images to Docker Cloud SSHing into a Docker Cloud-managed node Upgrade Docker Engine on a node Use the Docker Cloud Agent Using the Docker Cloud CLI
API reference
Quickstart contribution FAQ for contributors Where to chat or get help Style guide for Docker documentation

Controlling startup order in Compose

You can control the order of service startup with the depends_on option. Compose always starts containers in dependency order, where dependencies are determined by depends_on, links, volumes_from and network_mode: "service:...".

However, Compose will not wait until a container is “ready” (whatever that means for your particular application) - only until it’s running. There’s a good reason for this.

The problem of waiting for a database (for example) to be ready is really just a subset of a much larger problem of distributed systems. In production, your database could become unavailable or move hosts at any time. Your application needs to be resilient to these types of failures.

To handle this, your application should attempt to re-establish a connection to the database after a failure. If the application retries the connection, it should eventually be able to connect to the database.

The best solution is to perform this check in your application code, both at startup and whenever a connection is lost for any reason. However, if you don’t need this level of resilience, you can work around the problem with a wrapper script:

  • Use a tool such as wait-for-it or dockerize. These are small wrapper scripts which you can include in your application’s image and will poll a given host and port until it’s accepting TCP connections.

    Supposing your application’s image has a CMD set in its Dockerfile, you can wrap it by setting the entrypoint in docker-compose.yml:

    version: "2"
services:
  web:
    build: .
    ports:
      - "80:8000"
    depends_on:
      - "db"
    entrypoint: ./wait-for-it.sh db:5432
  db:
    image: postgres

  • Write your own wrapper script to perform a more application-specific health check. For example, you might want to wait until Postgres is definitely ready to accept commands:

    #!/bin/bash

set -e

host="$1"
shift
cmd="$@"

until psql -h "$host" -U "postgres" -c '\l'; do
  >&2 echo "Postgres is unavailable - sleeping"
  sleep 1
done

>&2 echo "Postgres is up - executing command"
exec $cmd

    You can use this as a wrapper script as in the previous example, by setting entrypoint: ./wait-for-postgres.sh db.

Compose documentation

On this page:
Mar 5, 2016 at 2:08am (PST) { "docker/apidocs": { "ref": "master", "repos": [ "[email protected]:docker/dhe-deploy.git" ], "sha": "70ac255c88cde0ea6ecf3fcb812783dea7e09da6" }, "docker/cloud-api-docs": { "ref": "master", "repos": [ "[email protected]:docker/cloud-docs.git" ], "sha": "c0539949c40be9abb193271e46d2ea88196f122d" }, "docker/cloud-api-docs-layout": { "ref": "master", "repos": [ "[email protected]:docker/cloud-docs.git" ], "sha": "c0539949c40be9abb193271e46d2ea88196f122d" }, "docker/compose": { "ref": "docs", "repos": [ "[email protected]:docker/compose.git" ], "sha": "9da9555f10abe628e7742476af3f10bd89f68b75" }, "docker/docker": { "ref": "docs", "repos": [ "[email protected]:docker/docker.git" ], "sha": "0e63b073ac8f33335a4d4df3f2aa22120e0b7f43" }, "docker/docker-cloud": { "ref": "master", "repos": [ "[email protected]:docker/cloud-docs.git" ], "sha": "c0539949c40be9abb193271e46d2ea88196f122d" }, "docker/docker-hub": { "ref": "master", "repos": [ "[email protected]:docker/hub2-demo.git" ], "sha": "73ccb2d678ab0cd83067f0c7ef6f3923d750c7bd" }, "docker/docker-trusted-registry": { "ref": "master", "repos": [ "[email protected]:docker/dhe-deploy.git" ], "sha": "70ac255c88cde0ea6ecf3fcb812783dea7e09da6" }, "docker/docs-base": { "ref": "master", "repos": [ "[email protected]:docker/docs-base.git" ], "sha": "5a4cfac3c4d156eda45080c7dcdd2a4c41e08067" }, "docker/kitematic": { "ref": "docs", "repos": [ "[email protected]:docker/kitematic.git" ], "sha": "856a989d834f7fcbcb9bba687539fb159228f6b8" }, "docker/machine": { "ref": "docs", "repos": [ "[email protected]:docker/machine.git" ], "sha": "21edf30337dc5996b5d785ce54d68b4020242f57" }, "docker/notary": { "ref": "docs", "repos": [ "[email protected]:docker/notary.git" ], "sha": "dfeb51f54f2b0cdf20cb55427b7cc8ea2d1cdd0a" }, "docker/opensource": { "ref": "master", "repos": [ "[email protected]:docker/opensource.git" ], "sha": "b994cdd1f74b0aeb0b51fda1249a0c4c8efbf0d0" }, "docker/registry": { "ref": "master", "repos": [ "[email protected]:docker/distribution.git" ], "sha": "33c4a6522e9247913fa0a9a2d78ef9a7aa98465f" }, "docker/swarm": { "ref": "docs", "repos": [ "[email protected]:docker/swarm.git" ], "sha": "b43a2c21c4017726cd9cb17ef9b16f2eef6d1159" }, "docker/toolbox": { "ref": "master", "repos": [ "[email protected]:docker/toolbox.git" ], "sha": "de267d701f94035549ea03e68047d85534286f85" }, "docker/tutorials": { "ref": "master", "repos": [ "[email protected]:docker/tutorials.git" ], "sha": "7af2622fe68a30684d971e4bf3ca7988902e5e26" }, "docker/ucp": { "ref": "master", "repos": [ "[email protected]:docker/orca.git" ], "sha": "8cd10936a1e063b9be0d5c04de7311a1b2cb25cf" }, "docs.docker.com": { "ref": "refs/heads/v1.10-030316", "repos": [ "[email protected]:moxiegirl/docs.docker.com.git", "[email protected]:docker/docs.docker.com.git" ], "sha": "b43886e4078ce481b06b4cee5c922f5bcc5c629f" } }