Docker Compose aguarde o contêiner X antes de iniciar Y

Estou usando rabbitmq e um exemplo simples de python daqui em conjunto com o docker-compose. Meu problema é que preciso aguardar a inicialização completa do rabbitmq. Pelo que pesquisei até agora, não sei como esperar com o contêiner x (no meu assistente de caso) até que y (rabbitmq) seja iniciado.

Encontrei este blog onde ele verifica se o outro host está online. Eu também encontrei este comando docker :

esperar

Uso: docker wait CONTAINER [CONTAINER ...]

Bloqueie até que um contêiner pare e imprima seu código de saída.

Esperar a parada de um contêiner talvez não seja o que estou procurando, mas, se for, é possível usar esse comando dentro do docker-compose.yml? Até agora, minha solução é aguardar alguns segundos e verificar a porta, mas é esse o caminho para conseguir isso? Se eu não esperar, recebo um erro.

docker-compose.yml

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

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

Olá, exemplo python (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 trabalhador:

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

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

Atualização de novembro de 2015 :

Um script de shell ou aguardar dentro do seu programa é talvez uma solução possível. Mas, depois de ver esse problema , estou procurando um comando ou recurso do docker / docker-componen.

Eles mencionam uma solução para implementar uma verificação de saúde, que pode ser a melhor opção. Uma conexão tcp aberta não significa que seu serviço está pronto ou pode permanecer pronto. Além disso, preciso alterar meu ponto de entrada no meu arquivo docker.

Portanto, espero obter uma resposta com os comandos docker-compose on board, que, esperançosamente, serão o caso se eles terminarem esse problema.

Atualização de março de 2016

Existe uma proposta para fornecer uma maneira interna de determinar se um contêiner está "vivo". Portanto, o docker-compose pode utilizá-lo no futuro próximo.

Atualização junho de 2016

Parece que a verificação de saúde será integrada ao docker na versão 1.12.0

Atualização de janeiro de 2017

Encontrei uma solução docker-compose, consulte: Docker Compose, aguarde o contêiner X antes de iniciar Y

Finalmente encontrei uma solução com um método docker-compose. Desde o formato de arquivo 2.1 do docker-compose, você pode definir verificações de saúde .

Fiz isso em um projeto de exemplo que você precisa instalar pelo menos o docker 1.12.0+. Eu também precisava estender o Dockerfile rabbitmq-management , porque o curl não está instalado na imagem oficial.

Agora, testo se a página de gerenciamento do rabbitmq-container está disponível. Se a curvatura terminar com o exitcode 0, o aplicativo de contêiner (python pika) será iniciado e publicará uma mensagem na fila hello. Agora está funcionando (saída).

docker-compose (versão 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

resultado:

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

Arquivo de encaixe (rabbitmq + curl):

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

A versão 3 não suporta mais o formato de condição de depende_on . Então, mudei de depende_on para reiniciar em caso de falha. Agora, meu contêiner de aplicativos será reiniciado 2-3 vezes até que esteja funcionando, mas ainda é um recurso de composição do docker sem substituir o ponto de entrada.

docker-compose (versão 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, isso ainda não é possível. Veja também esta solicitação de recurso .

Até agora, você precisa fazer isso em seus contêineres CMDpara aguardar até que todos os serviços necessários estejam lá.

Nos Dockerfiles, CMDvocê pode se referir ao seu próprio script de início que encerra a inicialização do serviço de contêiner. Antes de iniciá-lo, aguarde um dependendo, 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

Provavelmente você também precisa instalar o netcat no seu Dockerfile. Não sei o que é pré-instalado na imagem python.

Existem algumas ferramentas disponíveis que fornecem lógica de espera fácil de usar, para verificações simples da porta tcp:

• espere por isso
• dockerize

Para esperas mais complexas:

• goss - Blog de explicações

Usando restart: unless-stoppedou restart: alwayspode resolver esse problema.

Se o worker containerparar quando o rabbitMQ não estiver pronto, ele será reiniciado até que esteja.

Recentemente, eles adicionaram o depends_onrecurso .

Editar:

A partir do compor versão 2.1+, você pode usar depends_onem conjunto com healthcheckpara conseguir isso:

Dos 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 da versão 2.1

Você ainda pode usar depends_on, mas isso afeta apenas a ordem em que os serviços são iniciados - e não se eles estiverem prontos antes do serviço dependente ser iniciado.

Parece exigir pelo menos a versão 1.6.0.

O uso ficaria assim:

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

Dos documentos:

Expressar dependência entre serviços, que tem dois efeitos:

• O docker-compose up iniciará os serviços em ordem de dependência. No exemplo a seguir, db e redis serão iniciados antes da web.
• o docker-componha o SERVICE incluirá automaticamente as dependências do SERVICE. No exemplo a seguir, a docker-compose up web também criará e iniciará db e redis.

Nota: Pelo que entendi, embora isso defina a ordem em que os contêineres são carregados. Não garante que o serviço dentro do contêiner tenha realmente sido carregado.

Por exemplo, o contêiner do postgres pode estar ativo. Mas o próprio serviço postgres ainda pode estar inicializando no contêiner.

você também pode adicioná-lo à opção de comando, por exemplo.

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

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

para esperar em uma porta, você também pode usar algo como isto

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

Para aumentar o tempo de espera, você pode hackear um pouco mais:

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 fez o truque para mim .. veja abaixo

---
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 pedidos de início de contêiner, use

depends_on:

Para aguardar o contêiner anterior, comece a usar o script

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

Este artigo ajudará você a https://docs.docker.com/compose/startup-order/

Você também pode resolver isso definindo um terminal que aguarda a ativação do serviço usando o netcat (usando o script docker-wait ). Eu gosto dessa abordagem, pois você ainda possui uma commandseção limpa no seu docker-compose.ymle não precisa adicionar código específico do docker ao seu aplicativo:

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

Então o seu 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

Atualmente, isso está documentado na documentação oficial da janela de encaixe .

PS: você deve instalar netcatna sua instância do docker se isso não estiver disponível. Para fazer isso, adicione isso ao seu Dockerarquivo:

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

Existe um utilitário pronto para uso chamado " docker-wait " que pode ser usado para aguardar.

Tentei de várias maneiras diferentes, mas gostei da simplicidade disso: https://github.com/ufoscout/docker-compose-wait

A idéia de que você pode usar ENV vars no arquivo janela de encaixe compor para apresentar uma lista de hosts de serviços (com portas), que deve ser "esperado" como este: WAIT_HOSTS: postgres:5432, mysql:3306, mongo:27017.

Então, digamos que você tenha o seguinte arquivo docker-compose.yml (copie / cole do 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

Em seguida, para que os serviços esperem, você deve adicionar as duas linhas a seguir aos seus Dockerfiles (no Dockerfile dos serviços que devem aguardar o início de outros serviços):

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

O exemplo completo desse exemplo Dockerfile (novamente no repositório README do projeto ):

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 outros detalhes sobre o possível uso, consulte o arquivo LEIA-ME

com base nesta postagem do blog https://8thlight.com/blog/dariusz-pasciak/2016/10/17/docker-compose-wait-for-dependencies.html

Eu configurei o meu docker-compose.ymlcomo mostrado abaixo:

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

Então eu faço para executar =>:

docker-compose up start_dependencies

rabbitmqO serviço iniciará no modo daemon, start_dependenciesfinalizará o trabalho.

Na versão 3 de um arquivo Docker Compose, você pode usar RESTART .

Por exemplo:

docker-compose.yml

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

Observe que eu usei o Depend_on em vez de links, pois o último está obsoleto na versão 3.

Mesmo que funcione, pode não ser a solução ideal, pois você reinicia o contêiner do docker a cada falha.

Ter um olhar para RESTART_POLICY também. permite ajustar a política de reinicialização.

Ao usar o Redigir na produção , é realmente recomendável usar a política de reinicialização:

Especificando uma política de reinicialização como restart: sempre para evitar o tempo de inatividade

Uma das soluções alternativas é usar uma solução de orquestração de contêiner como o Kubernetes. O Kubernetes tem suporte para contêineres init que são concluídos antes que outros contêineres possam iniciar. Você pode encontrar um exemplo aqui com o contêiner do SQL Server 2017 Linux em que o contêiner da API usa o contêiner init para inicializar um banco de dados

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

Aqui está o exemplo em que o maincontêiner aguarda workerquando começa a responder por 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

No entanto, a maneira correta é usar healthcheck(> = 2.1).

Não recomendado para implantações sérias, mas aqui está essencialmente um comando "wait x seconds".

Com a docker-composeversão, 3.4uma start_periodinstrução foi adicionada ahealthcheck . Isso significa que podemos fazer o seguinte:

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

O que acontece aqui é que o healthchecké invocado após 5 segundos. Isso chama o status.shscript, que sempre retorna "Sem problemas". Acabamos de fazer o zmq_clientrecipiente esperar 5 segundos antes de começar!

Nota: É importante que você tenha version: "3.4". Se .4não houver, o docker-compose reclama.

Eu só tenho 2 arquivos de composição e inicio um primeiro e o segundo mais tarde. Meu script é assim:

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