Debugging containerized applications involves inspecting logs, getting a shell inside containers, examining configuration and state, and diagnosing common issues (crashes, networking, resources). Knowing how to troubleshoot is essential practical skill.
docker ps -a
docker logs <container>
docker logs -f -- 100 <container>
docker inspect <container>
docker events
docker logs is usually the first step — it shows the application's output and errors. docker ps -a reveals if a container exited (and its exit code).
# 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 gives a shell inside a running container — invaluable for inspecting files, checking the environment, and testing connectivity from the container's perspective.
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
Knowing how to debug and troubleshoot Docker containers is essential practical skill, because containerized applications inevitably have issues (crashes, connectivity problems, configuration errors) that must be diagnosed, and the containerized environment adds a layer that requires specific debugging techniques.
The foundational skills — inspecting logs (docker logs, usually the first step, showing the application's output and errors), checking status (docker ps -a revealing if and why a container exited, including exit codes), and examining configuration/state (docker inspect) — are how you start diagnosing most issues.
Getting a shell inside a container (docker exec -it ... bash) is an invaluable technique for investigating from the container's perspective — inspecting files, checking the environment, and testing connectivity — and knowing how to get a shell even when a container won't stay running (overriding the entrypoint) handles tricky cases.
Understanding common issues and their diagnosis is particularly valuable: containers exiting immediately (the main process crashed or finished — checking logs and CMD/ENTRYPOINT), inter-container connectivity problems (network membership, using service names not localhost), ports not accessible (mapping, and the common gotcha that the app must listen on 0.0.0.0 not 127.0.0.1), out-of-memory kills, and permission errors — these are the real, recurring problems that knowing how to recognize and fix saves significant time.
Since containerized applications have issues that must be debugged, and since effective troubleshooting (logs, exec into containers, inspect, and recognizing common failure patterns) is necessary to diagnose and resolve them, knowing how to debug Docker containers is essential, frequently-applied practical skill for anyone running containerized applications, a core operational competency that turns frustrating container problems into solvable ones.