Implement a 'clean' command #928

Closed
creack opened this Issue Jun 19, 2013 · 102 comments

Comments

Projects
None yet
@creack
Contributor

creack commented Jun 19, 2013

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

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Jun 19, 2013

Collaborator

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/dotcloud/docker/issues/928
.

Collaborator

shykes commented Jun 19, 2013

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/dotcloud/docker/issues/928
.

@samalba

This comment has been minimized.

Show comment
Hide comment
@samalba

samalba Jun 19, 2013

Contributor

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.

Contributor

samalba commented Jun 19, 2013

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

This comment has been minimized.

Show comment
Hide comment
@jpetazzo

jpetazzo Jun 19, 2013

Contributor

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

Contributor

jpetazzo commented Jun 19, 2013

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

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Jun 19, 2013

Collaborator

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/dotcloud/docker/issues/928#issuecomment-19655690
.

Collaborator

shykes commented Jun 19, 2013

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/dotcloud/docker/issues/928#issuecomment-19655690
.

@anthonybishopric

This comment has been minimized.

Show comment
Hide comment
@anthonybishopric

anthonybishopric Jun 19, 2013

Contributor

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.

Contributor

anthonybishopric commented Jun 19, 2013

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

This comment has been minimized.

Show comment
Hide comment
@Krijger

Krijger Jun 22, 2013

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.

Krijger commented Jun 22, 2013

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

This comment has been minimized.

Show comment
Hide comment
@keeb

keeb Jun 24, 2013

Contributor

+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.

Contributor

keeb commented Jun 24, 2013

+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

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Jun 24, 2013

Collaborator

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/dotcloud/docker/issues/928#issuecomment-19888761
.

Collaborator

shykes commented Jun 24, 2013

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/dotcloud/docker/issues/928#issuecomment-19888761
.

@keeb

This comment has been minimized.

Show comment
Hide comment
@keeb

keeb Jun 24, 2013

Contributor

Confirmed. Upgrading helped a lot!

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

keeb commented Jun 24, 2013

Confirmed. Upgrading helped a lot!

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

This comment has been minimized.

Show comment
Hide comment
@warpfork

warpfork Jun 26, 2013

Contributor

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.

Contributor

warpfork commented Jun 26, 2013

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

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Jun 26, 2013

Collaborator

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/dotcloud/docker/issues/928#issuecomment-20086211
.

Collaborator

shykes commented Jun 26, 2013

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/dotcloud/docker/issues/928#issuecomment-20086211
.

@mhennings

This comment has been minimized.

Show comment
Hide comment
@mhennings

mhennings Jun 30, 2013

Contributor

Please have a look at #1077

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

Contributor

mhennings commented Jun 30, 2013

Please have a look at #1077

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

@SeyZ

This comment has been minimized.

Show comment
Hide comment
@SeyZ

SeyZ Aug 8, 2013

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

SeyZ commented Aug 8, 2013

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

@creack

This comment has been minimized.

Show comment
Hide comment
@creack

creack Aug 8, 2013

Contributor

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

Contributor

creack commented Aug 8, 2013

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

@robblovell

This comment has been minimized.

Show comment
Hide comment
@robblovell

robblovell Aug 30, 2013

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?

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

This comment has been minimized.

Show comment
Hide comment
@crosbymichael

crosbymichael Aug 30, 2013

Contributor

@robblovell

you can do this right now:

delete all contianers

docker rm `docker ps -a -q`

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

crosbymichael commented Aug 30, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@robblovell

robblovell Sep 5, 2013

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% /

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

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Nov 11, 2013

Collaborator

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 :)

Collaborator

shykes commented Nov 11, 2013

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

This comment has been minimized.

Show comment
Hide comment
@hlascelles

hlascelles Jan 21, 2014

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'

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

This comment has been minimized.

Show comment
Hide comment
@jbenet

jbenet Jan 24, 2014

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.

jbenet commented Jan 24, 2014

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

This comment has been minimized.

Show comment
Hide comment
@drewcrawford

drewcrawford Jan 31, 2014

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

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

@dscho

This comment has been minimized.

Show comment
Hide comment
@dscho

dscho Feb 4, 2014

@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.

dscho commented Feb 4, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@stucki

stucki Feb 5, 2014

@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.

stucki commented Feb 5, 2014

@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 comment has been minimized.

Show comment
Hide comment
@jbenet

jbenet Feb 5, 2014

This is particularly frustrating when automated deploys fail.

jbenet commented Feb 5, 2014

This is particularly frustrating when automated deploys fail.

@icco

This comment has been minimized.

Show comment
Hide comment
@icco

icco Mar 2, 2014

I ran docker images | grep '<none>' | grep -P '[1234567890abcdef]{12}' -o | xargs -L1 docker rmi and 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' and got about 4Gb back. Deletes stopped containers and images with no tag.

icco commented Mar 2, 2014

I ran docker images | grep '<none>' | grep -P '[1234567890abcdef]{12}' -o | xargs -L1 docker rmi and 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' and got about 4Gb back. Deletes stopped containers and images with no tag.

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Mar 3, 2014

Member

As a simpler example:

# delete all stopped containers (because running containers will harmlessly error out)
docker rm $(docker ps -a -q)
# delete all untagged images
docker rmi $(docker images | awk '/^<none>/ { print $3 }')
Member

tianon commented Mar 3, 2014

As a simpler example:

# delete all stopped containers (because running containers will harmlessly error out)
docker rm $(docker ps -a -q)
# delete all untagged images
docker rmi $(docker images | awk '/^<none>/ { print $3 }')
@mastef

This comment has been minimized.

Show comment
Hide comment
@mastef

mastef Mar 3, 2014

i regularly have to look up this command, so wrote a small tutorial on useful clean up commands - http://blog.stefanxo.com/2014/02/clean-up-after-docker/

would be great if this could be a native feature in the cli

mastef commented Mar 3, 2014

i regularly have to look up this command, so wrote a small tutorial on useful clean up commands - http://blog.stefanxo.com/2014/02/clean-up-after-docker/

would be great if this could be a native feature in the cli

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Mar 3, 2014

Member

@mastef I agree; If the main 'docker' command should not be polluted with functionality like this, maybe in the form of a dockerutils command? e.g. dockerutils cleanupimages etc.

(otoh - a dockerutils script could be developed as a 3rd party thing / contrib)

Member

thaJeztah commented Mar 3, 2014

@mastef I agree; If the main 'docker' command should not be polluted with functionality like this, maybe in the form of a dockerutils command? e.g. dockerutils cleanupimages etc.

(otoh - a dockerutils script could be developed as a 3rd party thing / contrib)

@mastef

This comment has been minimized.

Show comment
Hide comment
@mastef

mastef Mar 3, 2014

Could be something, or as parameters for docker rm and docker rmi? - e.g. docker rm --stopped and docker rmi --untagged

mastef commented Mar 3, 2014

Could be something, or as parameters for docker rm and docker rmi? - e.g. docker rm --stopped and docker rmi --untagged

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Mar 3, 2014

Member

@mastef I suppose that could be an option, but there's already so many flags/options/commands in docker that you may end up having to look-up those parameters as well 😄

Not sure if this is the right location for this discussion, e.g. on docker-dev / docker-user, or that a separate issue should be created. Maybe someone of the 'core' developers can shine a light? @tianon ?

Member

thaJeztah commented Mar 3, 2014

@mastef I suppose that could be an option, but there's already so many flags/options/commands in docker that you may end up having to look-up those parameters as well 😄

Not sure if this is the right location for this discussion, e.g. on docker-dev / docker-user, or that a separate issue should be created. Maybe someone of the 'core' developers can shine a light? @tianon ?

drewcrawford added a commit to drewcrawford/scissors that referenced this issue Mar 6, 2014

@muff1nman

This comment has been minimized.

Show comment
Hide comment
@muff1nman

muff1nman Apr 3, 2014

The fact that I have 19 gigs of of unused containers/images is ridiculous. If it isn't tagged, I don't want it. I shouldn't have to clean up docker's mess.

The fact that I have 19 gigs of of unused containers/images is ridiculous. If it isn't tagged, I don't want it. I shouldn't have to clean up docker's mess.

@mastef

This comment has been minimized.

Show comment
Hide comment
@mastef

mastef Apr 3, 2014

@thaJeztah there's many rarely used options in docker; but this one is being used constantly.

mastef commented Apr 3, 2014

@thaJeztah there's many rarely used options in docker; but this one is being used constantly.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Apr 3, 2014

Member

@mastef agreed. Looking back on your idea, it may be good to implement as you proposed; i.e. docker rm --stopped or, maybe better docker rm --clean and docker rmi --clean to keep it consistent.

Extra care should be taken when implementing docker rm --clean as stopped containers may still be used as a data-only / volume container, but I suppose the API could check if they still are used / linked.

Member

thaJeztah commented Apr 3, 2014

@mastef agreed. Looking back on your idea, it may be good to implement as you proposed; i.e. docker rm --stopped or, maybe better docker rm --clean and docker rmi --clean to keep it consistent.

Extra care should be taken when implementing docker rm --clean as stopped containers may still be used as a data-only / volume container, but I suppose the API could check if they still are used / linked.

@mikehaertl

This comment has been minimized.

Show comment
Hide comment
@mikehaertl

mikehaertl May 1, 2015

@hobofan The idea is, to remove containers without a name. This way you can safely prevent your volume containers from being deleted by giving them a name. This of course doesn't work right now, because every container always gets a name, due to that (IMO useless) auto-naming feature.

@hobofan The idea is, to remove containers without a name. This way you can safely prevent your volume containers from being deleted by giving them a name. This of course doesn't work right now, because every container always gets a name, due to that (IMO useless) auto-naming feature.

@hobofan

This comment has been minimized.

Show comment
Hide comment
@hobofan

hobofan May 1, 2015

Contributor

@mikehaertl I understand that, but the notion that all containers with a name should be protected from deletion seems very arbitrary to me and would not solve the general issue, but only that of protecting volume containers. A better method for solving that problem as of 1.6.0 would be labeling the containers you want to protect in some way and then filtering by them (sadly there isn't a filter flag for labels yet).

Contributor

hobofan commented May 1, 2015

@mikehaertl I understand that, but the notion that all containers with a name should be protected from deletion seems very arbitrary to me and would not solve the general issue, but only that of protecting volume containers. A better method for solving that problem as of 1.6.0 would be labeling the containers you want to protect in some way and then filtering by them (sadly there isn't a filter flag for labels yet).

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah May 1, 2015

Member

sadly there isn't a filter flag for labels yet

Actually, there is, but iirc it wasn't in the docs upon release of 1.6 :)

Member

thaJeztah commented May 1, 2015

sadly there isn't a filter flag for labels yet

Actually, there is, but iirc it wasn't in the docs upon release of 1.6 :)

@kojiromike

This comment has been minimized.

Show comment
Hide comment
@kojiromike

kojiromike May 1, 2015

Contributor
  1. Auto-naming isn't useless, it's awesome.
  2. Names should not be overloaded with the responsibility of being an indicator as to whether or not a container is transient.
  3. Labels make sense, although the session approach in the early pull request makes a lot of sense, too.

We're seriously considering using jpetazzo/dind to emulate sessions here. Once we're done with a job we can nuke the dind container and we'd know for sure we got all the containers it contained.

Contributor

kojiromike commented May 1, 2015

  1. Auto-naming isn't useless, it's awesome.
  2. Names should not be overloaded with the responsibility of being an indicator as to whether or not a container is transient.
  3. Labels make sense, although the session approach in the early pull request makes a lot of sense, too.

We're seriously considering using jpetazzo/dind to emulate sessions here. Once we're done with a job we can nuke the dind container and we'd know for sure we got all the containers it contained.

@cusspvz

This comment has been minimized.

Show comment
Hide comment
@cusspvz

cusspvz Jul 22, 2015

+1 for TTL option on tag pull

Sorry for not reading entire issue, a search for TTL showed no results so... here is my proposal.

I propose to add a TTL option on image pull tag.
On a CD environment, registry will become storing a lot of non needed images... :/

cusspvz commented Jul 22, 2015

+1 for TTL option on tag pull

Sorry for not reading entire issue, a search for TTL showed no results so... here is my proposal.

I propose to add a TTL option on image pull tag.
On a CD environment, registry will become storing a lot of non needed images... :/

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jul 22, 2015

Member

For automatic cleaning / garbage collect, there's "Sherdock", which was created during the DockerCon 2015 hackathon; https://github.com/rancher/sherdock http://rancher.com/sherdock/

Member

thaJeztah commented Jul 22, 2015

For automatic cleaning / garbage collect, there's "Sherdock", which was created during the DockerCon 2015 hackathon; https://github.com/rancher/sherdock http://rancher.com/sherdock/

@cusspvz

This comment has been minimized.

Show comment
Hide comment
@cusspvz

cusspvz Jul 22, 2015

Sorry, my proposal wasn't for adding clean on local volumes but yes for registry pulls. Registry would know if image should be alive or not and maybe we could implement that also on local volumes (by transporting TTL from registry to docker server).

cusspvz commented Jul 22, 2015

Sorry, my proposal wasn't for adding clean on local volumes but yes for registry pulls. Registry would know if image should be alive or not and maybe we could implement that also on local volumes (by transporting TTL from registry to docker server).

@getstek

This comment has been minimized.

Show comment
Hide comment
@getstek

getstek Aug 18, 2015

How is this still an outstanding issue? Sherdock is great but only if you have a system capable of booting another container -- I don't see an option in the web interface to manage a remote system.

My entire platform is down because of full disk, worse yet none of the commands above actually work in my case. Except Sherdock (see above).

Is there a better solution than a few shell scripts and one liners?

getstek commented Aug 18, 2015

How is this still an outstanding issue? Sherdock is great but only if you have a system capable of booting another container -- I don't see an option in the web interface to manage a remote system.

My entire platform is down because of full disk, worse yet none of the commands above actually work in my case. Except Sherdock (see above).

Is there a better solution than a few shell scripts and one liners?

@stevenschlansker

This comment has been minimized.

Show comment
Hide comment
@stevenschlansker

stevenschlansker Aug 18, 2015

Indeed, Sherdock looks very interesting -- but if you are managing many tens of host machines, having a web UI is very counterproductive. A proper solution will need to be scriptable and automatable.

We have been running a combination of a few of the scripts above, but unfortunately have found that

  • None seems to be able to clean all possible leaked resources reliably, each does some slightly different subset
  • They all dive into the internal Docker directory, which is brittle -- upgrading to 1.7 caused our cleanup script to silently delete in-use volumes and image layers (!)
  • They all suffer from race conditions -- if you list images, check if they are used, and then try to delete one, someone may then attempt to use that image concurrently and cause errors. It is very hard to tell if these errors are actual failures or just concurrency issues

I still can't see any reason this issue should be closed, clearly this is a pain point affecting many of your users who are furthest down the "running Docker in production" path, and solutions outside of core seem to be very difficult / impossible to correctly implement.

Indeed, Sherdock looks very interesting -- but if you are managing many tens of host machines, having a web UI is very counterproductive. A proper solution will need to be scriptable and automatable.

We have been running a combination of a few of the scripts above, but unfortunately have found that

  • None seems to be able to clean all possible leaked resources reliably, each does some slightly different subset
  • They all dive into the internal Docker directory, which is brittle -- upgrading to 1.7 caused our cleanup script to silently delete in-use volumes and image layers (!)
  • They all suffer from race conditions -- if you list images, check if they are used, and then try to delete one, someone may then attempt to use that image concurrently and cause errors. It is very hard to tell if these errors are actual failures or just concurrency issues

I still can't see any reason this issue should be closed, clearly this is a pain point affecting many of your users who are furthest down the "running Docker in production" path, and solutions outside of core seem to be very difficult / impossible to correctly implement.

@mikehaertl

This comment has been minimized.

Show comment
Hide comment
@mikehaertl

mikehaertl Aug 18, 2015

I love how docker made my life as a developer so much easier. For example with tools like compose it has become so simple to share a somewhat complex development setup even with my designer coworkers in a couple of minutes.

Then again after some time you find out about the not so good parts and you seriously start to wonder: What the ..!? The claim is "batteries included" - but it's somehow just half of the truth. It's like you need 4 batteries but only 3 are included. Docker can really behave like a "litterbug" when you look at what happens to your harddrive after playing around with it for a while.

The manual doesn't really mention this and you need to find out on your own, how to get rid of all the garbage that docker has left (with abandonend volumes being the must painful to remove - you need to find a 3rd party "battery" first).

To me it feels like a lot of energy is now put into extending the stack of docker tools while some very basic but still essential missing features are simply neglected - even if users ask for them again and again.

I love how docker made my life as a developer so much easier. For example with tools like compose it has become so simple to share a somewhat complex development setup even with my designer coworkers in a couple of minutes.

Then again after some time you find out about the not so good parts and you seriously start to wonder: What the ..!? The claim is "batteries included" - but it's somehow just half of the truth. It's like you need 4 batteries but only 3 are included. Docker can really behave like a "litterbug" when you look at what happens to your harddrive after playing around with it for a while.

The manual doesn't really mention this and you need to find out on your own, how to get rid of all the garbage that docker has left (with abandonend volumes being the must painful to remove - you need to find a 3rd party "battery" first).

To me it feels like a lot of energy is now put into extending the stack of docker tools while some very basic but still essential missing features are simply neglected - even if users ask for them again and again.

@mhennings

This comment has been minimized.

Show comment
Hide comment
@mhennings

mhennings Aug 18, 2015

Contributor

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.

Contributor

mhennings commented Aug 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Aug 18, 2015

Contributor

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.

Contributor

cpuguy83 commented Aug 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mhennings

mhennings Aug 18, 2015

Contributor

@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.

Contributor

mhennings commented Aug 18, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@meirwah

meirwah Aug 26, 2015

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...

meirwah commented Aug 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@r4j4h

r4j4h Sep 6, 2015

Contributor

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.

Contributor

r4j4h commented Sep 6, 2015

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

This comment has been minimized.

Show comment
Hide comment
@dreamcat4

dreamcat4 Sep 23, 2015

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.

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

This comment has been minimized.

Show comment
Hide comment
@vielmetti

vielmetti Oct 9, 2015

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

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

@stevenschlansker

This comment has been minimized.

Show comment
Hide comment
@stevenschlansker

stevenschlansker Oct 9, 2015

@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.

@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

This comment has been minimized.

Show comment
Hide comment
@strootman

strootman Oct 9, 2015

+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.

+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

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Oct 9, 2015

Contributor

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.

Contributor

cpuguy83 commented Oct 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Oct 13, 2015

Contributor

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

Contributor

cpuguy83 commented Oct 13, 2015

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

This comment has been minimized.

Show comment
Hide comment
@stevenschlansker

stevenschlansker Oct 13, 2015

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

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

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Oct 13, 2015

Member

@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 👍

Member

thaJeztah commented Oct 13, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@stevenschlansker

stevenschlansker Oct 14, 2015

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 :(

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

This comment has been minimized.

Show comment
Hide comment
@dreamcat4

dreamcat4 Oct 14, 2015

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.

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

This comment has been minimized.

Show comment
Hide comment
@killianbrackey

killianbrackey Apr 25, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@violentr

violentr May 9, 2016

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

violentr commented May 9, 2016

alias docker-clean = 'docker rm $(docker ps -a -q) && 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

This comment has been minimized.

Show comment
Hide comment
@mastef

mastef Jun 17, 2016

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.

You have ten seconds

mastef commented Jun 17, 2016

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.

You have ten seconds

@rauluranga rauluranga referenced this issue in dokku/dokku Jun 30, 2016

Closed

Docker GC #2286

@10sr 10sr referenced this issue in 10sr/machine-setups Mar 16, 2017

Closed

Periodically delete unused containers #22

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment