Come ottenere una console di debug quando un container Docker si chiude subito

Exited (127): il container blog-testprod-django-testprod-1 si spegne subito dopo docker compose up -d. La guida mostra come aprire una console di debug per capire perché fallisce l’avvio¹.

Il flusso parte dalla build. L’autore costruisce l’immagine con docker compose build someservice, in alternativa con docker build .. Poi avvia lo stack con docker compose up -d. Uno dei servizi però non resta su: si chiude all’istante¹.

Per individuare il problema usa un solo comando, docker ps -a. L’output elenca il container fallito con stato “Exited (127) 1 second ago” e nome blog-testprod-django-testprod-1. La colonna IMAGE riporta blog-testprod-django-testprod. La colonna COMMAND mostra un comando troncato, “/bin/sh /app/entryp…”. Nello stesso elenco compaiono altri container attivi: un nginx:stable-alpine esposto su 0.0.0.0:8001->80/tcp con stato “Up 38 minutes”, un axllent/mailpit con porte 1025/tcp e 1110/tcp e la mappatura 0.0.0.0:8026->8025/tcp con stato “Up 39 minutes”. In coda si vede anche postgres:17¹.

L’obiettivo è ottenere una console interattiva collegata all’immagine che fallisce. Serve per osservare l’ambiente, verificare percorsi, eseguire a mano i comandi di avvio. Invece di riavviare alla cieca, si entra nel contesto del container e si riproduce il bootstrap passo per passo¹.

I dati raccolti orientano il debug. Nome del container e dell’immagine, comando mostrato nella colonna COMMAND, codice di uscita. Bastano per ancorare l’indagine alla risorsa giusta e al punto esatto in cui l’esecuzione si interrompe¹.

La procedura in pagina mette in fila i passaggi essenziali. Primo: costruire le immagini. Secondo: avviare i servizi. Terzo: usare docker ps -a per trovare il container “Exited”, leggere immagine, comando e stato. Quarto: aprire una console di debug legata a quella immagine o a quel container, così da testare direttamente ciò che l’entrypoint tenta di eseguire. La guida limita il perimetro a quanto necessario per arrivare alla shell e indagare, senza introdurre variazioni strutturali allo stack¹.

Anche il contesto dello stack aiuta. I container “Up” espongono porte e restano stabili. Quello in errore no. La differenza emerge subito dall’output, che affianca nomi, immagini, comandi, stato e mapping delle porte. Questo consente di isolare il servizio incriminato quando l’elenco contiene molte righe e componenti eterogenei¹.

Un dettaglio pratico chiude il cerchio: annotare immagine, comando e stato dal docker ps -a prima di aprire la console riduce tentativi a vuoto. Con quei tre elementi sotto mano, il passaggio al debugging interattivo diventa ripetibile anche su stack più ampi, dove più servizi partono e solo uno cade all’istante¹.