Container Lifecycle: From Create to Remove
A container is a state machine: created, running, paused, stopped, and removed. You manage this with commands like docker run, while orchestrators automate it. The footgun: stop doesn't delete a container; you must rm it to free up disk space.
Why it exists
To provide predictable control over application instances. Unlike a simple process, a container bundles its environment. Managing its lifecycle—from a clean start to a graceful shutdown and cleanup—is crucial for reliable, reproducible deployments, especially at scale.
The mental model
A container is like a disposable appliance with an on/off switch. You can create it (unbox it), run it (plug it in), stop it (unplug it), and remove it (throw it away). A stopped appliance still exists on your shelf, holding its state. A removed one is gone for good. Its internal data is lost unless you saved it to external storage (a volume).
How it works
The lifecycle is a series of state transitions managed by commands. docker create prepares the container but doesn't start it. docker run is a shortcut that both creates and starts. docker start moves a stopped container to a running state. docker stop sends a graceful shutdown signal (SIGTERM), then waits before forcing a stop (SIGKILL). docker kill sends SIGKILL immediately. docker pause freezes all processes inside. Finally, docker rm deletes a stopped container and its non-volume data.
When to use it
You manage the lifecycle constantly. Use docker run for new containers. Use docker stop and docker start to temporarily halt and resume services without losing their state, for example during maintenance. Use docker rm for cleanup to avoid accumulating stopped containers that consume disk space. Orchestrators like Kubernetes manage this lifecycle automatically to maintain a desired state.
When not to use it
Don't rely on a container's internal, non-volume storage for any data you want to keep. The lifecycle is designed to be ephemeral. Once a container is removed (rm), any data written to its filesystem that isn't on a mounted volume is gone forever. This is a core feature, not a bug.
One canonical example
A web server in a container needs a configuration update. The lifecycle allows for a controlled process: first, docker stop my_web_server to gracefully stop it. Second, you make your changes. Third, docker start my_web_server brings the same container instance back online. If you had used docker rm, you would have lost any logs or state within that specific container instance and would need to create a new one.
Interview question
What is the primary functional distinction between stopping a container and removing it?
- a.Removing a container initiates a graceful shutdown process, while stopping it immediately terminates all running processes within it.
- b.A stopped container is completely inactive and consumes no disk space, but a removed container's data is only cleared after a system restart.
- c.Stopping a container releases its allocated memory and CPU, while removing it ensures its image is no longer cached.
- d.Stopping a container allows it to be restarted later with its preserved internal state, whereas removing it permanently deletes the container instance and any data not on a volume.Correct
Why? this is the answer
The card explicitly states that stopping a container retains its state, allowing it to be restarted, while removing it permanently deletes the container and its non-volume data. Option A is incorrect because 'stop' sends a graceful shutdown signal (SIGTERM), not an immediate termination, and 'rm' deletes an already stopped container, it doesn't initiate the shutdown process itself.
Just read this? Test yourself on what you have been reading.
Read the original → docs.docker.com
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on docker — each one lists the topics its interview covers.
See open roles