* split spec * spec split * trial branch * fix * branch update * landing page * add description * add description * update file path * tweak * fix build * split spec Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com> * spec split Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com> * trial branch Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com> * fix Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com> * branch update Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com> * landing page Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com> * add description Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com> * add description Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com> * update file path Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com> * tweak Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com> * fix build Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com> * missing new line Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com> * first batch of fix links * second batch of link fix * update toc --------- Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com> Co-authored-by: CrazyMax <crazy-max@users.noreply.github.com>
1.7 KiB
description, keywords, title, notoc
| description | keywords | title | notoc |
|---|---|---|---|
| How to control service startup and shutdown order in Docker Compose | documentation, docs, docker, compose, startup, shutdown, order | Control startup and shutdown order in Compose | true |
{% include compose-eol.md %}
You can control the order of service startup and shutdown with the
depends_on option. Compose always starts and stops
containers in dependency order, where dependencies are determined by
depends_on, links, volumes_from, and network_mode: "service:...".
A good example of when you might use this is an application which needs to access a database. If both services are started with docker compose up, there is a chance this will fail since the application service might start before the database service and won't find a database able to handle its SQL statements.
Control startup
On startup, Compose does not wait until a container is "ready", only until it's running. This can cause issues if, for example you have a relational database system that needs to start its own services before being able to handle incoming connections.
The solution for detecting the ready state of a service is to use the condition attribute with one of the following options:
service_startedservice_healthy. This specifies that a dependency is expected to be “healthy”, which is defined withhealthcheck, before starting a dependent service.service_completed_successfully. This specifies that a dependency is expected to run to successful completion before starting a dependent service.