mirror of
https://github.com/docker/compose.git
synced 2025-10-31 03:03:49 +01:00
89 lines
3.0 KiB
Markdown
89 lines
3.0 KiB
Markdown
<!--[metadata]>
|
|
+++
|
|
title = "Controlling startup order"
|
|
description = "How to control service startup order in Docker Compose"
|
|
keywords = "documentation, docs, docker, compose, startup, order"
|
|
[menu.main]
|
|
parent="workw_compose"
|
|
weight=90
|
|
+++
|
|
<![end-metadata]-->
|
|
|
|
# Controlling startup order in Compose
|
|
|
|
You can control the order of service startup with the
|
|
[depends_on](compose-file.md#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](https://github.com/vishnubob/wait-for-it)
|
|
or [dockerize](https://github.com/jwilder/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
|
|
|
|
- [Installing Compose](install.md)
|
|
- [Get started with Django](django.md)
|
|
- [Get started with Rails](rails.md)
|
|
- [Get started with WordPress](wordpress.md)
|
|
- [Command line reference](./reference/index.md)
|
|
- [Compose file reference](compose-file.md)
|