Docker Compose espera el contenedor X antes de comenzar Y

Estoy usando rabbitmq y una simple muestra de python de aquí junto con docker-compose. Mi problema es que necesito esperar a que rabbitmq se inicie por completo. Por lo que busqué hasta ahora, no sé cómo esperar con el contenedor x (en mi caso trabajador) hasta que se inicie y (rabbitmq).

Encontré esta publicación de blog donde comprueba si el otro host está en línea. También encontré este comando docker :

Espere

Uso: docker wait CONTENEDOR [CONTENEDOR ...]

Bloquee hasta que un contenedor se detenga, luego imprima su código de salida.

Esperar a que se detenga un contenedor quizás no sea lo que estoy buscando, pero si lo es, ¿es posible usar ese comando dentro de docker-compose.yml? Mi solución hasta ahora es esperar unos segundos y verificar el puerto, pero ¿es esta la forma de lograr esto? Si no espero me sale un error.

docker-compose.yml

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

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

Python hola muestra (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 para trabajador:

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

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

Actualización de noviembre de 2015 :

Un script de shell o esperar dentro de su programa es quizás una posible solución. Pero después de ver este problema , estoy buscando un comando o función de docker / docker-compose.

Mencionan una solución para implementar un control de salud, que puede ser la mejor opción. Una conexión tcp abierta no significa que su servicio esté listo o pueda permanecer listo. Además de eso, necesito cambiar mi punto de entrada en mi dockerfile.

Así que espero una respuesta con los comandos a bordo de Docker-compose, que con suerte será el caso si terminan este problema.

Actualización de marzo de 2016

Existe una propuesta para proporcionar una forma integrada de determinar si un contenedor está "vivo". Por lo tanto, Docker-compose puede usarlo en un futuro próximo.

Actualización de junio de 2016

Parece que el chequeo de salud se integrará en Docker en la versión 1.12.0

Actualización enero 2017

Encontré una solución docker-compose ver: Docker Compose espera el contenedor X antes de comenzar Y

Finalmente encontré una solución con un método docker-compose. Desde el formato de archivo docker-compose 2.1 puede definir comprobaciones de estado .

Lo hice en un proyecto de ejemplo que necesita instalar al menos Docker 1.12.0+. También necesitaba ampliar el Dockerfile rabbitmq-management , porque curl no está instalado en la imagen oficial.

Ahora pruebo si la página de administración del rabbitmq-container está disponible. Si el rizo termina con el código de salida 0, la aplicación de contenedor (python pika) se iniciará y publicará un mensaje en la cola de saludo. Ahora está funcionando (salida).

docker-compose (versión 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

salida:

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

La versión 3 ya no admite la forma de condición de dependen_on . Así que me mudé de dependen_on para reiniciar en caso de falla. Ahora mi contenedor de aplicaciones se reiniciará 2-3 veces hasta que funcione, pero sigue siendo una función de compilación acoplable sin sobrescribir el punto de entrada.

docker-compose (versión 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

Nativamente eso no es posible, todavía. Consulte también esta solicitud de función .

Hasta ahora, debe hacer eso en sus contenedores CMDpara esperar hasta que todos los servicios requeridos estén allí.

En los Dockerfilemensajes de CMDcorreo electrónico, puede consultar su propio script de inicio que envuelve el inicio de su servicio de contenedor. Antes de comenzar, espera a uno dependiente como:

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

Probablemente también necesites instalar netcat en tu Dockerfile. No sé qué está preinstalado en la imagen de Python.

Existen algunas herramientas que proporcionan una lógica de espera fácil de usar, para verificaciones simples de puertos tcp:

• esperar
• dockerize

Para esperas más complejas:

• goss - Blog de explicación

Usando restart: unless-stoppedo restart: alwayspuede resolver este problema.

Si el trabajador se containerdetiene cuando rabbitMQ no está listo, se reiniciará hasta que lo esté.

Recientemente han agregado la depends_onfunción .

Editar:

A partir de compose la versión 2.1+, puede usarlo depends_onen conjunto con healthcheckpara lograr esto:

De los documentos :

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"

Antes de la versión 2.1

Todavía puede usar depends_on, pero solo afecta el orden en que se inician los servicios, no si están listos antes de que se inicie el servicio dependiente.

Parece requerir al menos la versión 1.6.0.

El uso se vería así:

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

De los documentos:

Expresar dependencia entre servicios, que tiene dos efectos:

• docker-compose up iniciará los servicios en orden de dependencia. En el siguiente ejemplo, db y redis se iniciarán antes que la web.
• El servicio docker-compose up incluirá automáticamente las dependencias de SERVICE. En el siguiente ejemplo, docker-compose up web también creará e iniciará db y redis.

Nota: Según tengo entendido, aunque esto establece el orden en que se cargan los contenedores. No garantiza que el servicio dentro del contenedor se haya cargado realmente.

Por ejemplo, el contenedor de postgres podría estar activo. Pero el servicio postgres en sí mismo aún podría estar inicializándose dentro del contenedor.

También puede agregarlo a la opción de comando, por ejemplo.

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

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

esperar en un puerto también puedes usar algo como esto

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

para aumentar el tiempo de espera puedes hackear un poco más:

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"

restart: on-failure hizo el truco para mí ... ver abajo

---
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"

Para el contenedor comenzar a ordenar el uso

depends_on:

Para esperar el inicio del contenedor anterior, use el script

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

Este artículo lo ayudará a https://docs.docker.com/compose/startup-order/

También puede resolver esto estableciendo un punto final que espere a que el servicio esté activo utilizando netcat (utilizando el script docker-wait ). Me gusta este enfoque, ya que todavía tiene una commandsección limpia en su docker-compose.ymly no necesita agregar código específico de Docker a su aplicación:

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

Entonces tu 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

Esto se documenta en la actualidad el funcionario documentación ventana acoplable .

PD: debe instalarlo netcaten su instancia de docker si no está disponible. Para hacerlo, agregue esto a su Dockerarchivo:

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

Hay una utilidad lista para usar llamada " docker-wait " que se puede usar para esperar.

Intenté muchas maneras diferentes, pero me gustó la simplicidad de esto: https://github.com/ufoscout/docker-compose-wait

La idea de que se puede utilizar ENV vars en el archivo de cargador de muelle de redacción para presentar una lista de hosts de servicios (con puertos) que debe ser "esperado" de esta manera: WAIT_HOSTS: postgres:5432, mysql:3306, mongo:27017.

Entonces, supongamos que tiene el siguiente archivo docker-compose.yml (copy / past de 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

A continuación, para que los servicios esperen, debe agregar las siguientes dos líneas a sus Dockerfiles (en Dockerfile de los servicios que deben esperar a que otros servicios comiencen):

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

El ejemplo completo de tal Dockerfile de muestra (nuevamente desde el proyecto 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

Para otros detalles sobre el posible uso, consulte README

basándose en esta publicación de blog https://8thlight.com/blog/dariusz-pasciak/2016/10/17/docker-compose-wait-for-dependencies.html

Configuré mi docker-compose.ymlcomo se muestra a continuación:

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: {}

Entonces lo hago para ejecutar =>:

docker-compose up start_dependencies

rabbitmqEl servicio comenzará en modo demonio, start_dependenciesfinalizará el trabajo.

En la versión 3 de un archivo Docker Compose, puede usar RESTART .

Por ejemplo:

docker-compose.yml

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

Tenga en cuenta que utilicé depende_en lugar de enlaces, ya que este último está en desuso en la versión 3.

Aunque funciona, puede que no sea la solución ideal, ya que reinicia el contenedor acoplable en cada falla.

Eche un vistazo a RESTART_POLICY también. le permite ajustar la política de reinicio.

Cuando usa Compose en producción , en realidad es una buena práctica usar la política de reinicio:

Especificar una política de reinicio como reiniciar: siempre para evitar el tiempo de inactividad

Una de las soluciones alternativas es utilizar una solución de organización de contenedores como Kubernetes. Kubernetes tiene soporte para contenedores init que se ejecutan hasta su finalización antes de que otros contenedores puedan comenzar. Puede encontrar un ejemplo aquí con el contenedor Linux de SQL Server 2017 donde el contenedor API usa el contenedor init para inicializar una base de datos

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

Aquí está el ejemplo donde el maincontenedor espera workercuando comienza a responder pings:

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

Sin embargo, la forma correcta es usar healthcheck(> = 2.1).

No se recomienda para implementaciones serias, pero aquí es esencialmente un comando "esperar x segundos".

Con la docker-composeversión se ha agregado3.4 una start_periodinstrucciónhealthcheck . Esto significa que podemos hacer lo siguiente:

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

Lo que sucede aquí es que healthcheckse invoca después de 5 segundos. Esto llama al status.shscript, que siempre devuelve "No hay problema". ¡Acabamos de hacer que el zmq_clientcontenedor espere 5 segundos antes de comenzar!

Nota: es importante que tengas version: "3.4". Si .4no está allí, Docker-compose se queja.

Solo tengo 2 archivos de composición y comienzo uno primero y el segundo más tarde. Mi guión se ve así:

#!/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