我在这里使用rabbitmq和一个简单的python示例 和docker-compose一起。我的问题是我需要等待rabbitmq完全启动。从我搜索到目前为止,我不知道如何等待容器x(在我的case worker)直到y (rabbitmq)启动。

我发现了一篇他检查另一个主机是否在线的博客文章。 我还发现了这个docker命令:

等待 用法:docker wait 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 sample (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 for worker:

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

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

2015年11月更新:

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

他们提到了实现运行状况检查的解决方案,这可能是最佳选择。一个开放的tcp连接并不意味着你的服务已经准备好或可能保持准备状态。除此之外,我需要改变我的入口点在我的dockerfile。

因此,我希望通过docker-compose on board命令得到一个答案,如果他们完成了这个问题,就有希望出现这种情况。

2016年3月更新

有人提议提供一种内置的方法来确定容器是否“活”。因此,docker-compose在不久的将来可能会得到应用。

2016年6月更新

健康检查似乎将在1.12.0版本集成到docker中

2017年1月更新

我找到了一个docker-compose解决方案,见: Docker在启动Y之前撰写等待容器X


当前回答

下面是主容器在开始响应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)。

其他回答

基于这篇博客文章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: {}

然后执行for run =>:

Docker-compose start_dependencies

Rabbitmq服务将以daemon模式启动,start_dependencies将完成工作。

另一种解决方案是使用像Kubernetes这样的容器编排解决方案。Kubernetes支持init容器,它在其他容器启动之前运行到完成。你可以在这里找到一个SQL Server 2017 Linux容器的例子,其中API容器使用init容器初始化数据库

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

最近他们添加了depends_on特性。

编辑:

从撰写版本2.1+到版本3,你可以使用depends_on结合healthcheck来实现这一点:

从文档中可以看出:

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服务本身可能仍然在容器中进行初始化。

不建议用于严重的部署,但这里实际上是一个“等待x秒”命令。

在docker-compose 3.4版中,healthcheck添加了一条start_period指令。这意味着我们可以做到以下几点:

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

这里发生的情况是,5秒后调用healthcheck。这将调用status.sh脚本,该脚本总是返回“No problem”。 我们只是让zmq_client容器在启动前等待5秒!

注意:重要的是你有版本:“3.4”。如果。4不在那里,docker-compose会抱怨。

我只是有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