docker-compose可以使用depends_on选项控制服务启动和关闭的顺序。撰写总是开始和依赖顺序，其中依赖性是通过确定停止容器 depends_on，links，volumes_from，和network_mode: "service:..."。
但是，对于启动而言，Compose不会等到容器“就绪”（对于您的特定应用程序意味着什么）之后，才等到它运行时。这是有充分的理由的。
等待数据库（例如）准备就绪的问题实际上只是分布式系统更大问题的一部分。在生产中，您的数据库可能随时不可用或移动主机。您的应用程序需要能够应对这些类型的故障。
要解决此问题，请设计您的应用程序以尝试在失败后重新建立与数据库的连接。如果应用程序重试连接，则它最终可以连接到数据库。
最好的解决方案是在启动时以及由于某种原因而断开连接时都在应用程序代码中执行此检查。但是，如果不需要此级别的弹性，则可以使用包装器脚本解决此问题：
使用诸如wait-for-it， dockerize，sh-compatible wait-for或RelayAndContainers模板之类的工具。这些是小的包装脚本，您可以在应用程序的映像中包括这些脚本，以轮询给定的主机和端口，直到它接受TCP连接为止。
例如，使用wait-for-it.sh或wait-for包装服务的命令：
version: "2"
services:
web:
build: .
ports:
- "80:8000"
depends_on:
- "db"
command: ["./wait-for-it.sh", "db:5432", "--", "python", "app.py"]
db:
image: postgres
第一个解决方案有局限性。例如，它不验证特定服务何时真正就绪。如果您向命令添加更多参数，请将该bash shift命令与循环一起使用，如下例所示。
或者，编写您自己的包装器脚本以执行更特定于应用程序的运行状况检查。例如，您可能要等到Postgres准备好接受命令：
#!/bin/sh
# wait-for-postgres.sh
set -e
host="$1"
shift
cmd="$@"
until PGPASSWORD=$POSTGRES_PASSWORD psql -h "$host" -U "postgres" -c 'q'; do
>&2 echo "Postgres is unavailable - sleeping"
sleep 1
done
>&2 echo "Postgres is up - executing command"
exec $cmd
您可以通过设置以下内容，将其用作上一个示例中的包装脚本：
command: ["./wait-for-postgres.sh", "db", "python", "app.py"]
