4 ms·
Hey, I'm a Docker maintainer. We don't plan on "keeping it that way". Disk clutter after lots of builds is a problem which we're very much addressing. It's spe
by shykes 12y ago
Hey, I'm a Docker maintainer.
We don't plan on "keeping it that way". Disk clutter after lots of builds is a problem which we're very much addressing. It's specifically a top-level docker clean command that I'm not a fan of, because it doesn't capture a clear intent - what are you cleaning, and who determines what should be kept and what shouldn't? In general I like to avoid Docker having to guess what you want - the proverbial "magic".
A few notes:
* The reason Docker can clutter your disk is because we made an explicit tradeoff: it's better to keep too much data than to remove too much. That is why we're able to say "yes, you can run a database on Docker. Neither the container nor its data will be removed, at any point, unless you explicitly request it". Everytime I hear someone complain "there's too much stuff on my disk", I rejoice that I am not instead hearing "Docker ate my data".
* We have already introduced a few improvements. For example Docker used to keep the intermediary container for each build step (for later inspection of the build output, transient state etc). Now, by default, we don't.
* The most elegant fix, I believe, is to use naming and tagging as an indication of interest. If you are interested in keeping an image, give it a name (for example with 'docker build -t'). When an image no longer has a name referencing it, instead of keeping it around as an anonymous image like it does today, Docker can remove garbage collect it. That should take care of the problem elegantly and without requiring a new, clunky top-level command.
TLDR: the "disk clutter" problem is the result of a conscious tradeoff which we are glad we made. We have started fixing it, and there are more fixes to come.
- j_s 12y ago> We don't plan on "keeping it that way". Cool! Can you point me to where the discussion on this is occurring? I was confused because the issue I referenced above was closed without a reference to any issue open on how this problem will be addressed.
- shykes 12y agoMost of the discussion has been on irc: #docker and #docker-dev on Freenode. There are several contributions underway under the general "theme" I described, but if it helps I could write a summary of how the experience will change for the user (normally there should be almost no UI change).
- CSDude 12y agoWhen you make a dangerous `apt-get remove xxxx` (that will cause critical packages to be removed), it warns you and wants you to write "Yes, do as I say!" https://fbcdn-sphotos-a-a.akamaihd.net/hphotos-ak-ash3/t1.0-9/541409_10151096050381018_2018380438_n.jpg https://fbcdn-sphotos-a-a.akamaihd.net/hphotos-ak-ash3/t1.0-...
- olouv 12y agoIt's a real PITA that the first thing you do when you start experimenting with docker is to have to find out about this missing clean command and to design a custom alias to fit your needs. In my case, I was expecting it (eg. `bower cache clean`, `npm cache clean`). Regarding the unclear intent, that's what cli help is for! `docker clean` could output it by default.
- shykes 12y agoWhat would you expect it to do exactly? Remove all untagged images?
- blueyed 12y agoThat's a good starting point. I have a docker-cleanup script, which removes untagged images and containers: https://github.com/blueyed/dotfiles/blob/master/usr/bin/docker-cleanup https://github.com/blueyed/dotfiles/blob/master/usr/bin/dock...
- threeseed 12y agoAre you serious ? If you want to capture a clear intent then simply ask the user to provide parameters. docker clean remove-untagged docker clean remove-old 4w It's bizarre that the Docker team is so oblivious to the issues running Docker in a real world environment.