官方文件:https://docs.docker.com/compose/startup-order/

可以通過depends_on來編排服務之間的依賴關係，但是有一個問題，比如一個web專案，依賴一個數據庫或者依賴一個redis服務，那麼要等到資料庫完全準備好之後，才能讓web服務開始啟動並連線資料庫，docker預設的依賴方式是隻要依賴資料庫服務容器啟動就會啟動web容器，而不 檢查資料庫是否已經準備好。

解決方法一個方面是在連線層面使用自動重連策略，比如mysql jdbc可以有auto reconnect自動重連引數。或者使用下面建議的用一個指令碼（wait-for-it.sh）來探測依賴服務已經完全準備好,或者自己編寫一個health check指令碼來檢測依賴服務的健康狀況來判斷依賴服務是否啟動完成。

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, dockerize, or sh-compatible wait-for. 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.

  For example, to use wait-for-it.sh or wait-for to wrap your service’s command:

  version: "2"
  services:
    web:
      build: .
      ports:
        - "80:8000"
      depends_on:
        - "db"
      command: ["./wait-for-it.sh", "db:5432", "--", "python", "app.py"]
    db:
      image: postgres
  

  Tip: There are limitations to this first solution; e.g., it doesn’t verify when a specific service is really ready. If you add more arguments to the command, you’ll need to use the bash shift command with a loop, as shown in the next example.

• Alternatively, 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
  # wait-for-postgres.sh
  
  set -e
  
  host="$1"
  shift
  cmd="[email protected]"
  
  until 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
  

  You can use this as a wrapper script as in the previous example, by setting:

  command: ["./wait-for-postgres.sh", "db", "python", "app.py"]

注意如果你使用wait-for-it.sh指令碼，如果你的基礎映象不包含bash命令（比如alpine映象）需要安裝bash,不然沒法執行wait-for-it.sh指令碼導致容器啟動失敗。

如果Dockerfile的基礎映象用的是alpine相關的基礎映象的話，記得新增如下指令安裝bash:

RUN apk update
RUN apk upgrade
RUN apk add --no-cache bash