Come mantenere in esecuzione il contenitore Docker dopo l'avvio dei servizi?

Ho visto un sacco di tutorial che sembrano fare la stessa cosa che sto cercando di fare, ma per qualche ragione i miei contenitori Docker escono. Fondamentalmente, sto installando un web server e alcuni demoni all'interno di un container Docker. Faccio le parti finali di questo tramite uno script bash chiamato run-all.shche corro attraverso CMD nel mio Dockerfile. run-all.shSomiglia a questo:

service supervisor start
service nginx start

E lo avvio all'interno del mio Dockerfile come segue:

CMD ["sh", "/root/credentialize_and_run.sh"]

Vedo che tutti i servizi si avviano correttamente quando eseguo le cose manualmente (ovvero accedendo all'immagine con -i -t / bin / bash) e tutto sembra funzionare correttamente quando eseguo l'immagine, ma esce una volta finisce di avviare i miei processi. Vorrei che i processi funzionassero indefinitamente e, per quanto ho capito, il contenitore deve continuare a funzionare perché ciò avvenga. Tuttavia, quando corro docker ps -a, vedo:

➜  docker_test  docker ps -a
CONTAINER ID        IMAGE                            COMMAND                CREATED             STATUS                      PORTS               NAMES
c7706edc4189        some_name/some_repo:blah   "sh /root/run-all.sh   8 minutes ago       Exited (0) 8 minutes ago                        grave_jones

Cosa dà? Perché sta uscendo? So che potrei semplicemente mettere un ciclo while alla fine del mio script bash per continuare, ma qual è il modo giusto per impedirgli di uscire?

Non è proprio così che dovresti progettare i tuoi contenitori Docker.

Quando si progetta un contenitore Docker, è necessario crearlo in modo che sia in esecuzione un solo processo (ovvero è necessario disporre di un contenitore per Nginx e uno per supervisord o l'app in esecuzione); inoltre, tale processo dovrebbe essere eseguito in primo piano.

Il contenitore "uscirà" quando termina il processo stesso (nel tuo caso, quel processo è il tuo script bash).

Tuttavia, se hai davvero bisogno (o desideri) di eseguire più servizi nel tuo contenitore Docker, prendi in considerazione di iniziare da "Immagine base Docker" , che utilizza runitcome processo pseudo-init ( runitrimarrà online mentre Nginx e Supervisor sono in esecuzione), che rimarrà in primo piano mentre gli altri tuoi processi fanno la loro parte.

Hanno documenti sostanziali, quindi dovresti essere in grado di ottenere ciò che stai cercando di fare ragionevolmente facilmente.

Se si utilizza un file Docker, provare:

ENTRYPOINT ["tail", "-f", "/dev/null"]

(Ovviamente questo è solo a scopo di sviluppo, non dovresti aver bisogno di mantenere in vita un contenitore a meno che non stia eseguendo un processo ad es. Nginx ...)

Ho appena avuto lo stesso problema e ho scoperto che se stai eseguendo il tuo container con il -te -dflag, continua a funzionare.

docker run -td <image>

Ecco cosa fanno le bandiere (secondo docker run --help):

-d, --detach=false         Run container in background and print container ID
-t, --tty=false            Allocate a pseudo-TTY

La più importante è la -tbandiera. -dti consente di eseguire il contenitore in background.

Il motivo per cui esce è perché lo script della shell viene eseguito prima come PID 1 e quando è completo, PID 1 è sparito e la finestra mobile viene eseguita solo mentre lo è PID 1.

Puoi usare il supervisore per fare tutto, se eseguito con il flag "-n" viene detto di non demonizzare, quindi rimarrà il primo processo:

CMD ["/usr/bin/supervisord", "-n"]

E il tuo supervisord.conf:

[supervisord]
nodaemon=true

[program:startup]
priority=1
command=/root/credentialize_and_run.sh
stdout_logfile=/var/log/supervisor/%(program_name)s.log
stderr_logfile=/var/log/supervisor/%(program_name)s.log
autorestart=false
startsecs=0

[program:nginx]
priority=10
command=nginx -g "daemon off;"
stdout_logfile=/var/log/supervisor/nginx.log
stderr_logfile=/var/log/supervisor/nginx.log
autorestart=true

Quindi è possibile avere tutti gli altri processi desiderati e il supervisore gestirà il riavvio di essi, se necessario.

In questo modo potresti usare supervisord nei casi in cui potresti aver bisogno di nginx e php5-fpm e non ha molto senso separarli.

puoi eseguire il tutto catsenza alcun argomento, come menzionato da bro @ Sa'ad per mantenere il contenitore funzionante [in realtà non facendo altro che aspettare l'input dell'utente] (il plugin Docker di Jenkins fa la stessa cosa)

Assicurati di aggiungere daemon off;nginx.conf o eseguirlo CMD ["nginx", "-g", "daemon off;"]come da immagine nginx ufficiale

Quindi utilizzare quanto segue per eseguire sia supervisore come servizio che nginx come processo in primo piano che impedirà la chiusura del contenitore

service supervisor start && nginx

In alcuni casi dovrai avere più di un processo nel tuo contenitore, quindi forzare il contenitore ad avere esattamente un processo non funzionerà e può creare più problemi nella distribuzione.

Quindi devi capire i compromessi e prendere la tua decisione di conseguenza.

Motivazione:

Non c'è nulla di sbagliato nell'esecuzione di più processi all'interno di un contenitore finestra mobile . Se a uno piace usare la finestra mobile come una VM leggera, così sia. Ad altri piace dividere le loro applicazioni in micro servizi. Me pensa: uno stack LAMP in un contenitore? Semplicemente fantastico.

La risposta:

Stick con una buona immagine di base come l' immagine di base di fusione . Potrebbero essercene altri. Per favore, commenta.

E questo è l'ennesimo appello per il supervisore. Perché l'immagine di base di phusion fornisce supervisore oltre ad alcune altre cose come cron e impostazioni locali. Roba che ti piace avere configurato quando esegui una VM così leggera. Per quello che vale, fornisce anche connessioni ssh nel contenitore.

L'immagine di phusion stessa si avvierà e continuerà a funzionare se si emette questa istruzione di esecuzione docker di base:

moin@stretchDEV:~$ docker run -d phusion/baseimage
521e8a12f6ff844fb142d0e2587ed33cdc82b70aa64cce07ed6c0226d857b367
moin@stretchDEV:~$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS
521e8a12f6ff        phusion/baseimage   "/sbin/my_init"     12 seconds ago      Up 11 seconds

O morto semplice:

Se un'immagine di base non fa per te ... Per la rapida CMD per mantenerla in esecuzione suppongo qualcosa di simile per bash:

CMD exec /bin/bash -c "trap : TERM INT; sleep infinity & wait"

O questo per busybox:

CMD exec /bin/sh -c "trap : TERM INT; (while true; do sleep 1000; done) & wait"

Questo è carino, perché uscirà immediatamente su a docker stop. Semplicemente sleepo catimpiegherà qualche secondo prima che il contenitore esca.

Cattura il PID del processo ngnix in una variabile (ad esempio $ NGNIX_PID) e alla fine del file entrypoint do

wait $NGNIX_PID 

In questo modo, il contenitore dovrebbe funzionare fino a quando ngnix è in vita, quando ngnix si ferma, anche il contenitore si ferma

Che ne dici di usare il servizio di supervisione se disponibile?

l'assistenza YOUR_SERVICE supervisiona

Una volta che la supervisione è stata eseguita correttamente, non si chiuderà se non viene ucciso o non viene richiesto espressamente di uscire.

Salva dover creare un supervisord.conf