Everyday container commands

The commands you'll type a hundred times a day

Running a container is the easy part. The commands in this lesson are the ones you actually live in day to day — checking why something isn't working, looking inside a running container, or getting a shell to poke around.

Viewing logs

Whatever a containerized process writes to standard output/error is captured by Docker as that container's logs — you don't need to configure logging separately for this to work.

docker logs -f is usually the very first command to reach for when a container isn't behaving — it's the container's equivalent of checking the console output of a normal program.

Getting a shell inside a running container

Sometimes logs aren't enough and you need to look around inside the container itself — check if a file exists, test a network call from inside its namespace, or inspect an environment variable. docker exec runs a new command inside an already running container:

• -i (interactive) keeps STDIN open so you can type into it.
• -t (tty) allocates a pseudo-terminal so it looks and behaves like a normal shell.
• Together, -it is what makes this feel like SSH-ing into the container.

Not every image ships bash — many minimal images (especially ones based on Alpine Linux) only have sh: If both fail with "no such file or directory," the image genuinely has no shell binary at all (common in very minimal production images) — in that case, docker logs and docker inspect are your only windows into it.

Inspecting a container's full configuration

docker inspect dumps a container's complete configuration as JSON — its IP address, mounted volumes, environment variables, resource limits, restart policy, everything: That output is long. In practice, you almost always want one specific field, so use --format with Go template syntax to extract just it:

Checking resource usage live

docker stats shows a live, continuously updating view of CPU, memory, and network usage per container — the container equivalent of top:

This is the fastest way to confirm whether a cgroup memory limit is about to trigger an OOM kill, or whether a container is quietly spinning your CPU.

Copying files in and out

docker cp moves files between the host and a container's filesystem, in either direction, without needing a shell inside the container:

Handy for pulling out a log file or a generated report without setting up a shared volume (covered in the next module) just for a one-off copy.

Cleaning up

Docker accumulates stopped containers, unused images, and dangling data over time. A few cleanup commands worth knowing before things pile up:

Putting it together: a realistic debugging flow

A typical "why isn't this working" sequence looks like:

Between logs, exec, and inspect, you can diagnose the overwhelming majority of container problems without needing any external tooling.

What's next

Every image so far in this course has been pulled from Docker Hub. The next lesson writes your first Dockerfile — the recipe for building your own images.