Docker CLI Commands: Containers, Images, Logs, and Cleanup

The most useful way to remember Docker commands is not alphabetical. In real debugging, you usually list containers, read logs, inspect configuration, enter the running container, and only then decide whether to restart or clean up. Treat destructive cleanup commands as the last step, not the first reflex.

Check Docker itself

docker version
docker info
docker ps
docker ps -a

docker version shows client and server information. If you only see client details or a daemon connection error, Docker Desktop or the Docker daemon may not be running.

docker ps lists running containers. docker ps -a includes stopped containers, which is important when an app exits immediately.

Images

docker image ls
docker pull nginx:alpine
docker image inspect nginx:alpine
docker image history nginx:alpine
docker image rm nginx:alpine

Avoid relying on latest in production. Use explicit, traceable tags when possible. Before removing an image, check whether a container still uses it.

Build an image:

docker build -t my-app:1.0.0 .
docker build --pull -t my-app:1.0.0 .

For Dockerfile layering, build context, and .dockerignore, see Dockerfile and .dockerignore for Node.js Apps.

Run a container

docker run --name web -d -p 127.0.0.1:8080:80 nginx:alpine

Useful options:

• --name web gives the container a readable name.
• -d runs it in the background.
• -p 127.0.0.1:8080:80 maps host port 8080 to container port 80, limited to host loopback.
• --rm deletes the container after it stops, useful for one-off commands.
• -e KEY=value and --env-file pass runtime environment variables.

If a web app is still unreachable, check whether the app listens on localhost or 0.0.0.0. The difference is explained in localhost vs 0.0.0.0 in Docker.

Container lifecycle

docker start web
docker stop web
docker restart web
docker rename web web-old
docker rm web-old
docker rm -f web-old

docker stop sends a termination signal and waits. docker rm -f forcibly stops and removes the container, so use it only when you understand the data and task state. Removing a container does not automatically remove named volumes.

Logs and process checks

docker logs web
docker logs -f --tail 200 web
docker logs --since 30m web
docker top web
docker stats web

docker logs reads stdout and stderr collected by the container log driver. It may not include files that the app writes inside the container. On long-running servers, configure log rotation so container logs do not fill the disk.

Enter a running container

docker exec -it web sh
docker exec web env
docker cp web:/etc/nginx/nginx.conf ./nginx.conf

Alpine images usually have sh, not bash. docker exec runs a command inside an existing container; it does not create a new image. Manual edits inside a container disappear when the container is recreated, so permanent fixes belong in source files, Dockerfile, or mounted configuration.

Inspect configuration

docker inspect web
docker inspect --format '{{.State.Status}}' web
docker inspect --format '{{json .NetworkSettings.Networks}}' web

inspect is the main tool for checking ports, mounts, environment variables, restart policy, networks, and container state. Be careful when sharing the output publicly because it may include sensitive environment values.

Volumes and mounts

docker volume ls
docker volume create app-data
docker volume inspect app-data

docker run --rm \
  --mount type=volume,src=app-data,dst=/data \
  alpine ls -la /data

Named volumes are managed by Docker. Bind mounts map a host path directly into a container. Before deleting containers or pruning resources, check where important data actually lives and whether it is backed up.

Networks

docker network ls
docker network create app-net
docker network inspect app-net
docker network connect app-net web
docker network disconnect app-net web

Containers on the same user-defined network can usually resolve each other by container name. Do not hard-code container IP addresses because recreated containers may receive different addresses.

Disk usage and cleanup

Start with evidence:

docker system df
docker ps -a
docker image ls
docker volume ls

Then clean by type:

docker container prune
docker image prune
docker builder prune

docker system prune -a has a wider blast radius, and docker volume prune can delete unused volumes that still contain important data. Do not put broad prune commands into an unattended cron job unless the environment is designed for it.

A reliable debugging order

docker ps -a
docker logs --tail 200 web
docker inspect web
docker stats web
docker exec -it web sh

Collect facts before restarting. A restart may temporarily recover the service while destroying the evidence that explains why it failed.