Stopping & Cleaning Up
Stopped containers, dangling images and orphan volumes silently eat disk.
Introduction
Stopped containers, dangling images and orphan volumes silently eat disk. Cleaning up regularly keeps your dev box healthy and your CI cache fast.
Purpose of this lesson
This lesson teaches Stopping & Cleaning Up as an engineering decision: what problem it solves, when to use it, how to implement it safely, and what signals tell you it is failing.
Understanding the topic
Use this whenever you create or review an application image. Build quality affects deploy speed, security exposure, reproducibility, CI cost, and how quickly engineers can diagnose failures.
Core concepts to understand:
docker stop $(docker ps -q)stops everything running.docker rm $(docker ps -aq)removes all stopped containers.docker image pruneremoves dangling images; add-afor unused.docker system dfshows where disk is going.
Visual explanation
Architecture or command flow to keep in mind:
# Safe daily cleanupdocker container prune -fdocker image prune -f# Big cleanup (careful!)docker system prune -af --volumes
Step-by-step explanation
- Start from a trusted, pinned base image and document why it fits the runtime.
- Order Dockerfile instructions from least-changing dependency metadata to most-changing source files so the cache stays useful.
- Build locally with BuildKit, inspect layers with
docker history, and run the image with the same command CI will use. - Test shutdown behavior, health checks, non-root execution, and runtime configuration before pushing the image.
- Tag with an immutable version or git SHA, scan the image, and promote the same artifact through environments.
Informative example
Use the example below as a working baseline, then verify the runtime behavior instead of assuming the command or file is correct.
# Safe daily cleanupdocker container prune -fdocker image prune -f# Big cleanup (careful!)docker system prune -af --volumes
A production-minded check usually includes docker ps, docker logs, docker inspect, and one validation from outside the container such as curl, a database connection, or a registry pull.
# Verification loop for Stopping & Cleaning Updocker ps -adocker logs --tail=100 <container-name>docker inspect <container-or-image-name>docker system df
Real-world use
CI runners run docker system prune nightly to keep build caches healthy without manual intervention.
Enterprise use cases
In a mature engineering organization, Stopping & Cleaning Up is documented as a repeatable pattern with approved base images, ownership labels, CI checks, security expectations, rollback notes, and troubleshooting commands. The difference between a tutorial and production practice is that every container decision must be observable, reviewable, and reversible.
Best practices
- Use
--rmon short-liveddocker runcommands. - Audit with
docker system dfbefore mass-pruning.
Common mistakes
--volumesdeletes named volumes too — data loss.
Debugging tips
- Use
docker build --progress=plainwhen BuildKit output hides the failing build step. - Run the image with a temporary shell or overridden command to inspect files, users, environment, and entrypoint behavior.
- Check
docker historyfor accidental secrets, unexpectedly large layers, and cache-busting instructions.
Optimization strategies
- Copy dependency lock files before source files so dependency installation remains cached during code edits.
- Use multi-stage builds to keep compilers, package managers, test tools, and source maps out of runtime images.
- Adopt BuildKit cache mounts for npm, Maven, pip, Go, or cargo dependencies in CI.
Advanced interview questions
Interview Prep
Practice concise answers, then expand each card for the explanation.
1QuestionWhat is a dangling image?+
Answer
2QuestionHow do you reclaim disk used by Docker?+
Answer
3QuestionWhat does the <code>--rm</code> flag do?+
Answer
Hands-on exercise
Create a small lab for Stopping & Cleaning Up: run the example, inspect the created Docker object, intentionally introduce one mistake, and record the command that reveals the failure. The goal is not just to make the happy path work; it is to build operational reflexes.
# Hands-on lab scaffoldmkdir -p docker-stopping-cleaning-up-labcd docker-stopping-cleaning-up-lab# Add the Dockerfile, compose.yml, or command from this lesson.# Then run one happy-path test and one broken-path test.docker versiondocker infodocker system df
Summary
Stopping & Cleaning Up matters because Docker is not only a packaging tool; it is a runtime, build, networking, storage, and delivery workflow. Treat each lesson as a production habit: make it repeatable, inspectable, secure, and easy to debug.