All of the things we have just done seem pretty painful to do and are hard to remember so Docker recently added docker image prune to help out in this aspect. By using docker image prune, all dangling images will be removed with a single command:
$ docker image prune
WARNING! This will remove all dangling images.
Are you sure you want to continue? [y/N] y
Deleted Images:
untagged: ubuntu@sha256:2b9285d3e340ae9d4297f83fed6a9563493945935fc787e98cc32a69f5687641
deleted: sha256:8b72bba4485f1004e8378bc6bc42775f8d4fb851c750c6c0329d3770b3a09086
<snip>
deleted: sha256:f4744c6e9f1f2c5e4cfa52bab35e67231a76ede42889ab12f7b04a908f058551
Total reclaimed space: 188MB
Something to note here, as you might have noticed, deleting all references to an image layer also cascades onto child layers.
Last but not least is volume clean-up, which can be managed with the docker volume command. I would recommend that you exercise extreme caution when doing this in order to avoid deleting data that you might need and only use manual volume selection or prune:
$ docker volume ls
DRIVER VOLUME NAME
local database_volume
local local_storage
local swarm_test_database_volume
$ docker volume prune
WARNING! This will remove all volumes not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Volumes:
local_storage
swarm_test_database_volume
database_volume
Total reclaimed space: 630.5MB
As a reference, I have been running Docker rather lightly the week I wrote this chapter and the removal of stale containers, images, and volumes has reduced my filesystem usage by about 3 GB. While that number is mostly anecdotal and may not seem much, on cloud nodes with small instance hard disks and on clusters with continuous integration added, leaving these things around will get you out of disk space faster than you might realize, so expect to spend some time either doing this manually or automating this process for your nodes in something such as systemd timers or crontab.