When Containers Become Trashcans

Containers are so awesome.

Prior to containers, if you wanted to experiment with some new technology, you had to go through the ringer to configure and install all of the appropriate dependencies, set up the proper infrastructure, and clutter your machine with tons of trash that you might not ever care to use in the future. Thankfully, Docker and other containerized technologies came along and empowered developers to just throw a one-liner into the command line and like magic, the entire world appeared in a magical little box.

Several days ago, I had an idea in my head so I scrounged around through Docker Hub looking for the perfect container that had everything that I wanted in it. I'd pull down one, tinker a bit, and throw it away. Pull another down, try something else, and then eventually throw it away. Pull yet another one down and ... crap!

docker: write /var/lib/docker/tmp/GetImageBlob785934359: no space left on device.

No space left on my device? That's odd, maybe it's the hours upon hours of videos that I've downloaded for my kids to watch on road trips, or all those computer games that I've installed but never can find the time to play (some day)? Let me check out the hard-drive and see how that looks:

Okay, so either this image that I'm pulling down is really big, or something else is going on. After a bit of mulling it over, I realized that like all good humans that don't want the machines taking over, delegated a specific amount of space and resources that Docker could take advantage and sure enough, I was right at the threshold.

It was time to take out the trash, however since docker dump trash isn't a legitimate command (at least out of the box), I just had to do a quick prune:

docker system prune

The prune command in a nutshell does the following:

• Removes all non-running / stopped containers
• Removes all volumes that aren't being used (by at least one active container)
• Removes all networks that aren't being used (by at least one active container)
• Removes all dangling images within the system.

Since I mentioned above that I really enjoy playing with containers, I figured that we'd just do it live, so here's what that looked like on my local machine:

With three little words, I managed to free up nearly 126GB of unused space across 22 containers, 5 networks, and 45 images). That's quite impressive, but more importantly, I was then able to immediately install the image that I was trying to in the first place.

So the moral of the story is this - containers are really awesome, powerful, and useful to the modern developer, but if you aren't mindful, those unused ones can quickly turn from containers to trashcans that can make your development environment a stinky place to work in.

Comments

[Andrew May]

Ah I know that feeling very well - particularly from utility containers that run a task and then finish, but the container hangs around!

I've got in the habit of using the --rm flag on docker run almost all the time so that the container is removed when stopped - I still need to prune occasionally, but not as often.

[Rion Williams]

Hi Andrew!

I'm in the same boat as well, it makes things so much easier when you clean up after you make the mess instead of waiting until things get really hairy.

This was just an older machine from back when I first discovered docker and obviously, didn't know or care how to clean up after myself!

[eLabFTW]

I wanted to write a similar article that also talks about other things developer face:

• yarn/npm cache
• cargo cache
• composer cache
• pip cache

At the end of the day, all these things can take as much as 100 Gb!

Might write an article summarizing the commands to clean a dev computer!

[Jacob Baker]

Literally did this earlier this afternoon because it dawned on me where all my space had gone!