Docker镜像与容器激增：如何通过最佳实践预防？

Great question—this is a super common pain point when getting comfortable with Docker Compose, and there are clear best practices to fix this without overcomplicating your workflow. Let’s break this down step by step:

Why you’re seeing all those dangling images and leftover containers #

First, let’s clarify the root causes:

• docker-compose run by default preserves containers even after you exit the shell. That’s why docker container ls -a shows so many stale entries—each run creates a new container that sticks around unless you delete it manually.
• Dangling <none> images happen when you rebuild a service (e.g., with docker-compose build) or pull an updated image: Docker keeps the old image around but removes its tag, leaving it as "dangling" because no container or named image references it anymore.

Best Practices to Fix This #

1. Always use --rm with docker-compose run (YES, this is a best practice) #

This is the easiest win. Adding --rm tells Docker to automatically delete the container as soon as you exit the shell or the command finishes. For your use case, run:

docker-compose run --rm service1 /bin/bash

You’ll never have leftover containers from run commands again. This is absolutely a standard best practice—no reason not to use it every time you run ad-hoc commands in a service container.

2. Clean up properly after docker-compose up #

When you start services with docker-compose up, don’t just hit Ctrl+C or run docker stop on individual containers. Instead, use:

docker-compose down

This stops all services and deletes their containers, networks, and default volumes (add -v to include volumes, but be cautious if you need to persist data). If you want to also remove locally built images (useful if you’re rebuilding often), add --rmi local:

docker-compose down --rmi local

Avoid --rmi all unless you want to delete every image associated with the Compose file (including pulled base images like postgres or nginx).

3. Regularly prune dangling images and unused resources #

Even with the above steps, you’ll still get dangling images over time. Run these commands to clean up safely:

• Delete all dangling images (the <none> ones):

  docker image prune
  

• Delete all stopped containers:

  docker container prune
  

• A one-stop shop to clean up all unused resources (images, containers, networks, volumes—note: volumes are only deleted if unused):

  docker system prune -a
  

The -a flag deletes all unused images (not just dangling ones), which is great for freeing up maximum space. Docker will prompt you before deleting anything, so you can confirm what’s being removed.

4. Tweak your docker-compose.yml to reduce clutter #

You don’t need a full rewrite, but small changes can help:

• Add explicit image tags for built services: Instead of letting Docker generate a random tag, define an image field for services you build. For example:

  services:
    service1:
      build: ./service1
      image: myapp/service1:latest
  

This way, when you rebuild, Docker overwrites the latest tag instead of creating a new untagged image. The old image will still become dangling, but you’ll have fewer <none> entries to sift through.

• Use tmpfs for ephemeral data: If your service writes temporary files that don’t need to persist, mount a tmpfs volume to avoid filling up disk space:

  services:
    service1:
      tmpfs: /tmp
  

Final Takeaway #

Most of the issue comes from small habits rather than a flawed docker-compose.yml. The --rm flag for run is non-negotiable best practice, and using docker-compose down instead of manual stops will keep your container list clean. Regular pruning will handle the dangling images, and minor YAML tweaks can reduce clutter further.

内容的提问来源于stack exchange，提问作者Ramon Marques