Open loganknecht opened 7 years ago
jadametz
commented
7 years ago I was just thinking about the need for this functionality the other day. According to the docs it looks like some basic functionality exists around time filtering. I haven't looked at the code (yet), and would also like to hear the maintainers opinion, but if this isn't too difficult I'd even like to take a shot at the implementation! :)
thaJeztah
commented
7 years ago The docker system prune, and docker container/image/volume/network prune commands were added to have a generic "garbage collect" functionality. I think the general consensus is to not overload these functions, and only provide the basic functionality that's needed to collect unused resources, without being too specific.
The --filter option was added to set a general "policy" for what needs to be purged;
--filter until=.. allows you to specify when resources should be considered "stale" (and prevents race conditions, for example, images that were just pulled, but no container was started yet).--filter label=xyz allows you to categorise resources, and either prevent them from being removed, even though they are considered "stale" (e.g. by setting a label do-not-remove)If you want to perform more fine-grained deletes, you can combine existing commands, for example:
docker image rm $(docker image ls --filter reference=docker --quiet)or
docker image ls --filter reference=docker --quiet | xargs docker image rmSo, while I cannot entirely exclude the possibility that new filters will be added to the prune commands, we'd like to be conservative adding new options.
loganknecht
commented
7 years ago @jadametz Did we just become best friends?!
Hey @thaJeztah!
Thank you for taking the time to respond to this feature request.
I would like to request a reconsideration for this feature. I super appreciate the examples you provided. My only complaint is that they're not particularly intuitive for those unfamiliar to docker.
In addition to that this isn't a feature that has not been sought out before.
If you look at google searches (google trend wasn't working for me):
| Search | Results |
|---|---|
| docker prune images by name | 124,000 |
| docker prune images by time | 117,00 |
| docker remove images by name | 1,850,000 |
| docker remove images by time | 247,000 |
| docker prune filter by name | 28,000 |
| docker prune filter by time | 32,500 |
This is not an amazing way to correlate it, but in each of these searches it is at least demonstrating that the feature for being able to remove by name is just as popular, if not more popular, than removing by time.
I realize that being conservative with expanding a feature is important, as outside sources might not understand the product directions, nuances, or technical limitations.
However, my interaction with docker users online and offline have demonstrated that there is a demand for the ability to have a more fine-tuned ability to remove images/containers with respect to the repo, name, etc, and that being only able to filter on time is not quite sufficient enough to solve that grievance.
Please reconsider the prioritization of this, as it directly affects my organization's efficacy in using your product to manage our solution. This would immediately reduce the footprint of my organization's codebase in managing docker images.
EDIT: Accidentally closed the ticket. Sorry!
thaJeztah
commented
7 years ago Well, the image prune functionality was to address:
| Search | Result |
|---|---|
| docker remove all images | 10,200,000 |
Joking aside, I appreciate your input, I'll definitely bring this up to see what other's opinions are.
My only complaint is that they're not particularly intuitive for those unfamiliar to docker.
The reason behind it comes from the Unix philosophy ("Do One Thing and Do It Well.") - combine commands instead of re-implement functionality that's already offered otherwise. However, I understand not everyone is equally fluent at doing that (and with the introduction of Docker on Windows, the landscape definitely changed).
VimCommando
commented
6 years ago You know, I landed on this feature request because I was exactly trying to figure out how to remove "old" images out of my automated build environment without removing my build dependencies. This means I can't just remove by age, because the nodejs image might not change for weeks, while my app builds can be worthless in literally minutes.
docker image rm $(docker image ls --filter reference=docker --quiet)
That little gem is exactly what I needed. I dropped my repository name in the reference variable (not the most self-explanatory.) Since I tag both the build number and latest the docker image rm command fails on the images I want to keep. I really don't like using daemon errors as a protection mechanism, but its effective.
I do understand not wanting to over complicate commands, but I feel like having documentation on how to accomplish a desired result (in my case I was searching removing docker images by tag) with existing tools would be a huge help. None of the --filter examples I saw in the official docs even mention --filter reference= as an option; so this is the first I've heard of it.
thaJeztah
commented
6 years ago The reference filter looks to be documented here; https://docs.docker.com/engine/reference/commandline/images/#filter-images-by-reference, but not on the new docker image ls page; https://docs.docker.com/engine/reference/commandline/image_ls/#usage. This is likely because they are aliases for each other, and the docker image ls documentation is generated. 🤔
@VimCommando can you open a separate issue for that?
VimCommando
commented
6 years ago You're right, reference is documented. It is something I probably overlooked because it didn't sound anything like "name" or "tag"; and "label" is something entirely different.
An FYI for anyone else who may land on this discussion, if you want to get a list of all images with a specific tag, use this:
docker images --filter reference="*:latest"
or even shorter
docker images *:latest
The documentation kinda implies "exact match only" behavior:
The [REPOSITORY[:TAG]] value must be an “exact match”. This means that, for example, docker images jav does not match the image java.
...but wildcards are supported. So the above commands return what you'd expect -f tag=latest to do. This will clear up my errors from above 👍
@thaJeztah For the filing the separate issue, are you referring to how all the links for the docker image sub-commands all link back to the parent command's content?
jberkus
commented
6 years ago @thaJeztah
--filter label=xyz allows you to categorise resources, and either prevent them from being removed, even though they are considered "stale" (e.g. by setting a label do-not-remove)
Last I checked, there is no way to change labels on a running container. So if you want to flag a container as do-not-remove after it's been started, you're out of luck. No?
thaJeztah
commented
6 years ago @jberkus correct, there's no option (yet) to update labels on a container (see https://github.com/moby/moby/issues/21721 for a proposal) - more input is welcome there; it's been there for a while, so possibly that one should be revisited / discussed again.
jberkus
commented
6 years ago Bit of a catch-22, then, no?
1: You can't protect containers from removal by name, use labels.
2: You can't change labels on instantiated containers.
Therefore: you can't protect containers from pruning unless you knew you wanted to protect them before they were created.
AnilNeeluru
commented
6 years ago I too agree with extending --filter based on repository/tag.
If system was running of hundreds or thousands of docker images, there is definitely possibility of holding few images irrespective of its age.
For example, if i have to delete a thousand images excluding 1 or 2. I feel there is no right command to do that on docker now. Because i could not able to filter those 1 or 2 images based on repository name/tag not able to use "docker image prune" command. I agree if we label the images to exclude we can achieve, but on run time if we have to label that is not possible right now.
with this command, one could delete particular image. docker image rm $(docker image ls --filter reference=docker --quiet)
But how to exclude that particular image is some thing missing i feel. As i struggled to figure it out the easiest way of deleting all but except one.
code-brewer
commented
6 years ago I also puzzled by the statement from official document. But finall figured out how to make it work. *IMPORTANT: char do not cover '/' character !** This is the source of all oddy result. To match '/' , you must explicitly spell it there. For example:
root@lanchain03:~# docker images thematter*/*
REPOSITORY TAG IMAGE ID CREATED SIZE
thematterio/wrapper wrapper 0c0fba8fc3be 2 weeks ago 1.33GB
thematterio/headercommiter commiter 23dcdfba9283 2 weeks ago 1.33GB
root@lanchain03:~#While result empty if missing '/'
root@lanchain03:~# docker images thematter*
REPOSITORY TAG IMAGE ID CREATED SIZE
root@lanchain03:~#
jsmilani
commented
5 years ago I am frustrated by the filter options too. The --filter until=.. option is pretty useless. It doesn't do what @thaJeztah stated above, it does what its description literally says: "only remove images created before given timestamp". That is the original created date, not the date pulled or last used or anything actually useful. It doesn't solve race conditions because you can pull an image and immediately prune it prior to starting it just because it was created/built a long time ago. This basically means on a build pipeline host (ie. Jenkins) you will always be removing your base images and old, mature support images. These images are most likely to be reused and stable and your build pipeline will only slow down re-pulling images all the time.
There needs to be a proper 'unused_since' or 'pulled_prior_to' equivalent, instead of 'until'. Either of those would help, but I would prefer the 'unused_since' as long as being pulled resets the clock on being 'used'. On build machines docker images just accumulate forever. Doing a prune of everything may help when disk reaches critical levels, but given how aggressive pruning is it can't be done as regular maintenance. You can never tell how frequently your build server is being used so if you cannot prune regularly/frequently you just end up with disk alert fatigue. In the case of our Jenkins slaves they containers just get killed by Kubernetes due to the host running out of disk space and Jenkins gets stuck in a bad state.
thaJeztah
commented
5 years ago For more specific filtering (last pulled, last used), the daemon would have to have that information; it's currently not available (see a proposal / discussion here: https://github.com/moby/moby/issues/4237)
2MmYxoeg
commented
5 years ago You know, I landed on this feature request because I was exactly trying to figure out how to remove "old" images out of my automated build environment without removing my build dependencies. This means I can't just remove by age, because the nodejs image might not change for weeks, while my app builds can be worthless in literally minutes.
docker image rm $(docker image ls --filter reference=docker --quiet)That little gem is exactly what I needed. I dropped my repository name in the reference variable (not the most self-explanatory.) Since I tag both the build number and latest the
docker image rmcommand fails on the images I want to keep. I really don't like using daemon errors as a protection mechanism, but its effective.
I would think that keeping the build environment clean while maintaining the cache would be a common thing to need to do. I'm trying to follow @VimCommando's suggestion: I have applied an additional latest tag to everything that is built during the process, and then run
docker image ls --filter reference=*:latest
But this returns all the latest images, which are obviously not what I want to remove. What am I missing with this suggestion? Why does his command throw daemon exceptions on the images he wants to keep (presumably those with the latest tag - or am I misunderstanding)? I want to keep the last-built version of each of my images, the cache used to build them, and no more.
er1c
commented
5 years ago Thanks for the hints here, I had luck with docker rmi $(docker image ls --filter reference=docker.tecalliance.services/ta-jenkins --quiet | tail -n +6) this will keep the last 5 images, the tail starts on line 6 (the images are ordered in the most recent first). For just the latest, you could use +2
fr-les
commented
5 years ago I'm looking for something similar, to prune the superseded intermediate layers (only). If we build project XvN on our build server using a multi-stage build, we get intermediate layers each time. When we rebuild the same version (same tag for the final image), we end up with an old, unused copy of the intermediate layer(s) that we would like to be able to delete. docker image prune deletes even the most recent copy of the intermediate layers.
d-shi
commented
5 years ago I also ended up on this issue after trying to figure out how to prune old images from one specific registry, but do not delete any images from any other registries. There does not seem to be the ability to use --filter until= with docker image ls, and also there does not seem to be the ability to use --filter reference= with docker image prune. What gives? If either of those were options I would be able to accomplish what I'm trying to do.
olljanat
commented
5 years ago @fastreles I suggest that you look buildkit which have "Automatic garbage collection"
@d-shi if those are in use by some containers you can just run removal for all of them. It generates some errors but works. Other way is get ids/tags for images which you want to keep, filter them out from full list and remove rest (quite simple for each loop).
d-shi
commented
5 years ago @olljanat the point is I do not want to remove all the images, only those that are past a certain age and only for a specific repository. Basically I need to be able to use --filter reference= in conjunction with --filter until, but there doesn't appear to be a way to do so.
strajansebastian
commented
5 years ago example of deleting all builds except last 2 for each kind of image (the image kind is based on the Repository value.
If you want to preserve just last build modify to tail -n+2.
# delete dead containers
docker container prune -f
# keep last 2 builds for each image from the repository
for diru in `docker images --format "{{.Repository}}" | sort | uniq`; do
for dimr in `docker images --format "{{.ID}};{{.Repository}}:{{.Tag}};'{{.CreatedAt}}'" --filter reference="$diru" | sed -r "s/\s+/~/g" | tail -n+3`; do
img_tag=`echo $dimr | cut -d";" -f2`;
docker rmi $img_tag;
done;
done
# clean dangling images if any
docker image prune -f
I find it useful to keep the space usage and build time low by preserving the last cached layers for next builds.
norcis
commented
4 years ago example of deleting all builds except last 2 for each kind of image (the image kind is based on the Repository value.
If you want to preserve just last build modify to
tail -n+2.# delete dead containers docker container prune -f # keep last 2 builds for each image from the repository for diru in `docker images --format "{{.Repository}}" | sort | uniq`; do for dimr in `docker images --format "{{.ID}};{{.Repository}}:{{.Tag}};'{{.CreatedAt}}'" --filter reference="$diru" | sed -r "s/\s+/~/g" | tail -n+3`; do img_tag=`echo $dimr | cut -d";" -f2`; docker rmi $img_tag; done; done # clean dangling images if any docker image prune -fI find it useful to keep the space usage and build time low by preserving the last cached layers for next builds.
can I use this script in Windows (powershell)?
strajansebastian
commented
4 years ago example of deleting all builds except last 2 for each kind of image (the image kind is based on the Repository value. If you want to preserve just last build modify to
tail -n+2.# delete dead containers docker container prune -f # keep last 2 builds for each image from the repository for diru in `docker images --format "{{.Repository}}" | sort | uniq`; do for dimr in `docker images --format "{{.ID}};{{.Repository}}:{{.Tag}};'{{.CreatedAt}}'" --filter reference="$diru" | sed -r "s/\s+/~/g" | tail -n+3`; do img_tag=`echo $dimr | cut -d";" -f2`; docker rmi $img_tag; done; done # clean dangling images if any docker image prune -fI find it useful to keep the space usage and build time low by preserving the last cached layers for next builds.
can I use this script in Windows (powershell)?
it is a Linux bash script. You can adapt it to powershell if you find equivalent commands for those that aren't available in powershell (ex: sort, uniq, sed, etc)
cfiderer
commented
4 years ago I think it is a pain in the ass that people have to do arbitrary shell scripting magic because the --filter logic needs to match the exact number of slashes. Something like "..." or "**" that spans an arbitrary number of path elements (including slashes) cannot be too difficult.
trexx
commented
4 years ago example of deleting all builds except last 2 for each kind of image (the image kind is based on the Repository value.
If you want to preserve just last build modify to
tail -n+2.# delete dead containers docker container prune -f # keep last 2 builds for each image from the repository for diru in `docker images --format "{{.Repository}}" | sort | uniq`; do for dimr in `docker images --format "{{.ID}};{{.Repository}}:{{.Tag}};'{{.CreatedAt}}'" --filter reference="$diru" | sed -r "s/\s+/~/g" | tail -n+3`; do img_tag=`echo $dimr | cut -d";" -f2`; docker rmi $img_tag; done; done # clean dangling images if any docker image prune -fI find it useful to keep the space usage and build time low by preserving the last cached layers for next builds.
Thanks for this. Simplified further for my needs.
for r in `docker images --format "{{.Repository}}" | sort -u`; do
docker rmi $(docker images -q --filter reference="$r" | tail -n +3);
done
cron410
commented
4 years ago FYI that last script did this to my docker environment. Instead of deleting, it just removed the repo names somehow. Note all the
REPOSITORY TAG IMAGE ID CREATED SIZE
linuxserver/jackett latest 63f386731668 7 days ago 256MB
linuxserver/jackett <none> bdfe2b3bfa8d 10 days ago 256MB
packetworks/nxfilter-base experimental bd6814df93f9 11 days ago 227MB
packetworks/nxfilter-base <none> c222e1ad6e13 11 days ago 227MB
<none> <none> c80896d4531b 13 days ago 257MB
<none> <none> b8d40f6087d8 2 weeks ago 257MB
<none> <none> 9eb82d3e82b8 2 weeks ago 257MB
<none> <none> 5b0a7db872bf 2 weeks ago 257MB
linuxserver/sonarr latest 1ccb677c7d1c 2 weeks ago 602MB
<none> <none> a0659194efba 2 weeks ago 257MB
packetworks/nxfilter-base <none> 6052495a85a5 2 weeks ago 228MB
<none> <none> 72e46e55b9a3 2 weeks ago 227MB
<none> <none> 6a2ea16f34ad 2 weeks ago 257MB
<none> <none> 9da2f19ab805 3 weeks ago 257MB
jellyfin/jellyfin latest 382724236ad2 3 weeks ago 490MB
oxidized/oxidized latest 7572b369e32e 3 weeks ago 780MB
<none> <none> 2d9d8d6b2f04 3 weeks ago 257MB
oxidized/oxidized <none> 63239af1753f 3 weeks ago 780MB
<none> <none> 1543aef10b7a 3 weeks ago 257MB
<none> <none> 3a3b9a13dd5c 3 weeks ago 257MB
linuxserver/sonarr <none> bf70898e2e0f 3 weeks ago 602MB
<none> <none> ad5f8d92335d 3 weeks ago 257MB
<none> <none> ecfd0f6cbe83 3 weeks ago 257MB
mumiehub/rclone-mount latest ec76d855be9b 4 weeks ago 216MB
<none> <none> 1cde8d66ac3a 4 weeks ago 256MB
<none> <none> bde4608a8d2c 4 weeks ago 256MB
mumiehub/rclone-mount <none> 641e22960a9f 4 weeks ago 216MB
<none> <none> 3b02207f6bdd 4 weeks ago 602MB
<none> <none> fc618a5b2962 4 weeks ago 256MB
<none> <none> e7a34f104ba6 4 weeks ago 256MB
<none> <none> 50b0e1bbb855 5 weeks ago 256MB
jellyfin/jellyfin <none> b32fb40fff8d 5 weeks ago 490MB
<none> <none> 98f154414b1e 5 weeks ago 256MB
<none> <none> a602ed0268a4 5 weeks ago 256MB
<none> <none> 3615043b1dd4 5 weeks ago 256MB
<none> <none> 8b1c6ce14b4a 5 weeks ago 602MB
<none> <none> b3a3d916b663 5 weeks ago 256MB
<none> <none> 5ab85f085704 5 weeks ago 256MB
<none> <none> b19d938cc82c 5 weeks ago 490MB
<none> <none> 07825c64ab2e 6 weeks ago 256MB
<none> <none> 19dc778507b1 6 weeks ago 801MB
<none> <none> c0fe5d69aba8 6 weeks ago 256MB
<none> <none> eab5a2e5d162 6 weeks ago 256MB
<none> <none> 66d118947c53 6 weeks ago 601MB
<none> <none> a066f4c1023a 6 weeks ago 256MB
themetabay/plex latest ccd753cc241c 6 weeks ago 412MB
<none> <none> eea6e5a2388b 6 weeks ago 256MB
<none> <none> 4b4f7170b236 6 weeks ago 801MB
<none> <none> 5539950ce913 6 weeks ago 256MB
<none> <none> b93741ff3759 7 weeks ago 256MB
<none> <none> 19ffa37f5545 7 weeks ago 490MB
jlesage/filezilla latest 58bde8ee2847 7 weeks ago 176MB
binhex/arch-delugevpn latest 03fca3252cb3 7 weeks ago 1.15GB
<none> <none> 85375b738c25 7 weeks ago 256MB
<none> <none> 5f5fa5e99994 7 weeks ago 256MB
<none> <none> 5167768fca8b 7 weeks ago 256MB
<none> <none> f980ed87a8c3 7 weeks ago 601MB
<none> <none> ea5c4f8a3ad9 7 weeks ago 256MB
<none> <none> 4a22cd50bd2e 7 weeks ago 256MB
<none> <none> d36a82634f69 7 weeks ago 256MB
<none> <none> 36578d24956d 8 weeks ago 256MB
<none> <none> c05e754fb88b 8 weeks ago 256MB
<none> <none> 6fd7a31d5764 8 weeks ago 256MB
<none> <none> 94a66c4a33a5 8 weeks ago 800MB
<none> <none> 6c691b24e4da 8 weeks ago 256MB
<none> <none> a3f85392c37d 2 months ago 601MB
<none> <none> ef4cb97b1e94 2 months ago 256MB
<none> <none> f7b7c1eee155 2 months ago 256MB
<none> <none> 048d10cb0037 2 months ago 256MB
<none> <none> f55adcf7e8e3 2 months ago 787MB
<none> <none> cfddfcbc78e2 2 months ago 256MB
<none> <none> e7ab4338a50d 2 months ago 256MB
<none> <none> d9ac17394a3c 2 months ago 256MB
<none> <none> 7c5be4fa47aa 2 months ago 787MB
<none> <none> 4c72eed85a75 2 months ago 601MB
<none> <none> 68d95d258f02 2 months ago 256MB
<none> <none> 6c16468c9a07 2 months ago 786MB
<none> <none> 5a20ae8a38a3 2 months ago 256MB
<none> <none> 9d5a2990e8fd 2 months ago 256MB
binhex/arch-delugevpn <none> c44c77b98e9e 2 months ago 1.51GB
<none> <none> f8664e8da317 2 months ago 256MB
<none> <none> 926310ad16eb 2 months ago 256MB
<none> <none> 5acadc50966f 2 months ago 601MB
<none> <none> 1155c0dcc9c7 2 months ago 256MB
<none> <none> 11499135c813 2 months ago 256MB
<none> <none> 70dcd2b6c691 2 months ago 256MB
<none> <none> 002084c9f5b5 2 months ago 256MB
<none> <none> 7dfe70b03a8c 2 months ago 256MB
<none> <none> f7b6bf679daa 2 months ago 256MB
<none> <none> a7e4fcff1266 2 months ago 601MB
<none> <none> 0acbd03afd39 2 months ago 231MB
<none> <none> 8878d4824d94 2 months ago 785MB
<none> <none> c95194bdb9e8 2 months ago 256MB
<none> <none> d918c177169e 2 months ago 256MB
<none> <none> 2a6d00a2e172 2 months ago 256MB
<none> <none> 0790e64d3fe5 2 months ago 256MB
<none> <none> 119db795be53 2 months ago 859MB
themetabay/plex <none> a3618ab21984 2 months ago 484MB
<none> <none> 10f252b29637 2 months ago 230MB
<none> <none> aea6d2650183 2 months ago 256MB
<none> <none> 7b41e5eaa558 3 months ago 256MB
<none> <none> 187e05c203c9 3 months ago 256MB
<none> <none> 83355ce89b01 3 months ago 256MB
<none> <none> f713752e6c0a 3 months ago 256MB
<none> <none> b4d717215f93 3 months ago 256MB
<none> <none> 4bb19983272f 3 months ago 601MB
<none> <none> 890fca1528da 3 months ago 256MB
<none> <none> 6592497c21bc 3 months ago 257MB
<none> <none> aa82d669e07b 3 months ago 484MB
<none> <none> d6719e5e3c8d 3 months ago 257MB
<none> <none> 4c85128495a3 3 months ago 257MB
<none> <none> f1ee2c088a2f 3 months ago 257MB
<none> <none> bfc8f126b5ab 3 months ago 257MB
<none> <none> bce7d1479b58 3 months ago 257MB
<none> <none> 9ae842cfb051 3 months ago 257MB
<none> <none> 76a8e933c5ff 3 months ago 858MB
<none> <none> 205f06e7525f 3 months ago 257MB
<none> <none> 2d602922a6d3 3 months ago 245MB
<none> <none> fb453468cc2f 3 months ago 484MB
<none> <none> 028a37b1675f 3 months ago 257MB
<none> <none> c844870baa5f 3 months ago 257MB
<none> <none> 961789918df2 3 months ago 257MB
<none> <none> 9eabd7e7203b 3 months ago 257MB
<none> <none> 7030321b385d 3 months ago 484MB
<none> <none> a1ad9d784d10 3 months ago 602MB
<none> <none> 3df9e0982eae 3 months ago 858MB
<none> <none> 05cfb81cac0a 3 months ago 257MB
<none> <none> bf991441d2b4 3 months ago 257MB
<none> <none> ffb58b9c9723 3 months ago 1.64GB
<none> <none> dec2635da3e4 3 months ago 484MB
jlesage/filezilla <none> f9422cb626af 3 months ago 169MB
<none> <none> 0b3eee2f2f0d 3 months ago 858MB
<none> <none> 244ed64f7cfc 3 months ago 1.64GB
<none> <none> cd6415122893 3 months ago 858MB
<none> <none> e9c7803dbb0d 3 months ago 257MB
<none> <none> 828a9660361e 3 months ago 257MB
<none> <none> 7d957ae9580f 3 months ago 858MB
<none> <none> ce044bd00ae4 3 months ago 257MB
<none> <none> 11abb8a9f31a 3 months ago 858MB
<none> <none> 44885c9e2b8f 3 months ago 257MB
<none> <none> 4fe767535787 3 months ago 257MB
<none> <none> 0db5c9df1401 3 months ago 223MB
<none> <none> 74a7f5f18221 3 months ago 257MB
<none> <none> f304cdc4c9ed 3 months ago 257MB
<none> <none> 95d8de2f7f4f 3 months ago 857MB
mcuadros/ofelia latest 854f2a3c68f3 3 months ago 22.6MB
<none> <none> a0a207e4294f 4 months ago 257MB
<none> <none> ce929664e5a9 4 months ago 257MB
<none> <none> 0fd0c82521d8 4 months ago 214MB
<none> <none> 2f6d895ce7a6 4 months ago 484MB
<none> <none> 35a0d9c86a72 4 months ago 257MB
<none> <none> 422773a8f5f7 4 months ago 602MB
<none> <none> dfff3dd64204 4 months ago 257MB
<none> <none> 26f6899f00ef 4 months ago 213MB
<none> <none> 421bf5d5225f 4 months ago 257MB
<none> <none> 4459dbd4ea56 4 months ago 169MB
packetworks/nxfilter-base <none> 904c5fcdabaf 4 months ago 225MB
<none> <none> 9af165cdad4b 4 months ago 257MB
<none> <none> 5590b9f346b1 4 months ago 257MB
<none> <none> b537f902a8ab 4 months ago 257MB
mcuadros/ofelia <none> fa2b87464ed1 4 months ago 22.6MB
<none> <none> d487bae4b39a 4 months ago 601MB
<none> <none> 5159d16943cd 4 months ago 257MB
<none> <none> ae67ba584674 4 months ago 483MB
<none> <none> eb3d07baaed4 4 months ago 257MB
<none> <none> 51554535409c 4 months ago 257MB
<none> <none> 74edb37eac3d 4 months ago 257MB
<none> <none> 5e41dfe87d74 4 months ago 462MB
<none> <none> f8a2a2223ab8 4 months ago 257MB
<none> <none> 3e0d7bf105fd 4 months ago 169MB
<none> <none> a5bb5cdcc06c 4 months ago 483MB
<none> <none> 49de591e5637 4 months ago 601MB
<none> <none> b94603f1b923 4 months ago 601MB
<none> <none> 43536a408d02 4 months ago 856MB
<none> <none> ae8e1a0ef210 4 months ago 257MB
<none> <none> deb55b45401b 4 months ago 212MB
<none> <none> 22ca71beca2f 4 months ago 855MB
<none> <none> 7975a483b340 4 months ago 1.55GB
<none> <none> 9296c37dba60 4 months ago 493MB
<none> <none> 4368897d0c33 5 months ago 483MB
<none> <none> 05d4494a3a41 5 months ago 22.6MB
<none> <none> 2f11c5ed4b12 5 months ago 169MB
aptrust/nginx-proxy latest 77a9a25bb676 6 months ago 54.4MB
pihole/pihole latest 694e8aa9d588 6 months ago 289MB
linuxserver/cardigann latest 6c2b3fd6e39c 6 months ago 39.6MB
python 3.7-alpine a5d195bb2a63 7 months ago 97.8MB
<none> <none> e51f37599eef 7 months ago 514MB
alpine/socat latest 2398cf75de68 8 months ago 9.05MB
python 2.7 426ba9523d99 8 months ago 896MB
<none> <none> d230a51a07d4 10 months ago 41.7MB
nunofgs/octoprint latest 56bd458b43e8 10 months ago 890MB
nunofgs/octoprint alpine 09368a3a03e0 10 months ago 514MB
bbtsoftwareag/nginx-proxy-unrestricted-requestsize alpine d2d7e6dc887e 11 months ago 54.3MB
mumiehub/rclone-mount <none> 299c4c7a66a1 11 months ago 168MB
<none> <none> c112ea25aef0 12 months ago 220MB
busybox latest db8ee88ad75f 13 months ago 1.22MB
alpine 3.9 055936d39205 16 months ago 5.53MB
bcardiff/rclone latest 461f8c0cc38c 16 months ago 38.1MB
ubuntu latest d131e0fa2585 16 months ago 102MB
bash latest f63c4bf22009 16 months ago 15.1MB
willfarrell/autoheal latest 2b5329557072 18 months ago 18.2MB
vimagick/sslsplit latest a9bcdf37fd95 19 months ago 9.14MB
octoprint/octoprint latest 84a40e332987 21 months ago 1.19GB
iamjohnnym/bionic-python 3.7 9fefceecfe41 22 months ago 148MB
bcicen/docker-replay latest 58c86c8beb1e 23 months ago 67MB
v2tec/watchtower latest 3069a9fb302a 2 years ago 9.49MB
iitgdocker/iperf-web latest 00bc1f63404d 3 years ago 415MB
1science/java oracle-jre-8 fb375357ddef 3 years ago 176MBDangling images? Might need to add an additional command to prune them https://docs.docker.com/engine/reference/commandline/image_prune/
raffraffraff
commented
3 years ago I can't believe it's still such a pain to keep CI boxes clean in 2021. Things that would really help:
--dry-run option to the prune commanddocker image ls and docker image prune.--filter="label=maintainer!=NVIDIA CORPORATION <cudatools@nvidia.com>"--filter="label!=maintainer=NVIDIA CORPORATION <cudatools@nvidia.com>"[edit: Ironically, I keep NVIDIA images because they are ridiculously huge. I don't want CI pulling them every time]]
vrmerlin
commented
3 years ago I concur that this is a problem. In my case, I have several GitLab runner hosts that are constantly building applications, meaning they are constantly generating new images which can be disposed of after they are pushed into a private Docker repo. But there are also a lot of other images which I'd prefer to just stay (e.g. images for doing the build process, like JDKs, etc). I'd really like to do docker system prune -a -f --filter "repository=foobar.com* or something similar.
JamesBewley
commented
3 years ago I would like to run the following:
docker image prune --force --filter="repository=myrepo" --filter="until=168h"
Is the alternative really to use a combination of docker ls and tail
Vigrond
commented
1 month ago Bit of an old issue, but it turned up in google. so here is my working solution.
this is for the use case where you are building your own images like with @vrmerlin 's comment
# build our image with labels
docker build --label repository=foobar.com
# run the new image. do stuff. maybe build more images with same label.
docker run [...]
docker build [...]
# lets make sure filter is working correctly first by listing the images
docker image ls --filter label=repository=foobar.com
# now we can prune
docker image prune --filter label=repository=foobar.comthe --label option of docker build adds a "config": {"labels": { "repository": "foobar.com"}} into the images metadata. you can see your labels with docker image inspect
This method is currently working well for me in gitlab CI
Preface
Hello there!
I've done some googling and I have not seen any clear documentation or discussion about this aspect of the
docker image prunecommand.I've read a fair amount of the documentation here:
Problem
There appears to be no mechanism for filtering on information specific to the image name and/or tags.
User Story
I have a build process that builds intermediate images for my process. In addition to that I'm also pulling in other images from a docker registry, and this machine may be dirty from the build system using other build processes docker images.
Because of this I would like to be able to filter out images/tags that are irrelevant and/or relevant to my images.
For example, my docker images after the process is run, looks like so:
Hypothetical Solution
What would be super convenient is the ability to filter based on the image name, the repo that houses the images, and/or the ability to filter by tags as well within that context.
Let's pretend I want to remove all images retrieved from the example.com repo.
Remove images based on repo fuzzy matching
docker image prune --force --filter "repository=example.com*"Or maybe I want it based on image name
Remove images based on image name fuzzy matching
docker image prune --force --filter "repository=*example_product*"Questions
Am I misunderstanding the
--filterflag?I realize grep'ing is a solution, but this seems like the tool itself would benefit more from creating this feature rather than relying on work arounds from within the environment's tooling?
I look forward to your feedback 😄
Output of
docker version:Output of
docker info:Additional environment details (AWS, VirtualBox, physical, etc.): OSX