Running and Managing Containers

Analogy categoryAnalogies

From Image to Running Container

A Docker image is a read-only template; a container is a running (or stopped) instance of that image with its own writable layer, process namespace, and network stack. Managing containers day-to-day means creating them, observing their state, interacting with them, and cleaning them up.

🏏

Cricket analogy: Like a coaching manual (image) being a fixed reference while an actual training session (container) run from it can be paused, adjusted, or ended, a Docker image is a read-only template and a container is its running instance.

Starting a Container with docker run

The docker run command creates and starts a container in one step. Common flags control detachment, naming, port mapping, and automatic removal.

🏏

Cricket analogy: Like a captain calling 'play' to send the whole XI onto the field in one command rather than walking each player out individually, docker run creates and starts a container in a single step with flags for naming and ports.

bash

# Run an nginx web server in the background, name it, map host port 8080 to container port 80
docker run -d --name web -p 8080:80 nginx:1.27

# Run an interactive shell in a temporary container that is removed on exit
docker run -it --rm ubuntu:22.04 bash

# Run a container with a restart policy
docker run -d --name api --restart unless-stopped myapp:1.0

-d runs the container detached (in the background); without it, the container's process output streams to your terminal and Ctrl+C stops the container.

Listing and Inspecting Containers

docker ps shows running containers; add -a to include stopped ones. docker inspect returns detailed JSON metadata such as IP address, mounts, and environment variables.

🏏

Cricket analogy: Like checking the live scoreboard for teams currently batting versus pulling the full match archive including completed games, docker ps shows running containers, and -a includes stopped ones; docker inspect gives detailed match metadata.

bash

docker ps                       # running containers only
docker ps -a                    # all containers, including exited
docker inspect web               # full JSON details for container 'web'
docker inspect -f '{{.State.Status}}' web   # just the status field

Viewing Logs and Executing Commands

docker logs retrieves stdout/stderr from a container's main process, which is essential for debugging without attaching a terminal. docker exec runs an additional command inside an already-running container, commonly used to open a debug shell.

🏏

Cricket analogy: Like reviewing a player's ball-by-ball commentary feed to debug a poor performance without interviewing them live, docker logs retrieves stdout/stderr, while docker exec lets you step into the dressing room mid-match to talk to them directly.

bash

docker logs web                 # print all logs
docker logs -f --tail 100 web   # follow the last 100 lines live
docker exec -it web sh          # open an interactive shell inside the running container
docker exec web cat /etc/nginx/nginx.conf

Stopping, Restarting, and Removing Containers

docker stop sends SIGTERM (then SIGKILL after a grace period) to gracefully shut down a container's main process. docker rm deletes the container's writable layer and metadata; it must be stopped first unless you use -f.

🏏

Cricket analogy: Like an umpire signaling a batter off the field with a warning before forcibly removing them if they linger (SIGTERM then SIGKILL), docker stop gracefully shuts a container down, and docker rm clears their name from the scorebook, requiring they've left first.

bash

docker stop web                 # graceful stop (default 10s grace period)
docker stop -t 30 web            # give it 30 seconds before SIGKILL
docker start web                 # restart a stopped container
docker restart web               # stop then start
docker rm web                    # remove a stopped container
docker rm -f web                 # force-stop and remove in one step
docker container prune           # remove ALL stopped containers

docker rm -f and docker container prune are destructive and cannot be undone — any data in the container's writable layer (not stored in a volume) is lost permanently.

docker run = create + start; -d detaches, --name labels, -p host:container maps ports, --rm auto-cleans on exit
docker ps -a lists all containers including stopped ones; docker ps alone shows only running ones
docker stop sends SIGTERM first, then SIGKILL after the grace period (default 10s, configurable with -t)
docker exec -it <container> sh opens a shell inside an already-running container; it does not start a new container
docker logs -f follows log output live, similar to tail -f
Container data in the writable layer is ephemeral and lost on docker rm unless backed by a volume