Il debug delle applicazioni containerizzate comporta l'ispezione dei log, l'accesso a una shell all'interno dei container, l'esame della configurazione e dello stato, e la diagnosi dei problemi comuni (crash, networking, risorse). Sapere come risolvere i problemi è un'abilità pratica essenziale.
docker ps -a
docker logs <container>
docker logs -f -- 100 <container>
docker inspect <container>
docker events
docker logs è di solito il primo passo — mostra l'output e gli errori dell'applicazione. docker ps -a rivela se un container è uscito (e il suo codice di uscita).
# run an interactive shell inside a RUNNING container to investigate
docker exec -it <container> bash # or sh (alpine)
# → inspect files, run commands, check the environment, test connectivity from inside
# if the container won't STAY running, override the entrypoint to get a shell
docker run -it --entrypoint sh myimage
docker exec -it ... bash fornisce una shell all'interno di un container in esecuzione — inestimabile per ispezionare file, controllare l'ambiente e testare la connettività dalla prospettiva del container.
Container EXITS immediately → check `docker logs`; the main process crashed or finished
(a container stops when its main process exits) — check CMD/ENTRYPOINT, errors
CAN'T CONNECT between containers → check they're on the same network; use service NAMES
(not localhost); verify ports; `docker network inspect`
PORT not accessible → check -p mapping; the app must listen on 0.0.0.0 (not 127.0.0.1)
OUT OF MEMORY / killed → check `docker stats`, resource limits (OOMKilled in inspect)
PERMISSION errors → file ownership/user (non-root user vs mounted volume permissions)
IMAGE issues → rebuild without cache (--no-cache); check the build context/.dockerignore
Sapere come eseguire il debug e la risoluzione dei problemi nei container Docker è un'abilità pratica essenziale, perché le applicazioni containerizzate inevitabilmente hanno problemi (crash, problemi di connettività, errori di configurazione) che devono essere diagnosticati, e l'ambiente containerizzato aggiunge un livello che richiede tecniche di debug specifiche.
Le abilità fondamentali — ispezionare i log (docker logs, di solito il primo passo, che mostra l'output e gli errori dell'applicazione), controllare lo stato (docker ps -a che rivela se e perché un container è uscito, inclusi i codici di uscita), e esaminare configurazione/stato (docker inspect) — sono il modo in cui inizi a diagnosticare la maggior parte dei problemi.
Ottenere una shell all'interno di un container (docker exec -it ... bash) è una tecnica inestimabile per investigare dalla prospettiva del container — ispezionare file, controllare l'ambiente e testare la connettività — e sapere come ottenere una shell anche quando un container non rimane in esecuzione (sovrascrivendo l'entrypoint) affronta i casi complicati.
Comprendere i problemi comuni e la loro diagnosi è particolarmente prezioso: container che escono immediatamente (il processo principale è crash o è finito — controllare i log e CMD/ENTRYPOINT), problemi di connettività tra container (appartenenza alla rete, usando nomi di servizio non localhost), porte non accessibili (mapping, e il gotcha comune che l'app deve ascoltare su 0.0.0.0 non 127.0.0.1), kill per esaurimento memoria, e errori di permesso — questi sono i problemi reali e ricorrenti che sapere come riconoscere e risolvere ti fa risparmiare tempo significativo.
Poiché le applicazioni containerizzate hanno problemi che devono essere debuggati, e poiché una risoluzione dei problemi efficace (log, exec nei container, inspect, e riconoscimento dei pattern di guasto comuni) è necessaria per diagnosticare e risolverli, sapere come eseguire il debug dei container Docker è un'abilità pratica essenziale, frequentemente applicata per chiunque esegua applicazioni containerizzate, una competenza operativa centrale che trasforma i frustranti problemi dei container in problemi risolvibili.
Una raccolta di domande di colloquio IT con risposte dettagliate — da Junior a Senior.
Dona