Posted on by Danny Gershman
Using containers can be very advantageous and we’ve discovered many different possibilities with them. However, without a good cleanup strategy, you will find yourself quickly running out of disk space. This is where a Docker janitor can come in handy.
There are a couple of ones floating around GitHub/Docker Hub, but none really do cleanup in a nice compact way of dealing with systems that build images. You might have a build server that is building layers upon layers of images. Over time, you will undoubtedly have failures. Each one of these failures will have a dangling image that never got tagged, as well as volumes that are orphaned. These can eventually cause build failures or even collisions if not cleaned up properly.
During build server integration testing, you might be testing an application with several external dependencies like a data store or a message queue. We like to have repeatable processes that can be run both locally and on the build server. One benefit of this is that engineers starting their first day can pull down code from GitHub and start working right away with having to install other applications on their personal systems. This self-documenting way of keeping tracking of external dependencies allows for portability when testing on the build server. These will start to accumulate over time and likely become a blocker on your build system. The janitor will keep things tidy and allow your build system to run smoothly.
We wrote our own script that handles these cases, and our Site Reliability Engineering Team has been using this as a plain old shell script in Jenkins when running short lived containers for either building or testing. We decided to make it nice and portable by packaging it in a Docker image for easy reuse.
Feel free to fork and contribute a pull request on the repository docker-janitor, or go ahead and pull it down directly from Docker Hub
docker pull securityscorecard/docker-janitor.