Docker Compose 在启动 Y 之前等待容器 X答案

【问题标题】：Docker Compose wait for container X before starting YDocker Compose 在启动 Y 之前等待容器 X
【发布时间】：2015-10-23 03:12:16
【问题描述】：

我正在使用 rabbitmq 和来自here 的简单 python 示例与 docker-compose 一起使用。我的问题是我需要等待rabbitmq 完全启动。从我到目前为止搜索的内容来看，我不知道如何等待容器 x（在我的案例工作者中）直到 y (rabbitmq) 启动。

我发现了这个blog post，他在其中检查其他主机是否在线。我还发现了这个docker command：

等待

用法：docker wait CONTAINER [CONTAINER...]

阻塞直到容器停止，然后打印其退出代码。

等待容器停止可能不是我想要的，但如果是的，是否可以在 docker-compose.yml 中使用该命令？到目前为止，我的解决方案是等待几秒钟并检查端口，但这是实现此目的的方法吗？如果我不等待，我会收到错误消息。

docker-compose.yml

worker:
    build: myapp/.
    volumes:
    - myapp/.:/usr/src/app:ro

    links:
    - rabbitmq
rabbitmq:
    image: rabbitmq:3-management

python hello 示例 (rabbit.py)：

import pika
import time

import socket

pingcounter = 0
isreachable = False
while isreachable is False and pingcounter < 5:
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    try:
        s.connect(('rabbitmq', 5672))
        isreachable = True
    except socket.error as e:
        time.sleep(2)
        pingcounter += 1
    s.close()

if isreachable:
    connection = pika.BlockingConnection(pika.ConnectionParameters(
            host="rabbitmq"))
    channel = connection.channel()

    channel.queue_declare(queue='hello')

    channel.basic_publish(exchange='',
                          routing_key='hello',
                          body='Hello World!')
    print (" [x] Sent 'Hello World!'")
    connection.close()

工人的 Dockerfile：

FROM python:2-onbuild
RUN ["pip", "install", "pika"]

CMD ["python","rabbit.py"]

2015 年 11 月更新：

shell 脚本或在程序中等待可能是一种可能的解决方案。但是在看到这个Issue 之后，我正在寻找 docker/docker-compose 本身的命令或功能。

他们提到了实施健康检查的解决方案，这可能是最佳选择。打开的 tcp 连接并不意味着您的服务已准备好或可能保持准备就绪。除此之外，我还需要更改 dockerfile 中的入口点。

所以我希望通过 docker-compose on board 命令得到答案，如果他们完成了这个问题，希望会是这样。

2016 年 3 月更新

proposal 提供了一种内置方法来确定容器是否“活动”。所以 docker-compose 可能在不久的将来可以使用它。

2016 年 6 月更新

在版本 1.12.0 中，似乎健康检查将 integrated 进入 docker

2017 年 1 月更新

我找到了一个 docker-compose 解决方案，请参阅： Docker Compose wait for container X before starting Y

【问题讨论】：

在 docker-compose 2.3 中不推荐使用健康检查，以鼓励分布式系统容错。见：docs.docker.com/compose/startup-order
我已经多次遇到这个问题。你可以克服它，但 docker-compose 会在每一步都与你抗争。如果你想要 setup-test-teardown 容器控制，你最好使用像conducto这样的东西。

标签： docker-compose

【解决方案1】：

终于找到了一个 docker-compose 方法的解决方案。由于 docker-compose 文件格式为 2.1，您可以定义 healthchecks。

我在example project 中做到了您至少需要安装 docker 1.12.0+。我还需要extend the rabbitmq-management Dockerfile，因为官方镜像上没有安装curl。

现在我测试一下rabbitmq-container的管理页面是否可用。如果 curl 以 exitcode 0 结束，则将启动容器应用程序（python pika）并将消息发布到 hello 队列。它现在正在工作（输出）。

docker-compose（2.1 版）：

version: '2.1'

services:
  app:
    build: app/.
    depends_on:
      rabbit:
        condition: service_healthy
    links: 
        - rabbit

  rabbit:
    build: rabbitmq/.
    ports: 
        - "15672:15672"
        - "5672:5672"
    healthcheck:
        test: ["CMD", "curl", "-f", "http://localhost:15672"]
        interval: 30s
        timeout: 10s
        retries: 5

输出：

rabbit_1  | =INFO REPORT==== 25-Jan-2017::14:44:21 ===
rabbit_1  | closing AMQP connection <0.718.0> (172.18.0.3:36590 -> 172.18.0.2:5672)
app_1     |  [x] Sent 'Hello World!'
healthcheckcompose_app_1 exited with code 0

Dockerfile（rabbitmq + curl）：

FROM rabbitmq:3-management
RUN apt-get update
RUN apt-get install -y curl 
EXPOSE 4369 5671 5672 25672 15671 15672

版本 3 不再支持depends_on 的条件形式。 所以我从depends_on转移到重新启动失败。现在我的应用容器将重新启动 2-3 次，直到它开始工作，但它仍然是一个 docker-compose 功能，不会覆盖入口点。

docker-compose（版本 3）：

version: "3"

services:

  rabbitmq: # login guest:guest
    image: rabbitmq:management
    ports:
    - "4369:4369"
    - "5671:5671"
    - "5672:5672"
    - "25672:25672"
    - "15671:15671"
    - "15672:15672"
    healthcheck:
        test: ["CMD", "curl", "-f", "http://localhost:15672"]
        interval: 30s
        timeout: 10s
        retries: 5

  app:
    build: ./app/
    environment:
      - HOSTNAMERABBIT=rabbitmq
    restart: on-failure
    depends_on:
      - rabbitmq
    links: 
        - rabbitmq

【讨论】：

@svenhornberg ping 使用 ICMP，因此不支持 TCP 端口。也许nc 来测试一个TCP 端口。可能最好使用psql -h localhost -p 5432 并查询一些东西。
“取决于”已在版本 3 中删除 docs.docker.com/compose/compose-file/#dependson
@nha 看起来depends_on 的condition 形式已被删除，但depends_on 本身在v3 中仍然存在
如果depends_on 和condition 已被删除，如何仍然使用健康检查来控制启动顺序？
很难相信这样的痛苦仍然

【解决方案2】：

这在本机上是不可能的。另见feature request。

到目前为止，您需要在您的容器 CMD 中执行此操作，以等待所有必需的服务都在那里。

在Dockerfiles CMD 中，您可以参考您自己的启动脚本，该脚本包含启动您的容器服务。在开始之前，您需要等待一个依赖项，例如：

Dockerfile

FROM python:2-onbuild
RUN ["pip", "install", "pika"]
ADD start.sh /start.sh
CMD ["/start.sh"]

start.sh

#!/bin/bash
while ! nc -z rabbitmq 5672; do sleep 3; done
python rabbit.py

您可能还需要在 Dockerfile 中安装 netcat。我不知道python镜像上预装了什么。

有一些工具可以提供易于使用的等待逻辑，用于简单的 tcp 端口检查：

对于更复杂的等待：

goss - 解释blog

【讨论】：

您能解释一下您所说的 CMD 是什么意思吗？这是否意味着我的程序必须这样做，就像我通过端口检查所做的那样？还是您的意思是来自例如的特定 CMD linux为此？
谢谢你的解释，我赞成你的回答。但我认为即将到来的功能请求将是我问题的正确答案，所以到目前为止我没有回答。

【解决方案3】：

最近他们添加了depends_on feature。

编辑：

从撰写版本 2.1+ 到版本 3，您可以使用 depends_on 和 healthcheck 来实现此目的：

From the docs:

version: '2.1'
services:
  web:
    build: .
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_started
  redis:
    image: redis
  db:
    image: redis
    healthcheck:
      test: "exit 0"

2.1 版之前

您仍然可以使用depends_on，但它只会影响服务启动的顺序 - 如果它们在依赖服务启动之前准备好，则不会。

似乎至少需要 1.6.0 版。

用法如下所示：

version: '2'
services:
  web:
    build: .
    depends_on:
      - db
      - redis
  redis:
    image: redis
  db:
    image: postgres

来自文档：

表达服务之间的依赖关系，有两个作用：

docker-compose up 将按依赖顺序启动服务。在下面的例子中，db 和 redis 将在 web 之前启动。

docker-compose up SERVICE 将自动包含 SERVICE 的依赖项。在下面的例子中，docker-compose up web 也会创建并启动 db 和 redis。

注意：据我了解，虽然这确实设置了容器的加载顺序。不保证容器内的服务已经真正加载完毕。

例如，您的 postgres 容器可能已启动。但 postgres 服务本身可能仍在容器内初始化。

【讨论】：

dnephin 写道：depends_on 只是订购。要真正延迟另一个容器的启动，需要某种方法来检测进程何时完成自身初始化。
"版本3不再支持depends_on的条件形式。" docs.docker.com/compose/compose-file/#dependson
depends_on 不会等到容器处于 ready 状态（无论您的情况是什么意思）。它只会等到容器处于“运行”状态。
@akauppi 我没有找到任何这样的报价。相反，我看到第 3 版确实支持 depends_on（并说明如果您在 swarm 模式下部署它不支持）请参阅 docs.docker.com/compose/compose-file/compose-file-v3/… 我已经使用 docker-compose 版本 3.7 在本地进行了测试它确实支持depends_on的条件形式。
@akauppi 当然，我知道从那以后可能发生了很多变化。尽管这个问题/答案是旧的，但它在如何管理 Docker 中的启动顺序的搜索结果中仍然很高。其他开发人员可能会像我一样偶然发现这些 cmets，并且可能会发现更新很有用。我想depends_on 的条件形式在某个时候被删除了，后来又恢复了。

【解决方案4】：

使用restart: unless-stopped 或restart: always 可以解决这个问题。

如果workercontainer在rabbitMQ未准备好时停止，它将重新启动，直到它准备好。

【讨论】：

我喜欢这种情况下的解决方案，但它不适用于在其运行的子进程之一失败时不退出的容器。例如，即使运行的 Java servlet 无法连接到数据库服务器，Tomcat 容器也会继续运行。诚然，Docker 容器使 Tomcat 之类的 servlet 容器大多是不必要的。
@DerekMahar，如果你有一个只提供 REST 调用的基于 Java 的 Web 应用程序，你用什么来代替 Jetty/Tomcat？
@JoeG，我的意思是 Tomcat 是可以托管许多应用程序的 servlet 容器，而不是嵌入式 Tomcat。例如，Docker 使得前者几乎没有必要，而后者则更受微服务欢迎。

【解决方案5】：

您也可以将其添加到命令选项中，例如。

command: bash -c "sleep 5; start.sh"

https://github.com/docker/compose/issues/374#issuecomment-156546513

要在端口上等待，您也可以使用类似的东西

command: bash -c "while ! curl -s rabbitmq:5672 > /dev/null; do echo waiting for xxx; sleep 3; done; start.sh"

要增加等待时间，您可以多破解一点：

command: bash -c "for i in {1..100} ; do if ! curl -s rabbitmq:5672 > /dev/null ; then echo waiting on rabbitmq for $i seconds; sleep $i; fi; done; start.sh"

【讨论】：

有效且易于使用：这是一个很好的答案。

【解决方案6】：

restart: on-failure 为我做了诀窍..见下文

---
version: '2.1'
services:
  consumer:
    image: golang:alpine
    volumes:
      - ./:/go/src/srv-consumer
    working_dir: /go/src/srv-consumer
    environment:
      AMQP_DSN: "amqp://guest:guest@rabbitmq:5672"
    command: go run cmd/main.go
    links:
          - rabbitmq
    restart: on-failure

  rabbitmq:
    image: rabbitmq:3.7-management-alpine
    ports:
      - "15672:15672"
      - "5672:5672"

【讨论】：

【解决方案7】：

对于容器开始订购使用

depends_on:

等待前一个容器启动使用脚本

entrypoint: ./wait-for-it.sh db:5432

这篇文章会帮助你 https://docs.docker.com/compose/startup-order/

【讨论】：

@svenhornberg 在评论中，你链接，没有关于 wait-for-it.sh 功能的解释。

【解决方案8】：

尝试了许多不同的方法，但喜欢这种简单性：https://github.com/ufoscout/docker-compose-wait

您可以在 docker compose 文件中使用 ENV vars 来提交应该“等待”的服务主机列表（带有端口），如下所示：WAIT_HOSTS: postgres:5432, mysql:3306, mongo:27017。

假设您有以下 docker-compose.yml 文件（从 repo README 复制/过去）：

version: "3"

services:

  mongo:
    image: mongo:3.4
    hostname: mongo
    ports:
      - "27017:27017"

  postgres:
    image: "postgres:9.4"
    hostname: postgres
    ports:
      - "5432:5432"

  mysql:
    image: "mysql:5.7"
    hostname: mysql
    ports:
      - "3306:3306"

  mySuperApp:
    image: "mySuperApp:latest"
    hostname: mySuperApp
    environment:
      WAIT_HOSTS: postgres:5432, mysql:3306, mongo:27017

接下来，为了让服务等待，您需要将以下两行添加到您的 Dockerfiles（到应该等待其他服务启动的服务的 Dockerfile 中）：

ADD https://github.com/ufoscout/docker-compose-wait/releases/download/2.5.0/wait /wait
RUN chmod +x /wait

此类示例 Dockerfile 的完整示例（再次来自项目 repo README）：

FROM alpine

## Add your application to the docker image
ADD MySuperApp.sh /MySuperApp.sh

## Add the wait script to the image
ADD https://github.com/ufoscout/docker-compose-wait/releases/download/2.5.0/wait /wait
RUN chmod +x /wait

## Launch the wait tool and then your application
CMD /wait && /MySuperApp.sh

有关可能使用的其他详细信息，请参阅README

【讨论】：

我正在寻找类似的答案。我通常使用hub.docker.com/r/dadarek/wait-for-dependencies，因为它在下面使用netcat。您提供的是基于 Rust 的。无法评论你的质量，但对我来说，没有额外的层是绝对专业的。
出于安全考虑，我强烈建议不要这样做。您正在从超链接运行任意可执行文件。更好的解决方案是使用 COPY 复制到图像中的静态脚本来做同样的事情
@PaulK 当然，从超链接运行任何东西都不安全是可以理解的，但这只是上面的演示如何使https://github.com/ufoscout/docker-compose-wait 库工作:) 你使用该库的方式不会改变您可以使用一些库的答案。安全性是一个复杂的话题，如果我们走得太远，我们应该检查那个库在里面做什么，即使我们复制它:) 所以最好在你的评论中更具体，比如：“我强烈建议不要使用那个库来自超链接”。希望您同意，谢谢提示！

【解决方案9】：

您还可以通过使用 netcat（使用 docker-wait 脚本）设置一个等待服务启动的端点来解决此问题。我喜欢这种方法，因为您的 docker-compose.yml 中仍然有一个干净的 command 部分，并且您不需要将特定于 docker 的代码添加到您的应用程序中：

version: '2'
services:
  db:
    image: postgres
  django:
    build: .
    command: python manage.py runserver 0.0.0.0:8000
    entrypoint: ./docker-entrypoint.sh db 5432
    volumes:
      - .:/code
    ports:
      - "8000:8000"
    depends_on:
      - db

然后你的docker-entrypoint.sh:

#!/bin/sh

postgres_host=$1
postgres_port=$2
shift 2
cmd="$@"

# wait for the postgres docker to be running
while ! nc $postgres_host $postgres_port; do
  >&2 echo "Postgres is unavailable - sleeping"
  sleep 1
done

>&2 echo "Postgres is up - executing command"

# run the command
exec $cmd

这在官方docker documentation 中有记录。

PS：如果不可用，您应该在您的 docker 实例中安装 netcat。为此，请将其添加到您的 Docker 文件中：

RUN apt-get update && apt-get install netcat-openbsd -y

【讨论】：

【解决方案10】：

如果您只想启动服务，则另一个服务已成功完成（例如迁移、数据填充等），docker-compose 1.29 版附带build in functionality for this - service_completed_successfully。

depends_on:
  <service-name>:
    condition: service_completed_successfully

根据specification：

service_completed_successfully - 指定依赖项在启动依赖服务之前应运行到成功完成

【讨论】：

【解决方案11】：

有一个名为“docker-wait”的即用型实用程序可用于等待。

【讨论】：

谢谢，但它只是一个 shell 脚本，所以它就像 h3nrik 回答或在 python 中等待。它不是 docker-compose 本身的功能。愿你看看github.com/docker/compose/issues/374 他们计划实施健康检查，这将是最好的方法。打开的 tcp 连接并不意味着您的服务已准备好或可能保持准备就绪。除此之外，我还需要更改 dockerfile 中的入口点。

【解决方案12】：

根据这篇博文https://8thlight.com/blog/dariusz-pasciak/2016/10/17/docker-compose-wait-for-dependencies.html

我配置了我的docker-compose.yml，如下图：

version: "3.1"

services:
  rabbitmq:
    image: rabbitmq:3.7.2-management-alpine
    restart: always
    environment:
      RABBITMQ_HIPE_COMPILE: 1
      RABBITMQ_MANAGEMENT: 1
      RABBITMQ_VM_MEMORY_HIGH_WATERMARK: 0.2
      RABBITMQ_DEFAULT_USER: "rabbitmq"
      RABBITMQ_DEFAULT_PASS: "rabbitmq"
    ports:
      - "15672:15672"
      - "5672:5672"
    volumes:
      - data:/var/lib/rabbitmq:rw

  start_dependencies:
    image: alpine:latest
    links:
      - rabbitmq
    command: >
      /bin/sh -c "
        echo Waiting for rabbitmq service start...;
        while ! nc -z rabbitmq 5672;
        do
          sleep 1;
        done;
        echo Connected!;
      "

volumes:
  data: {}

然后我运行 =>:

docker-compose up start_dependencies

rabbitmq 服务将以守护模式启动，start_dependencies 将完成工作。

【讨论】：

大声笑，通过"curl", "-f", "http://localhost:15672" 进行查询，您需要为此安装management 插件并使用已弃用的健康检查 - 它的最佳答案。简单的工作示例，通过nc 对其进行检查 - 否决。哈，好吧...
答案不使用原生 docker 功能，如果您使用 curl、nc 或其他工具，则无关紧要。尽管！ nc 与其他答案中已经发布的相同。
本地 docker 功能：1.docs.docker.com/compose/startup-order 2.github.com/docker/compose/issues/5007 3.github.com/docker/compose/issues/374
@IgorKomar，谢谢你，你拯救了我的一天！ :3 在实际应用程序启动之前，我使用了几乎相同的机制来检查 mysql 服务器是否准备就绪。 ;) 我将类似的命令传递给docker-compose run --name app-test --rm "app" bash -l -c 'echo Waiting for mysql service start... && while ! nc -z db-server 3306; do sleep 1; done && echo Connected! && /bin/bash /script/ci_tests.sh'

【解决方案13】：

在 Docker Compose 文件的版本 3 中，您可以使用 RESTART。

例如：

docker-compose.yml

worker:
    build: myapp/.
    volumes:
    - myapp/.:/usr/src/app:ro
    restart: on-failure
    depends_on:
    - rabbitmq
rabbitmq:
    image: rabbitmq:3-management

请注意，我使用 depends_on 而不是 links，因为后者在版本 3 中已被弃用。

尽管它可以工作，但它可能不是理想的解决方案，因为每次出现故障时都要重新启动 docker 容器。

也可以查看RESTART_POLICY。它可以让您微调重启策略。

当你use Compose in production时，实际上最好使用重启策略：

指定重启策略，如重启：总是避免停机

【讨论】：

【解决方案14】：

不推荐用于严重部署，但这里本质上是一个“等待 x 秒”命令。

使用docker-compose 版本3.4 和start_period instruction has been added to healthcheck。这意味着我们可以执行以下操作：

docker-compose.yml:

version: "3.4"
services:
  # your server docker container
  zmq_server:
    build:
      context: ./server_router_router
      dockerfile: Dockerfile

  # container that has to wait
  zmq_client:
    build:
      context: ./client_dealer/
      dockerfile: Dockerfile
    depends_on:
      - zmq_server
    healthcheck:
      test: "sh status.sh"
      start_period: 5s

status.sh:

#!/bin/sh

exit 0

这里发生的是healthcheck 在 5 秒后被调用。这将调用status.sh 脚本，该脚本始终返回“没问题”。我们刚刚让zmq_client 容器在启动前等待 5 秒！

注意：拥有version: "3.4" 很重要。如果.4 不存在，docker-compose 会抱怨。

【讨论】：

作为一个幼稚的“等待 5 秒”解决方案，这个方案相当巧妙。我会投票，但我不会投票，因为这不适用于类似 prod 的设置，而且我担心有人会查看投票数而不是仔细阅读。尽管如此，我还是想说“伙计，这很聪明”；）
附言。有关更复杂的解决方案，请参阅 Evereq 的答案
这不是 start_period 所做的。该配置意味着有一个宽限期，失败的健康检查不计为重试。如果它及早成功，它被认为是健康的。在开始期之后，失败将被视为重试。见docs.docker.com/engine/reference/builder/#healthcheck

【解决方案15】：

我目前也有这样的要求，即在其他服务启动之前等待某些服务启动并运行。另请阅读此处和其他一些地方的建议。但是他们中的大多数都要求docker-compose.yml 必须进行一些更改。所以我开始研究一个我认为是围绕 docker-compose 本身的编排层的解决方案，最后我想出了一个我称之为 docker-compose-profile 的 shell 脚本。即使服务没有直接向主机公开任何端口，它也可以等待与某个容器的 tcp 连接。我使用的技巧是在堆栈中启动另一个 docker 容器，然后我可以（通常）从那里连接到每个服务（只要没有应用其他网络配置）。还有等待方法来注意某个日志消息。可以将服务组合在一起以在一个步骤中启动，然后触发另一个步骤来启动。您还可以排除某些服务而不列出所有其他要启动的服务（例如可用服务的集合减去一些排除的服务）。这种配置可以捆绑到配置文件中。有一个名为 dcp.yml 的 yaml 配置文件（目前）必须放在 docker-compose.yml 文件旁边。

对于您的问题，如下所示：

command:
  aliases:
    upd:
      command: "up -d"
      description: |
        Create and start container. Detach afterword.

profiles:
  default:
    description: |
      Wait for rabbitmq before starting worker.
    command: upd
    steps:
      - label: only-rabbitmq
        only: [ rabbitmq ]
        wait:
          - 5@tcp://rabbitmq:5432
      - label: all-others

您现在可以通过调用来启动您的堆栈

dcp -p default upd

甚至简单地

dcp

因为只有一个默认配置文件可以在 up -d 上运行。

有一个小问题。我当前的版本（还）不支持像唯一的特殊等待条件你实际上需要。所以没有测试向rabbit发送消息。

我已经在考虑在主机上或作为 docker 容器运行某个命令的进一步等待方法。比我们可以通过类似的方式扩展该工具

...
        wait:
          - service: rabbitmq
            method: container
            timeout: 5
            image: python-test-rabbit
...

拥有一个名为 python-test-rabbit 的 docker 映像来进行检查。

这样做的好处是，不再需要将等待的部分交给您的工人。它将被隔离并留在编排层内。

可能有人觉得这很有用。非常欢迎任何建议。

你可以在https://gitlab.com/michapoe/docker-compose-profile找到这个工具

【讨论】：

【解决方案16】：

另一种解决方案是使用 Kubernetes 等容器编排解决方案。 Kubernetes 支持在其他容器启动之前运行完成的 init 容器。您可以在此处找到 SQL Server 2017 Linux 容器的示例，其中 API 容器使用 init 容器来初始化数据库

https://www.handsonarchitect.com/2018/08/understand-kubernetes-object-init.html

【讨论】：

【解决方案17】：

这是main 容器在开始响应 ping 时等待 worker 的示例：

version: '3'
services:
  main:
    image: bash
    depends_on:
     - worker
    command: bash -c "sleep 2 && until ping -qc1 worker; do sleep 1; done &>/dev/null"
    networks:
      intra:
        ipv4_address: 172.10.0.254
  worker:
    image: bash
    hostname: test01
    command: bash -c "ip route && sleep 10"
    networks:
      intra:
        ipv4_address: 172.10.0.11
networks:
  intra:
    driver: bridge
    ipam:
      config:
      - subnet: 172.10.0.0/24

但是，正确的方法是使用healthcheck (>=2.1)。

【讨论】：

【解决方案18】：

我只有 2 个撰写文件，然后开始第一个和第二个。我的脚本是这样的：

#!/bin/bash
#before i build my docker files
#when done i start my build docker-compose
docker-compose -f docker-compose.build.yaml up
#now i start other docker-compose which needs the image of the first
docker-compose -f docker-compose.prod.yml up

【讨论】：

这不是一个好的做法。你不能从一个 compose 文件中提供由多个容器组成的解决方案。