The Container Lifecycle (The Restaurant Shift Analogy)
LEVEL 0
The Problem
Starting a container is straightforward: docker run nginx. But then what?
- How do you stop it gracefully?
- What if you want to restart it?
- What happens to changes you made inside?
- When should you remove a container vs restart it?
Understanding the full lifecycle helps you manage containers like a professional.
LEVEL 1
The Concept — The Restaurant Shift
The Concept
Think about managing staff in a restaurant.
Hiring (docker create): You’ve decided to hire someone. They’re on the roster, they have a uniform ready, but they haven’t worked a shift yet.
First Shift (docker start / docker run): The employee clocks in and starts working. They’re active, serving customers, making changes to the restaurant (restocking shelves, moving furniture).
Break Time (docker pause): Employee takes a break. They’re still at work, still technically on shift, but frozen in place. When break ends, they continue exactly where they left off.
End of Shift (docker stop): Employee clocks out. Their shift is recorded, any work they did is noted. They can come back tomorrow (restart), but right now they’re off.
Leaving the Company (docker rm): Employee is terminated. Their uniform is returned, their locker is cleared out. To get work done, you’d need to hire someone new.
The key insight: An employee who clocked out (stopped) is different from an employee who left the company (removed). Stopped containers can return. Removed containers are gone.
LEVEL 2
The Mechanics — Lifecycle Commands
The Mechanics
Creating Without Starting
docker create --name myapp nginx
Container exists but isn’t running. Useful when you want to configure something before starting, or for creating containers in advance.
Starting
docker start myapp
Starts a created or stopped container. The main process begins execution.
The All-in-One: docker run
docker run --name myapp nginx
This is docker create + docker start in one command. Most common way to work with containers.
Stopping Gracefully
docker stop myapp
- Sends SIGTERM to the main process
- Gives it 10 seconds (default) to clean up
- If still running, sends SIGKILL
The graceful period allows applications to:
- Finish current requests
- Close database connections
- Write final log entries
- Save state
Stopping Forcefully
docker kill myapp
Sends SIGKILL immediately. The process has no chance to clean up. Use this only when docker stop doesn’t work.
Restarting
docker restart myapp
Equivalent to docker stop + docker start. Useful for applying configuration changes or recovering from issues.
Removing
docker rm myapp # Only works on stopped containers
docker rm -f myapp # Force removes running container (stop + rm)
LEVEL 3
Restart Policies
What should happen when a container stops? Docker can automatically restart it.
# Never restart (default)
docker run --restart=no nginx
# Always restart (even after reboot)
docker run --restart=always nginx
# Restart only on failure (non-zero exit)
docker run --restart=on-failure nginx
# Restart on failure, max 3 times
docker run --restart=on-failure:3 nginx
# Always, unless manually stopped
docker run --restart=unless-stopped nginx
When to Use Each:
| Policy | Use Case |
|---|---|
no | One-time tasks, development |
always | Production services that must always run |
on-failure | Tasks that should retry on error |
unless-stopped | Production, but respects manual stops |
LEVEL 4
What Survives Container Restarts
When you restart a container:
Survives:
- Container’s writable layer (files created inside)
- Environment variables set at creation
- Network settings
- Volume mounts
Lost:
- Running process state (memory)
- Anything in tmpfs mounts
- Non-persisted application state
This is why applications need to be designed to handle restarts — they should save important state to disk or external systems.