Implement a 'clean' command

[creack]

It would be nice to have a command that cleans up docker:

• Untagged images
• Containers older than 1 week (or maybe 24h?)

This could be done via a new top level command 'docker clean' or via options to 'docker rm' and 'docker rmi'.

I think it would be better to have this server side than client side.

[shykes]

It will be difficult to find a common definition of "clean". What if I have
a production database running for months or years? Should it be cleaned? :)

On Tue, Jun 18, 2013 at 5:04 PM, Guillaume J. Charmes <
notifications@github.com> wrote:

It would be nice to have a command that cleans up docker:

• Untagged images
• Containers older than 1 week (or maybe 24h?)

This could be done via a new top level command 'docker clean' or via
options to 'docker rm' and 'docker rmi'.

I think it would be better to have this server side than client side.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/928
.

[samalba]

Agreed, that's why it would make sense to take 2 dimensions for the clean command. The amount of time since the last start + the creation date.

For instance, clean all containers that were created more than 30 days ago and which has not been started for 1 week.

[jpetazzo]

Note: the run duration is a good hint, too! (Chances are, that short-lived
containers can be thrown away.)

[shykes]

My favorite approach would be to improve 'docker images' and 'docker ps'
with advanced filtering, and then make it easy to pipe that into 'docker
rm' and 'docker rmi'. More unix-y :)

On Tue, Jun 18, 2013 at 6:20 PM, Jérôme Petazzoni
notifications@github.comwrote:

Note: the run duration is a good hint, too! (Chances are, that short-lived
containers can be thrown away.)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/928#issuecomment-19655690
.

[anthonybishopric]

This does seem like the kind of feature that everyone will want their own flavor of. Maybe the follow on feature is to make an equivalent of git aliases, so if someone wants to have a docker clean they can do it in their own way, and start now by doing the unix-y filter and pipe stuff.

[Krijger]

My proposal would be the following.

A) allow for container tagging. Allow a (maybe unique) description (such as 'User info database') as well, which would make a container listing way more readable and informative.
B) then implement an option such as docker rm -a, which would remove all untagged containers, and maybe a docker rm -a --hard which would remove all containers.

In my opinion, this would give a lot of value on top of the possibilities that the standard unix commands already offer.

[keeb-zz]

+1 to docker clean. That would be so great, docker ps -a doesn't return in a reasonable (10+ minute) amount of time right now.

It's only going to get worse.

[shykes]

Hey Nick, with the latest update (0.4.6), 'docker ps -a' should be fast
again. What slowed it down was computing the size of each container on the
fly, and we moved that to an optional flag (-s).

On Sun, Jun 23, 2013 at 9:38 PM, Nick Stinemates
notifications@github.comwrote:

+1 to docker clean. That would be so great, docker ps -a doesn't return
in a reasonable (10+ minute) amount of time right now.

It's only going to get worse.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/928#issuecomment-19888761
.

[keeb-zz]

Confirmed. Upgrading helped a lot!

keeb@li253-7:~$ docker ps -a | wc -l
502

[warpfork]

I'm of a split mind about the concept of a clean command. The comments saying it would be excellent are true, as are the ones suggesting that clean is something everyone will want their own flavor of.

It seems like this has a lot of similarity to building a garbage collector... but there's no clear definition of what constitutes a strong reference, since it's possible for docker commands to want to refer to a container that ended an arbitrarily large distance ago in time or in subsequent container runs.

[shykes]

Like I said before: what I want to see is improved ways of querying
images and containers. That can be used for removal by piping into 'docker
rm', but also for other things.

On Wed, Jun 26, 2013 at 3:55 PM, Eric Myhre notifications@github.comwrote:

I'm of a split mind about the concept of a clean command. The comments
saying it would be excellent are true, as are the ones suggesting that
clean is something everyone will want their own flavor of.

It seems like this has a lot of similarity to building a garbage
collector... but there's no clear definition of what constitutes a strong
reference, since it's possible for docker commands to want to refer to a
container that ended an arbitrarily large distance ago in time or in
subsequent container runs.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/928#issuecomment-20086211
.

[mhennings]

Please have a look at #1077

I think that it provides a good way to handle temporary stuff without interferring with anything else.

[SeyZ]

What about: docker ps -a | cut -c-12 | xargs docker rm

[creack]

@SeyZ This indeed works but it would remove only containers and all of them.
btw, you can also use docker rm docker ps -a -q``

[robblovell]

I vote to implement a 'clean' command that works for both images and containers. Docker uses a lot of disk space and leaves a lot of stuff laying around. In an environment with limited disk space without resorting to cryptic bash scripts to clean out massive amounts of left over stuff from docker run and docker build.

I have had to resort to the following bash scripts to clean up containers:

docker ps -a | cut -c-12 | xargs docker rm

And this to clean up images:

images=`sudo find /var/lib/docker/graph/ -maxdepth 1 -type d -printf "%f "`
docker rmi $images

My use case:

Build a docker file.
Push it to a private repository
Pull the docker to a production box
Run it
Hook it up into nginx
Kill the old docker.

This series of steps on both a push box and application server eats up 1/2 to 2 g each time it is done both on the build box and the application server. On a 20GB machine, there is no room.

It just seems to be something that should be part of the cannon of commands.. It should be easy, obvious and well documented.

docker clean images
docker clean containers

or

docker rm -a [--hard]
docker rmi -a [--hard]

Perhaps there is something critical I am missing about managing the containers and images that I can do to make this more manageable?

[crosbymichael]

@robblovell

you can do this right now:

delete all contianers

docker rm `docker ps -a -q`

**delete all images**
docker rmi `docker images -q`

[robblovell]

I think the point is that docker seems to leave a lot of stuff lying around, both images and containers. I didn't know where all the space was going on my hard drive until I found some magic documented and undocumented things. I think it is important to really rethink the image build caching and whole graph thing. When I build a container, I should be able to disconnect it from all other associations so that it is independent from all those associations. I should be able to delete the cache baggage without worry that the image I just created is messed up. I should also be able to kill a container and have it completely disappear from the disk.

An aside related to this issue:
Tagging something to move it to another registry is not acceptable as a solution, it is both non-intuitive and creates an unnecessary coupling between registries. My private repo, the public one, and the local one should not have associations to each other. I should be able to do "docker push [image name] [registry_url]" and have my independent image pushed there with no baggage, no connections from where I am pushing from.

I am just trying to relate my experience as a new user. What was non-intuitive was the difference between a registry and a repository and the fact that when I build something or run something there is a lot of baggage laying around if you are constantly building and deleting images, and running and killing containers.

For instance: here is a session where I delete stuff, as you can see, there is about 23 GB of space from left over docker containers killed off:

From a full disk....

#docker ps -a | cut -c-12 | xargs docker rm
Error: No such container: ID

Error: Impossible to remove a running container, please stop it first

d46a31743a91
c6ba4a162585
...
1036 lines removed here...
...
75b387dabb63
2627552d6c84

df -h

Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 63G 40G 20G 67% /

[shykes]

We are convering to a solution to this problem with 2 improvements which are partially implemented in 0.6.6 and will continue in the 0.7 branch:

• The "graph" of images and containers are being unified, so you can trace the lineage of any container or image across all container and images.
• Both containers and images will be named by default, with the possibility of having multiple names.

With this system, names can be used for reference-counting and garbage collection. If a container or image drops to 0 names, it can be safely removed. This will take care of leftover containers or images after a build, temporary containers etc.

This means we will not need a "clean" command. Therefore I am closing this issue :)

[hlascelles]

For those who want to clear down stopped docker containers, leave running ones, and want a zero exit code if there were no errors, use the following. We need it during an automated deploy, and were seeing the "Impossible to remove a running container" errors which come with the more "brute force" remove line given in comments above.

docker ps -a | grep "Exit " | grep -v "CONTAINER ID" | cut -c-12 | xargs -L1 bash -c 'if [ $0 == 'bash' ] ; then : ; else docker rm $0; fi'

[jbenet]

Not sure where this is at today, but thoughts FWTW:

something like docker clean should have modes (or these should be separate (sub)commands) like:

• prune (default): remove only dangling* containers + images
• all-except-tagged: remove all but tagged containers + their images
• all-except-running: remove all containers + images except those running now
• all: remove everything

*dangling means containers not in the current "branches". You can think of a tagged container as a named branch in git. All dependency commits containers should stay cached (for rebuilding purposes). But all the containers that are not themselves tagged or dependencies of those tagged, should be removed. Think of this like "garbage collection", rather than "clean". Perhaps docker gc.

[drewcrawford]

@shykes a clean command is still needed to actually perform the garbage collection once the image runs to 0 reference count.

[dscho]

@shykes I would also like to ask you to reconsider closing this ticket without a resolution such as suggested by @jbenet in #928 (comment). I run into serious disk space trouble after building and rebuilding images dozens of times.

[stucki]

@shykes I agree with @dscho @drewcrawford - A docker clean functionality is still missing. Having names for containers doesn't really help if you still need to remove each of them manually (or using handcrafted shell pipes). Please reopen the issue.

[jbenet]

This is particularly frustrating when automated deploys fail.

[mhennings]

my first contribution to this thread was a pul request for a session timout for docker containers (to clean up automatically)

now that --rm is implemented i feel the need for a cleanup as less pressing. even though i have bash scripts for cleanup on every server which is kind of awkward.

As this thread is not doing any progress... i think we should either suggest a new feature that fits in the big picture or let it go.

[cpuguy83]

There will always be new features to add, old bugs to fix, etc. (Note, there are over 900 issues, and over 100 PR's, and we merge or close over 100 PRs per week).

Notably, docker clean is not the correct approach and is why this is closed. What are you going to clean?
Dangling images? docker rmi $(docker images --filter dangling=true)
Stopped containers? docker rm $(docker ps -aq)

docker clean adds nothing to this other than an extra command only useful for a very small subset of users... and then only syntactic sugar.

[mhennings]

@cpuguy83
with that argumenttion you take it a bit easy. There is obviously a need to do proper garbage collection. something docker still lacks.

while i totally agree on not implementing a simple syntactic sugar, there is indeed something missing.

I think whenever a closed issue gets much attention we should look at the cause, and if docker actually may be missing something needed.

so please, lets look for constructive ideas to fill the gap with a feature that makes sense for every participant.

[meirwah]

For remote option of clearing unused Docker images , I'm part of a project trying to solve this (CloudSlang) using SSH/REST to clearing images from host, and still provide flexibility on the logic.
Here isa blog on how to clear a CoreOS cluster using it : https://www.digitalocean.com/community/tutorials/how-to-clean-up-your-docker-environment-using-cloudslang-on-a-coreos-cluster-2

We can elaborate it to give more "cleaning" capabilities...

[r4j4h]

I think at the very least those handy commands for dangling images and stopped containers and the like should be placed into a visible area of the docs before this issue is closed. Perhaps related sections or a FAQ area, or even a "Maintaining Docker Long Term" section that can guide users in the various directions. That way we expose the variety of kinds of cleaning that can be done, with starting points to doing them.

[dreamcat4]

Dangling images? docker rmi $(docker images --filter dangling=true)
Stopped containers? docker rm $(docker ps -aq)

docker clean adds nothing to this other than an extra command only useful for a very small subset of users... and then only syntactic sugar.

It's useful because the user does not clean out their images very often. Usually every 1-3 months. By that time everyone's forgotten the cmd to use. Wheras docker clean can be checked for man and --help easily. If more advanced usage is required other than the docker rmi $(docker images --filter dangling=true). Heck every single time I've forgotten and had to look it up. Useless.

[vielmetti]

Ran into this problem (again) and had to spelunk through Docker issues (again) to fix it. +1 for syntactic sugar.

[stevenschlansker]

@cpuguy83 Also, the "syntactic sugar" you propose is not actually correct. For example, your command docker rmi $(docker images --filter dangling=true) is subject to race conditions -- it can race with a docker run of a formerly dangling image and cause errors.

This is not a hypothetical race condition. It affects nearly 50% of our cleanup runs (each takes tens of minutes to run, and we schedule a lot of tasks!)

This makes it nearly impossible to write a correct implementation that can differentiate between failure modes, and the operator needs to sort it all out manually. Which sucks when you are maintaining a cluster of 100 machines which continually fill their disks.

[strootman]

+1 to @stevenschlansker
We have a situation which is alarmingly similar to the one described by @stevenschlansker. We try to alleviate the issue by using --rm, but there are times when the containers do not exit gracefully and are left hanging around.

[cpuguy83]

Perhaps there could be something like DELETE /images?filter=<filter spec> and we can lock the graph during that process.

But also I'm thinking there shouldn't be any race issue when calling rmi here unless the rmi is in process but the image is still available for run. Will have to look.

[cpuguy83]

Definitely agree, image removal is quite racey.
This is going to take a lot of work to clean up... I have opened an issue to track: #16982

[stevenschlansker]

Thanks for looking. It's good to have validation that we have not (yet) completely lost our minds ;)

[thaJeztah]

@stevenschlansker thanks for that! We need to prevent adding features that are not strictly needed (or can be reasonably worked around in another way), but in this case you're right that the "workaround" was not a solution 👍

[stevenschlansker]

Here is another example of why this situation really sucks. Look at one of the best scripts I've found so far to "clean up" Docker:

https://github.com/chadoe/docker-cleanup-volumes/blob/master/docker-cleanup-volumes.sh

Not only is it hugely complicated, there have been multiple bugs which cause it to delete in-use volumes out from running containers: chadoe/docker-cleanup-volumes#19

And this is state of the art. I made the mistake of upgrading to Docker 1.8.3 yesterday and tripped this bug. Now this morning I've got about thirty angry users coming at me asking where their data is... but it's all gone :(

[dreamcat4]

Yeah. I also made the mistake of using a 3rd party tool to do a so-called 'clean' of my unused volumes. It just deleted all my docker volumes... Really didn't like that.

[killianbrackey]

A friend and I put together a script that may help some of you. The script runs a few filtered commands using docker-clean [option flags]. We put it together to help streamline the running of a lot of the same commands across multiple machines and has become a huge part of our docker workflow.

Check it out and let us know what you think and open any issues with features you would like to see or fork and pull!

https://github.com/ZZROTDesign/docker-clean

[violentr]

alias docker-clean = 'docker rm $(docker ps -a -q) &amp;&amp; docker rmi $(docker images -q) && docker ps -a | cut -c-12 | xargs docker rm'
Removes docker containers then docker images and lastly clears cache

[mastef]

It's been now over 2 years since this thread started with many additional suggestions that wouldn't require script batching, like docker rm --stopped and docker rmi --untagged, etc. Since I'm still getting notifications on this one, let's celebrate with a remixed classic.

[DeeDeeG]

This is handled by prune sub-commands now.

• docker builder prune (for deleting old build cache)
• docker container prune
• docker image prune
• docker network prune
• docker volume prune

To do them all at once:

• docker system prune (doesn't delete any volumes by default)
  • run docker system prune --volumes to delete volumes too.

Docs:

• https://docs.docker.com/config/pruning/
• https://docs.docker.com/search/?q=prune

(Commenting for anyone still reading this thread, e.g. linked here from StackOverflow.)