The Commands You'll Use Every Day

In one line

A focused set of flags for docker run, plus exec, logs, and inspect — the small toolkit that covers the vast majority of real day-to-day Docker work.

0/4 · 0%

Key ideas

01
docker run flags worth memorizing: -d (detached — runs in the background, returns your terminal immediately), -it (interactive + a pseudo-terminal — for a shell you can type into), --name (a human-readable name instead of a random one), -p host:container (maps a port on your machine to a port inside the container), -e KEY=VALUE (sets an environment variable), --rm (auto-remove the container the instant it stops — great for throwaway/test containers).
02
docker exec -it <container> <command> runs a NEW command inside an ALREADY-RUNNING container — most commonly docker exec -it mycontainer bash (or sh if bash isn't installed) to get an interactive shell inside a live container for debugging. This is different from docker run, which creates a brand-new container.
03
docker logs <container> shows the STDOUT/STDERR output the container's main process has printed since it started — your first stop when a container isn't behaving as expected. Add -f to follow the log stream live (like tail -f), and --tail 100 to see just the last 100 lines instead of the entire history.
04
docker inspect <container> dumps a huge JSON blob with EVERY detail about a container: its IP address, mounted volumes, environment variables, restart policy, exact image digest, and more — the deep-dive tool when you need one specific fact and don't want to guess.
05
docker cp <container>:/path/in/container ./local-path copies files OUT of a container (and docker cp ./file <container>:/path copies them in), even from a stopped container. It is handy for grabbing a heap dump, a generated report, or a log file that was never sent to stdout. Copying files INTO a running container to fix something is a debugging trick only: the change disappears with the container, so the real fix belongs in the image.
06
docker port <container> quickly shows just the port mappings, without wading through the full inspect JSON.
07
A container that crashes just... stays stopped, by default — nobody restarts it for you. The --restart flag fixes this: --restart unless-stopped (the common sensible default) restarts the container automatically on crash OR on a host reboot, EXCEPT when a human explicitly stopped it themselves; --restart always restarts it even after a manual stop; --restart on-failure only restarts on a non-zero exit code, not a clean exit.
08
Cleanup commands worth knowing: docker container prune removes ALL stopped containers at once. docker system prune is more aggressive — removes stopped containers, unused networks, dangling images, and build cache, reclaiming disk space (always read what it says it will remove before confirming).

In your stack

→
A very common real command for a Spring Boot app under active development: docker run -d --name myapp -p 8080:8080 -e SPRING_PROFILES_ACTIVE=docker myapp:latest — detached, named for easy reference, port 8080 exposed to your browser, and an environment variable telling Spring Boot which application-docker.properties profile to activate.

Code & diagrams

everyday-commands.shmarkdown

This block alone covers most of a typical day working with Docker.

# Run detached, named, port-mapped, with an env var, auto-removed on stop
docker run -d --name myapp -p 8080:8080 -e SPRING_PROFILES_ACTIVE=docker --rm myapp:latest

# Get an interactive shell INSIDE the already-running container
docker exec -it myapp bash

# Watch the app's logs live (like tail -f)
docker logs -f myapp

# See only the last 50 log lines, no live following
docker logs --tail 50 myapp

# Get every detail Docker knows about this container
docker inspect myapp

# Just the port mappings, quickly
docker port myapp

# Auto-restart on crash or host reboot, but not after a manual stop
docker run -d --name myapp --restart unless-stopped -p 8080:8080 myapp:latest

# Clean up every stopped container at once
docker container prune

# Nuclear cleanup: stopped containers + unused networks + dangling images + build cache
docker system prune

Explain it without notes

Why does docker exec -it mycontainer bash sometimes fail with 'executable file not found', and what's the usual fix?

What's the practical risk of habitually adding --rm to every docker run you type, and when is it clearly the right choice?

Practice

Run any container with -d, then use docker logs -f on it in one terminal while triggering some activity (like hitting a web server's port with curl) in another, and watch the logs update live.

Run docker inspect on any container and find its internal IP address in the JSON output (hint: look under NetworkSettings).

Trade-offs

↔
docker exec for debugging is fine for development, but relying on it to manually 'fix' a running production container (installing a missing package on the fly, editing a config file by hand) creates configuration drift — the fix disappears the moment the container restarts, and nobody else's containers get it either. The durable fix always belongs in the Dockerfile (Phase 2).

Done when you can

I can run a container with the right combination of -d, -it, --name, -p, -e, and --rm for a given scenario.
I reach for docker logs first whenever a container misbehaves.
I know exec is for debugging a live container, not for making permanent changes.
I set a --restart policy on any container that genuinely needs to survive a crash or reboot unattended.

Command Palette