Debugging a Running Docker Container

Direct Answer

Begin with docker ps, docker logs, docker inspect, docker stats, and application health checks. Use docker exec -it <container> sh only if the image contains a shell and policy permits it; minimal/distroless images may not. Inspect configuration carefully because environment output can contain secrets, and reproduce long investigations from the image/Dockerfile rather than changing a running container.

Code Example

// Step 1: Check application logs
docker logs --tail 100 -f order-api

// Step 2: Open shell inside running container
docker exec -it order-api /bin/bash

// Inside container: check if config file exists
ls -la /app/config/

// Inside container: verify environment variables
env | grep DATABASE

// Inside container: test network connectivity
curl http://localhost:8080/actuator/health

// Step 3: Inspect container configuration
docker inspect order-api

// Filter inspect output for specific info (environment variables)
docker inspect -f '{{.Config.Env}}' order-api

// Monitor real-time resource usage
docker stats order-api

// See running processes inside container
docker top order-api

Common Mistakes & Pitfalls

• Only using docker logs: Freshers stop at logs and give up when the error isn't obvious. They don't realize they can open a shell with docker exec and poke around inside the container to check files, test commands, or verify configuration.
• Forgetting -it flags on docker exec: Running docker exec without -i -t results in non-interactive or missing terminal output. The -it combination is essential — -i keeps stdin open, -t allocates a pseudo-TTY for proper terminal behavior.
• Not having debugging tools in the image: Opening a shell with docker exec only to find curl, wget, and even ls are missing because the base image is Alpine or a distroless variant. Production images strip unnecessary tools, but during debugging you need them — either use a different base image for dev or install tools temporarily.