Quando si esegue un servizio all'interno di un contenitore, diciamo mongodb, il comando

docker run -d myimage

uscirà immediatamente e restituirà l'id del contenitore. Nel mio script CI, eseguo un client per testare la connessione mongodb, subito dopo aver eseguito il contenitore mongo. Il problema è: il client non può connettersi perché il servizio non è ancora attivo. Oltre ad aggiungere un grande sleep 10nel mio script, non vedo alcuna opzione per aspettare che un container sia attivo e funzionante.

Docker ha un comando waitche non funziona in quel caso, perché il contenitore non esiste. È una limitazione di docker?

Come commentato in un problema simile per la finestra mobile 1.12

HEALTHCHECKil supporto è unito a monte come da docker / docker # 23218 - questo può essere considerato per determinare quando un container è integro prima di avviare il successivo nell'ordine

Questo è disponibile dalla finestra mobile 1.12rc3 (14-07-2016)

docker-composeè in procinto di supportare una funzionalità in attesa di condizioni specifiche.

Usa libcompose(quindi non devo ricostruire l'interazione docker) e aggiunge un gruppo di comandi di configurazione per questo. Dai un'occhiata qui: https://github.com/dansteen/controlled-compose

Puoi usarlo in Dockerfile in questo modo:

HEALTHCHECK --interval=5m --timeout=3s \
  CMD curl -f http://localhost/ || exit 1

Documenti ufficiali: https://docs.docker.com/engine/reference/builder/#/healthcheck

Ho trovato questa semplice soluzione, stavo cercando qualcosa di meglio ma senza fortuna ...

until [ "`/usr/bin/docker inspect -f {{.State.Running}} CONTAINERNAME`"=="true" ]; do
    sleep 0.1;
done;

o se vuoi aspettare fino a quando il contenitore non viene segnalato come integro (supponendo che tu abbia un controllo di integrità)

until [ "`/usr/bin/docker inspect -f {{.State.Health.Status}} CONTAINERNAME`"=="healthy" ]; do
    sleep 0.1;
done;

Se non vuoi esporre le porte, come nel caso in cui prevedi di collegare il contenitore e potresti eseguire più istanze per il test, ho scoperto che questo era un buon modo per farlo in una riga :) Questo esempio è basato sull'attesa che ElasticSearch sia pronto:

docker inspect --format '{{ .NetworkSettings.IPAddress }}:9200' elasticsearch | xargs wget --retry-connrefused --tries=5 -q --wait=3 --spider

Ciò richiede che wget sia disponibile, che è standard su Ubuntu. Riproverà 5 volte, 3 secondi tra i tentativi, anche se la connessione viene rifiutata e inoltre non scarica nulla.

Se il servizio containerizzato che hai avviato non risponde necessariamente bene alle richieste di curl o wget (cosa abbastanza probabile per molti servizi), puoi ncinvece usarlo .

Ecco uno snippet da uno script host che avvia un contenitore Postgres e attende che sia disponibile prima di continuare:

POSTGRES_CONTAINER=`docker run -d --name postgres postgres:9.3`
# Wait for the postgres port to be available
until nc -z $(sudo docker inspect --format='{{.NetworkSettings.IPAddress}}' $POSTGRES_CONTAINER) 5432
do
    echo "waiting for postgres container..."
    sleep 0.5
done

Modifica : questo esempio non richiede di ESPORRE la porta che si sta testando, poiché accede all'indirizzo IP "privato" assegnato da Docker per il contenitore. Tuttavia questo funziona solo se il demone dell'host docker è in ascolto sul loopback (127.xxx). Se (ad esempio) sei su un Mac e stai eseguendo la VM boot2docker, non sarai in grado di utilizzare questo metodo poiché non puoi instradare agli indirizzi IP "privati" dei contenitori dalla shell del tuo Mac.

Supponendo che tu conosca l'host + la porta del tuo server MongoDB (o perché hai usato a -link, o perché li hai iniettati con -e), puoi semplicemente usare curlper verificare se il server MongoDB è in esecuzione e accetta le connessioni.

Il seguente frammento proverà a connettersi ogni secondo, finché non avrà successo:

#!/bin/sh
while ! curl http://$DB_PORT_27017_TCP_ADDR:$DB_PORT_27017_TCP_PORT/
do
  echo "$(date) - still trying"
  sleep 1
done
echo "$(date) - connected successfully"

Ho finito con qualcosa del tipo:

#!/bin/bash

attempt=0
while [ $attempt -le 59 ]; do
    attempt=$(( $attempt + 1 ))
    echo "Waiting for server to be up (attempt: $attempt)..."
    result=$(docker logs mongo)
    if grep -q 'waiting for connections on port 27017' <<< $result ; then
      echo "Mongodb is up!"
      break
    fi
    sleep 2
done

Lanciare la mia soluzione là fuori:

Sto usando le reti docker quindi il trucco netcat di Mark non ha funzionato per me (nessun accesso dalla rete host) e l'idea di Erik non funziona per un contenitore postgres (il contenitore è contrassegnato come in esecuzione anche se postgres non lo è ancora disponibile per la connessione). Quindi sto solo tentando di connettermi a postgres tramite un contenitore temporaneo in un ciclo:

#!/bin/bash

docker network create my-network
docker run -d \
    --name postgres \
    --net my-network \
    -e POSTGRES_USER=myuser \
    postgres

# wait for the database to come up
until docker run --rm --net my-network postgres psql -h postgres -U myuser; do
    echo "Waiting for postgres container..."
    sleep 0.5
done

# do stuff with the database...

test/test_runner

#!/usr/bin/env ruby

$stdout.sync = true

def wait_ready(port)
  until (`netstat -ant | grep #{port}`; $?.success?) do
    sleep 1
    print '.'
  end
end

print 'Running supervisord'
system '/usr/bin/supervisord'

wait_ready(3000)

puts "It's ready :)"

$ docker run -v /tmp/mnt:/mnt myimage ruby mnt/test/test_runner

Sto testando in questo modo se la porta è in ascolto o meno. In questo caso ho il test in esecuzione dall'interno del container, ma è anche possibile dall'esterno se mongodb è pronto o meno.

$ docker run -p 37017:27017 -d myimage

E controlla se la porta 37017 è in ascolto o meno dal contenitore host.

Ho dovuto affrontarlo di recente e mi è venuta un'idea. Durante la ricerca per questo compito sono arrivato qui, quindi ho pensato di condividere la mia soluzione con i futuri visitatori di questo post.

Soluzione basata su Docker-compose

Se stai usando docker-compose puoi controllare il mio POC di sincronizzazione docker . Ho combinato alcune delle idee in altre domande (grazie per questo - voto positivo).

L'idea di base è che ogni contenitore nel composito esponga un servizio diagnostico. La chiamata a questo servizio controlla se il set di porte richiesto è aperto nel container e restituisce lo stato generale del container (WARMUP / RUNNING secondo il POC). Ogni contenitore dispone inoltre di un'utilità per verificare all'avvio se i servizi dipendenti sono attivi e in esecuzione. Solo allora il contenitore si avvia.

Nell'ambiente docker-compose di esempio sono presenti due servizi server1 e server2 e il servizio client che attende l'avvio di entrambi i server, quindi invia una richiesta a entrambi ed esce.

Estratto dal POC

wait_for_server.sh

#!/bin/bash

server_host=$1
sleep_seconds=5

while true; do
    echo -n "Checking $server_host status... "

    output=$(echo "" | nc $server_host 7070)

    if [ "$output" == "RUNNING" ]
    then
        echo "$server_host is running and ready to process requests."
        break
    fi

    echo "$server_host is warming up. Trying again in $sleep_seconds seconds..."
    sleep $sleep_seconds
done

In attesa di più contenitori:

trap 'kill $(jobs -p)' EXIT

for server in $DEPENDS_ON
do
    /assets/wait_for_server.sh $server &
    wait $!
done

Implementazione di base del servizio diagnostico ( checkports.sh ):

#!/bin/bash

for port in $SERVER_PORT; do
    nc -z localhost $port;

    rc=$?

    if [[ $rc != 0 ]]; then
        echo "WARMUP";
        exit;
    fi
done

echo "RUNNING";

Collegamento del servizio di diagnostica a una porta:

nc -v -lk -p 7070 -e /assets/checkports.sh

È possibile utilizzare wait-for-it ", uno script bash puro che attenderà la disponibilità di una porta host e TCP. È utile per sincronizzare lo spin-up di servizi interdipendenti, come i contenitori docker collegati. Poiché è un puro script bash, non ha dipendenze esterne ".

Tuttavia, dovresti provare a progettare i tuoi servizi per evitare questo tipo di interdipendenze tra i servizi. Il tuo servizio può provare a riconnettersi al database? Puoi lasciare che il tuo container muoia se non riesce a connettersi al database e lasciare che un orchestratore di container (ad esempio Docker Swarm) lo faccia per te?

Per verificare se un container Docker PostgreSQL o MySQL (attualmente) è attivo e funzionante (specialmente per strumenti di migrazione come Flyway), puoi utilizzare il file binario wait-for : https://github.com/ArcanjoQueiroz/wait-for .

Soluzione Docker-compose

Dopo docker-compose non conosco il nome del container docker, quindi uso

docker inspect -f {{.State.Running}} $(docker-compose ps -q <CONTAINER_NAME>)

e controllando truecome qui https://stackoverflow.com/a/33520390/7438079

Per l'istanza docker di mongoDB abbiamo fatto questo e funziona come un fascino:

#!/usr/bin/env bash

until docker exec -i ${MONGO_IMAGE_NAME} mongo -u ${MONGO_INITDB_ROOT_USERNAME} -p ${MONGO_INITDB_ROOT_PASSWORD}<<EOF
exit
EOF
do
    echo "Waiting for Mongo to start..."
    sleep 0.5
done