The Container Lifecycle

In one line

Created, Running, Paused, Stopped, Removed — a container moves through distinct states, and knowing exactly which command moves it between which states is the difference between confidently debugging and randomly guessing.

0/4 · 0%

Think of it like this

A car's lifecycle. PARKED (created but engine off) → DRIVING (running) → PULLED OVER with engine idling (paused) → PARKED again (stopped) → SCRAPPED (removed, gone forever). Each state has a specific action that moves you to the next.

Key ideas

01
CREATED: docker create <image> makes a container but does NOT start it — rare to use directly, but it's the first real state.
02
RUNNING: docker start <container> (existing) or docker run <image> (create + start in one step) — the container's main process is actively executing.
03
PAUSED: docker pause <container> freezes ALL processes inside the container (using a kernel-level freeze, cgroups) without stopping them — useful for briefly freezing a container's CPU usage without losing its running state. docker unpause resumes it exactly where it left off.
04
STOPPED (Exited): docker stop <container> sends a graceful shutdown signal (SIGTERM, then SIGKILL after a grace period) — the container's process ends, but the container itself (its filesystem, its ID, its config) still exists on disk.
05
REMOVED: docker rm <container> permanently deletes a stopped container's filesystem and metadata. You cannot remove a RUNNING container without -f (force), which stops it first.
06
docker restart is a shortcut for stop + start. docker kill is like docker stop but skips the graceful SIGTERM and sends SIGKILL immediately — use stop by default, reach for kill only when a container is genuinely unresponsive.
07
A stopped container still occupies disk space and a container NAME (you can't reuse the same --name for a new container until the old stopped one is removed) — this is the single most common 'why won't my container start, it says the name is already in use' beginner error.

In your stack

→
Graceful shutdown matters enormously for a Spring Boot app: docker stop sends SIGTERM, and Spring Boot's graceful shutdown (server.shutdown=graceful in application.properties) listens for that signal to finish in-flight requests before exiting — docker kill skips this entirely and can drop active requests mid-flight.

Code & diagrams

lifecycle-commands.shmarkdown

The exact command for every transition in the state diagram.

# CREATE (rare to use alone) — makes the container, doesn't start it
docker create --name mycontainer nginx

# START — moves CREATED or STOPPED -> RUNNING
docker start mycontainer

# PAUSE / UNPAUSE — freeze/unfreeze a RUNNING container in place
docker pause mycontainer
docker unpause mycontainer

# STOP — graceful shutdown (SIGTERM, then SIGKILL after ~10s grace period)
docker stop mycontainer

# KILL — immediate shutdown (SIGKILL right away), use when unresponsive
docker kill mycontainer

# RESTART — shortcut for stop + start
docker restart mycontainer

# REMOVE — permanently delete a STOPPED container
docker rm mycontainer

# The "I don't care, just get rid of it" combo — force-remove even if running
docker rm -f mycontainer

ContainerLifecyclediagram

Every arrow here is one of the commands above.

Rendering diagram…

Explain it without notes

Why does docker run --name web nginx fail with 'name already in use' even though docker ps shows nothing running with that name?

What's the practical difference between docker stop and docker kill, and when would you deliberately choose kill?

Practice

Start a container, pause it, and while paused, try running docker exec into it — observe and explain what happens.

Create (don't start) a container with docker create, confirm it appears in docker ps -a with a status that isn't 'Up' or 'Exited', then start it.

Trade-offs

↔
Always reaching for docker rm -f out of convenience skips graceful shutdown entirely — fine for throwaway dev containers, but a habit that will eventually drop in-flight work if applied carelessly to a production container serving real traffic.

Done when you can

I can draw the full container lifecycle state diagram from memory.
I know exactly which command moves a container between any two states.
I understand why a stopped container still blocks its name from reuse.

Command Palette