Come avviare un contenitore Docker arrestato con un comando diverso?

Vorrei avviare un container Docker arrestato con un comando diverso, poiché il comando predefinito si interrompe, ovvero non è ansible avviare il contenitore e quindi utilizzare “docker exec”.

Fondamentalmente mi piacerebbe avviare una shell in modo da poter ispezionare il contenuto del contenitore.

Fortunatamente ho creato il contenitore con l’opzione -it!

Trova il tuo id del contenitore fermato

docker ps -a 

Impegna il contenitore fermato:

Questo comando salva lo stato del contenitore modificato in una nuova immagine user/test_image

 docker commit $CONTAINER_ID user/test_image 

Avvia / esegui con un punto di ingresso diverso:

 docker run -ti --entrypoint=sh user/test_image 

Descrizione dell’argomento del punto di accesso: https://docs.docker.com/engine/reference/run/#/entrypoint-default-command-to-execute-at-runtime

Nota:

Passaggi sopra appena avviare un contenitore arrestato con lo stesso stato del file system. È fantastico per una rapida investigazione. Ma le variabili di ambiente, la configurazione di rete, i volumi allegati e altro personale non sono ereditati, è necessario specificare tutti questi argomenti in modo esplicito.

I passaggi per avviare un container interrotto sono stati presi in prestito da qui: (ultimo commento) https://github.com/docker/docker/issues/18078

Modifica questo file (corrispondente al tuo contenitore fermato):

 vi /var/lib/docker/containers/923...4f6/config.json 

Modificare il parametro “Percorso” per puntare al nuovo comando, ad esempio / bin / bash. È anche ansible impostare il parametro “Args” per passare argomenti al comando.

Riavvia il servizio finestra mobile (nota che ciò interromperà tutti i contenitori in esecuzione):

 service docker restart 

Elenca i tuoi contenitori e assicurati che il comando sia cambiato:

 docker ps -a 

Avvia il contenitore e attacca ad esso, ora dovresti essere nella tua shell!

 docker start -ai mad_brattain 

Funzionato con Fedora 22 usando Docker 1.7.1.

NOTA: se la tua shell non è intertriggers (ad esempio non hai creato il contenitore originale con l’opzione -it), puoi invece cambiare il comando in “/ bin / sleep 600” o “/ bin / tail -f / dev / null” per darti il ​​tempo necessario per eseguire “docker exec -it CONTID / bin / bash” come un altro modo per ottenere una shell.

Aggiungi un segno di spunta alla parte superiore del tuo script Entrypoint

Docker ha davvero bisogno di implementarlo come una nuova funzionalità, ma ecco un’altra soluzione alternativa per situazioni in cui hai un punto di accesso che termina dopo il successo o l’insuccesso, il che può rendere difficile il debug.

Se non si dispone già di uno script Entrypoint, crearne uno che esegua i comandi necessari per il contenitore. Quindi, all’inizio di questo file, aggiungi queste linee a entrypoint.sh :

 # Run once, hold otherwise if [ -f "already_ran" ]; then echo "Already ran the Entrypoint once. Holding indefinitely for debugging." cat fi touch already_ran # Do your main things down here 

Per garantire che il cat tenga la connessione, potrebbe essere necessario fornire un TTY. Sto eseguendo il contenitore con il mio script Entrypoint in questo modo:

 docker run -t --entrypoint entrypoint.sh image_name 

Ciò causerà l’esecuzione dello script una volta, creando un file che indica che è già stato eseguito (nel filesystem virtuale del contenitore). È quindi ansible riavviare il contenitore per eseguire il debug:

 docker start container_name 

Quando si riavvia il contenitore, verrà trovato il file already_ran , causando l’interruzione dello script Entrypoint con cat (che attende solo per sempre un input che non arriverà mai, ma mantiene il contenitore attivo). È quindi ansible eseguire una sessione bash debug:

 docker exec -i container_name bash 

Mentre il contenitore è in esecuzione, puoi anche rimuovere already_ran ed eseguire manualmente lo script di entrypoint.sh per entrypoint.sh nuovamente, se hai bisogno di eseguire il debug in questo modo.

Ho preso la risposta di @Dmitriusan e l’ho trasformata in uno pseudonimo:

alias docker-run-prev-container = ‘prev_container_id = “$ (finestra mobile ps -aq | testa -n1)” && docker commit “$ prev_container_id” “prev_container / $ prev_container_id” && finestra mobile run -it –entrypoint = bash “prev_container / $ prev_container_id “‘

Aggiungi questo nel tuo file alias ~/.bashrc e avrai un nuovo alias di docker docker-run-prev-container che ti lascerà in una shell nel contenitore precedente.

Utile per il debug di docker build falliti.

Non è stato specificato se il contenitore sta uscendo, solo che il tuo codice si blocca e devi vedere cosa sta succedendo nel contenitore. Se non sta uscendo, ecco un’altra potenziale soluzione.

Ottieni l’id del contenitore con la docker ps

docker exec -it 665b4a1e17b6 /bin/sh

Se entrypoint è impostato su qualcosa di problematico, può anche essere ignorato come suggerito nella risposta di Dmitriusan. Si noti inoltre che è ansible albind a qualsiasi contenitore in esecuzione con docker attach . Così tante soluzioni diverse soluzioni. Non vedo la necessità di impegnarmi sull’immagine. Sembra inutile.

Esecuzioni di Documenti per Docker – https://docs.docker.com/engine/reference/commandline/exec/

Docs for Docker attach – https://docs.docker.com/engine/reference/commandline/attach/

 docker container start  

In realtà non sono d’accordo con entrambe queste risposte. Se vuoi solo vedere cosa c’è nel contenitore, puoi eseguire questo comando per ottenere una shell. Non c’è bisogno di cambiare l’entry point in tutte le configurazioni.

 docker run -it  bash