spotify / docker-gc Goto Github PK
View Code? Open in Web Editor NEWINACTIVE: Docker garbage collection of containers and images
License: Apache License 2.0
INACTIVE: Docker garbage collection of containers and images
License: Apache License 2.0
Thanks for making this useful tool.
However, the current installation process requires users to manually build system packages, and it would be great if these packaged can be pre-built and published to public service like Bintray.
AFAIK, there's an official Spotify team page on Bintray: https://bintray.com/spotify
get.docker.io returns a 301 moved permanently status code to get.docker.com. cURL interprets this as success, a blank file is created in /bin/docker
, and everything appears to have succeeded until you actually attempt to run the container and nothing happens.
It seems as though even the image on dockerhub has this issue.
The fix is simple, do one or both of:
-L
argument to tell cURL to follow redirectsFor some reason I'm not quite sure of yet, we sometimes end up with entries in /var/lib/docker/containers/ that docker does not recognize. This causes errors like Error: No such image or container: 3801e6aeaf57c....
, which then causes docker-gc to error out before removing any containers. This builds up, and then we (since we apparently cron didn't send mail to the right place) have full disk.
Not sure, sadly.
Ignore the missing container and remove the rest. Display summary afterwards with errors encountered.
No containers removed
The new process detection (in 420558e) seems to be problematic when run with sudo
. This is probably because sudo
creates another copy of the process entry with root permissions, and then runs that. So there will be two copies in the process list.
If I switch to root, the command works just fine.
sudo docker-gc
Command completes successfully
docker-gc
detects the original sudo
request as a separate process, and refuses to run
GNU bash, version 4.3.42(1)-release
grep (GNU grep) 2.25
Sudo version 1.8.16
$ sudo docker-gc
[Mon Jun 27 11:47:26 EDT 2016] : docker-gc : Process is already running with PID 6817
Because the container state "FinishedAt": "0001-01-01T00:00:00Z"
is used for containers that have not exited yet, containers in the Created
state are reaped despite the grace period setting. This is an issue for automation systems such as ECS that use the remote api to create and then start a container if docker-gc runs before the container starts.
docker create
Not to delete containers in the Created
state before they have a chance to run.
Docker-gc does a really nice job here, but one thing it doesn't do: Cleaning up dangling volumes. To this end, I'm running
docker volume ls -qf dangling=true | xargs -r docker volume rm
as a cronjob; see https://github.com/chadoe/docker-cleanup-volumes. It'd perhaps be worthwhile including it into docker-gc as well.
Great work! Just one wee gotcha I hit that might be easy to fix...
grep
on my mac throws an error if you try to use an empty input file. Critically, because this is used by docker-gc
here and here, it means no containers or images are ever removed.
I think one potential work around would be to ensure that $EXCLUDE_IDS_FILE
and $EXCLUDE_CONTAINERS_IDS_FILE
have at least one line in them (perhaps something that will never match like '_FOO_'
.
eg.
$ grep --version
grep (BSD grep) 2.5.1-FreeBSD
$ cat containers.reap.tmp
6bf92fe32e92765d85b381325e702349c8bd1edb44df1537addbc593b97c1942
$ cat exclude_container_ids
$ cat containers.reap.tmp | grep -v -f exclude_container_ids
Exit 1
$ echo '_FOO_' > exclude_container_ids
$ cat containers.reap.tmp | grep -v -f exclude_container_ids
6bf92fe32e92765d85b381325e702349c8bd1edb44df1537addbc593b97c1942
I just ran docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc spotify/docker-gc
as specified in the readme. It reported removing a bunch of containers, and now it seems to be hanging indefinitely.
> docker --version
Docker version 1.8.1, build 786b29d4
Tried it again - on the second run, it produces the same output (it reported removing the same containers, so it seems like it didn't actually do anything) and hangs in the same place.
Hi Guys,
I'm using the GC and I've set the GRACE_PERIOD_SECONDS=432000
(432000seconds is 5days) although for some reason it is removing exited containers that are over 5-6hours old.
Any ideas on why this might be happening?
Thanks,
Tommy
It would be nice if the script could output in some capacity what it had removed, to be able to trace back issues where an image/container was unexpectedly removed from a host.
The current version of the script keeps some output of what it has done in the "state directory" but this is overwritten each time the script is re-run.
For instance, I would like to be able to check /var/log/cron.log to see that docker-gc deleted image 123456 three hours ago, even if I have run the script 10 times more since then.
Hello, we are using the docker-gc as a docker image running on our cluster. It is run as a systemd service with following ExecStart
: docker run --name %p --rm -v /var/run/docker.sock:/var/run/docker.sock spotify/docker-gc || docker rmi spotify/docker-gc
.
Issue we are seeing is:
Sep 22 10:59:59 ip-172-23-28-118.eu-west-1.compute.internal sh[16106]: pidof: unrecognized option: x
Sep 22 10:59:59 ip-172-23-28-118.eu-west-1.compute.internal sh[16106]: BusyBox v1.23.2 (2015-04-24 15:46:01 GMT) multi-call binary.
Sep 22 10:59:59 ip-172-23-28-118.eu-west-1.compute.internal sh[16106]: Usage: pidof [OPTIONS] [NAME]...
Sep 22 10:59:59 ip-172-23-28-118.eu-west-1.compute.internal sh[16106]: List PIDs of all processes with names that match NAMEs
Sep 22 10:59:59 ip-172-23-28-118.eu-west-1.compute.internal sh[16106]: -s Show only one PID
Sep 22 10:59:59 ip-172-23-28-118.eu-west-1.compute.internal sh[16106]: -o PID Omit given pid
Sep 22 10:59:59 ip-172-23-28-118.eu-west-1.compute.internal sh[16106]: Use %PPID to omit pid of pidof's parent
And it seems like the process doesn't get run.
Thanks
[Edit] I suspect this is to do with difference of running natively vs running in a container that is using alpine:
~/docker run -ti alpine pidof -x
pidof: unrecognized option: x
BusyBox v1.23.2 (2015-04-24 15:46:01 GMT) multi-call binary.
Usage: pidof [OPTIONS] [NAME]...
List PIDs of all processes with names that match NAMEs
-s Show only one PID
-o PID Omit given pid
Use %PPID to omit pid of pidof's parent
[Edit#2] Can theonlydoo@7fc4110 use -s
instead of -x
as that option is available in BusyBox v1.23.2 (2015-04-24 15:46:01 GMT) multi-call binary. used by Alpine?
The dockerfile uses alpine which is based on busybox.
The examples for excluding containers show a line like this
redis:[^ ]\+
However, the version of grep on busybox does not process the +.
The fix for this is to pass -E
to grep. However, I haven't sent a PR because I'm not sure of the ramifications of this change. It might break for people who aren't running busybox.
bash-4.3# docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
alpine latest 2314ad3eeb90 2 weeks ago 4.79 MB
bash-4.3# docker images | tail -n+2 | sed 's/^\([^ ]*\) *\([^ ]*\) *\([^ ]*\).*/ \1:\2 \3 /' | grep "alpine:[^ ]\+"
bash-4.3# docker images | tail -n+2 | sed 's/^\([^ ]*\) *\([^ ]*\) *\([^ ]*\).*/ \1:\2 \3 /' | grep -E "alpine:[^ ]+"
alpine:latest 2314ad3eeb90
The script shouldn't fail if EXCLUDE_FROM_GC doesn't exist.
When deleting images, Docker appears to consume all the CPU, causing the entire machine to be unresponsive. One workaround would be to add a sleep option to "yield" after each image removed.
One the cli, I would run something like this
docker images -q --filter dangling=true | xargs -I % sh -c '{ docker rmi %; sleep 3; }'
1 Run as a binary
Initialization: no /etc/docker-gc-exclude && /etc/docker-gc-exclude-containers files ( empty EXCLUDE_FROM_GC
&& EXCLUDE_CONTAINERS_FROM_GC
ENV)
Run: After the execution, i would get a /var/lib/docker-gc/exclude_container_ids file containing all of the existing containers, while /var/lib/docker-gc/exclude_ids is empty, which is not expected.
2 Run as a docker container
Simple docker run --rm -v /var/run/docker.sock:/var/run/docker.sock spotify/docker-gc
is not gonna work.
How could it possibly function well without accessing EXCLUDE_FROM_GC
ENV (sort of stuff)? 'Cause it's located in /etc/docker-gc-exclude-containers.
We need a volume at least.
Hi!
I am running the OS X beta, and the gc doesn't seem to work here. Might be the run-statement is different on OS X, but here goes.
Running the beta:
$ docker run mysql
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c6520857da8c mysql "docker-entrypoint.sh" 13 minutes ago Exited (1) 13 minutes ago jolly_payne
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
spotify/docker-gc latest a7bf2dad99ba 8 minutes ago 22.41 MB
mysql latest 63a92d0c131d 3 days ago 374.1 MB
gliderlabs/alpine 3.2 7a0dbfde8b8c 13 days ago 5.258 MB
$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc spotify/docker-gc
Container running d92a5bb3b85944333e484b67a14e7c10da248dd6cd31c54b270b9810255d7344 /goofy_pare
Container not running c6520857da8c962074fd55b5590743442ecd07c7c6eae436986fad438042945a /jolly_payne
Removing image sha256:7a0dbfde8b8c592e6507117bd29b84a4ebc3f7c8e7dfa76b1d955c5606f51c59 [gliderlabs/alpine:3.2]
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c6520857da8c mysql "docker-entrypoint.sh" 15 minutes ago Exited (1) 15 minutes ago jolly_payne
docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
spotify/docker-gc latest a7bf2dad99ba 9 minutes ago 22.41 MB
mysql latest 63a92d0c131d 3 days ago 374.1 MB
gliderlabs/alpine 3.2 7a0dbfde8b8c 13 days ago 5.258 MB
The gc should remove both images and containers..
Doesn't happen
Unfortunately docker-gc
does not seem to work when used in combination with boot2docker even though the script exits with a 0
status code.
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e2ef0285ccb5 redis:latest "/entrypoint.sh redi 7 hours ago Exited (0) 7 hours ago dock-redis
631656e621e7 mysql:latest "\"/entrypoint.sh sh 10 days ago Exited (1) 10 days ago ecstatic_mccarthy
$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock spotify/docker-gc
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e2ef0285ccb5 redis:latest "/entrypoint.sh redi 7 hours ago Exited (0) 7 hours ago dock-redis
631656e621e7 mysql:latest "\"/entrypoint.sh sh 10 days ago Exited (1) 10 days ago ecstatic_mccarthy
Support network and volume cleanup
docker-gc should clean up dangling networks and volumes automatically
...(and the git repo) to allow people to stay on a stable working version.
With Docker version 1.6.1, build 97cd073
:
$ sudo docker-gc
date: invalid date ‘"2015-07-25 09:26:5’
/usr/sbin/docker-gc: line 69: 1438142405 - : syntax error: operand expected (error token is "- ")
Bash trace:
$ sudo bash -x ./docker-gc
+ set -o nounset
+ set -o errexit
+ GRACE_PERIOD_SECONDS=3600
+ STATE_DIR=/var/lib/docker-gc
+ DOCKER=docker
+ EXCLUDE_FROM_GC=/etc/docker-gc-exclude
+ '[' '!' -f /etc/docker-gc-exclude ']'
+ EXCLUDE_FROM_GC=/dev/null
+ EXCLUDE_IDS_FILE=exclude_ids
+ '[' '!' -d /var/lib/docker-gc ']'
+ cd /var/lib/docker-gc
+ docker version
+ docker ps -a -q --no-trunc
+ sort
+ uniq
+ docker ps -q --no-trunc
+ sort
+ uniq
+ compute_exclude_ids
+ PROCESSED_EXCLUDES=processed_excludes.tmp
+ sed 's/^\(.*\)$/ \1 /' /dev/null
+ sed '/^ *$/d'
+ docker images
+ tail -n+2
+ sed 's/^\([^ ]*\) *\([^ ]*\) *\([^ ]*\).*/ \1:\2 \3 /'
+ grep -f processed_excludes.tmp
+ cut '-d ' -f3
+ sed 's/^/^/'
+ comm -23 containers.all containers.running
+ echo -n ''
+ cat containers.exited
+ read line
++ docker inspect -f '{{json .State.FinishedAt}}' 16e1b23066c2462a70fd9c027a4e85a7ed0828f306c694c5ffec36d7c7160021
+ EXITED='"2015-07-25T09:26:54.517387651Z"'
++ elapsed_time '"2015-07-25T09:26:54.517387651Z"'
+++ date -u +%s
++ utcnow=1438143000
++ without_ms='"2015-07-25T09:26:5'
++ replace_t='"2015-07-25 09:26:5'
+++ date_parse '"2015-07-25 09:26:5'
+++ date --utc
++++ date -u --date '"2015-07-25 09:26:5' +%s
date: invalid date ‘"2015-07-25 09:26:5’
+++ echo
++ epoch=
./docker-gc: line 69: 1438143000 - : syntax error: operand expected (error token is "- ")
+ ELAPSED=
$
It looks like the inspect returns surrounding quotes which are confusing the without_ms logic:
$ t=$(docker inspect -f '{{json .State.FinishedAt}}' 16e1b23066c2462a70fd9c027a4e85a7ed0828f306c694c5ffec36d7c7160021)
$ echo $t
"2015-07-25T09:26:54.517387651Z"
$ echo ${t:0:19}
"2015-07-25T09:26:5
sudo docker-gc
Traceback (most recent call last):
File "<stdin>", line 3, in <module>
File "/usr/lib/python2.7/_strptime.py", line 325, in _strptime
(data_string, format))
ValueError: time data '2015-06-17' does not match format '%Y-%m-%dT%H:%M:%S'
This is an error I get from freshly installed docker-gc on Ubuntu 15.04 amd64, Docker 1.7.0. My first guess was something locale related, but looking at the specificity of the expected format, I suppose it could be due to Docker (or some other piece of software along the way) changing some date format to a less accurate form. I have written a /etc/docker-gc-exclude file. I'll be happy to supply additional details if you need some.
I'm trying to run docker-gc on my Raspberry Pi. This is the first time I've attempted to run it. I checked it out, built and installed it with only these issues
...
warning: the authors of lintian do not recommend running it with root privileges!
E: docker-gc: no-copyright-file
E: docker-gc: extended-description-is-empty
W: docker-gc: binary-without-manpage usr/sbin/docker-gc
Finished running lintian.
I added an excludes file to my default location that just has "latest" in it.
I run the command manually and the results are...
$ docker-gc
Container not running 026614557a1a053dab3225b85216d14169fc8f9bca8ff9011319db41086d5133 /distracted_visvesvaraya
...
Container not running ffc72f6f12f8202af21fe3204ace4c2867277b213bf13d4c5457c1d35442c035 /sharp_ritchie
And then this is the error thrown at the end...
date: invalid date ‘0001-01-01 00:00:00’
/usr/sbin/docker-gc: line 102: 1456619521 - : syntax error: operand expected (error token is "- ")
No images were removed after this error was thrown. Is this a bug or did I just overlook something?
Quick one, why is Python being added in the Dockerfile ? I removed it on local and all seems to go well.
Finishing the clean up, I get this error
df: ‘/var/lib/docker’: No such file or directory
My Docker Root Dir is changed but seems process does not follow it, just go to default Docker Root Dir (/var/lib/docker/)
Change Docker Root Dir
Launch the clean up
No error.
df: ‘/var/lib/docker’: No such file or directory
Finished Cleanup (bytes free )
The following command will
- Delete all docker images for old containers
- Delete all stopped and orphan containers
Are you sure (Y/n): y
df: ‘/var/lib/docker’: No such file or directory
Starting Cleanup (bytes free )
Unable to find image 'samsaffron/docker-gc:latest' locally
latest: Pulling from samsaffron/docker-gc
0f4d770cd333: Pull complete
a3ed95caeb02: Pull complete
6a2ea02ca5be: Pull complete
bc4c30afebbb: Pull complete
Digest: sha256:1efd5febba28f881c815c37005b09c67fce0fa62d583b82790b0a0fe82cad999
Status: Downloaded newer image for samsaffron/docker-gc:latest
df: ‘/var/lib/docker’: No such file or directory
Finished Cleanup (bytes free )
If a docker pull is running while docker-gc executes it deletes intermediate layers of the currently pulled image, corrupting the download. If you try to create a container from the corrupt image, it shows an error that it cannot find an intermediate image.
On a machine of mine I'm running a similar code which removes untagged images with the command:
docker rmi $(docker images -q --filter "dangling=true")
This has the same issues and because of that I'm running it only nightly once when there's no other maintenance method is running.
I wonder if this could be improved somehow. It would be really helpful to run docker-gc more often on eg. a Jenkins build machine, where each commit can trigger a new build with a new image and we can run out of disk space quickly.
This can be really hard to fix because of the race conditions.
Learn many from docker-gc. I didn't run docker-gc but read the code.
the docker-gc's way of remove a image is
docker rmi $(image_id)
if the image has multiple repo:tag reference to it, the command will fail.
my shell removes repo:tag instead of imageid mostly, avoid the bug.
When running docker-gc I get a list of template errors logged:
Template parsing error: template: :1:2: executing "" at <.Tags>: Tags is not a field of struct type types.ImageInspect
Removing image 010a096fc84648e91a06c39a451f333b543d71dc01f3e8ac83bfdf7a39aaf18f
Use an old version of docker-gc with a newer version of docker.
The command to run without producing any errors.
I got multiple errors.
Please provide the RHEL/CentOS 7.2 repo with binaries
when I run "GRACE_PERIOD_SECONDS=1296000 docker-gc" command I get These
Container not running d9124c0ca7f9e4636dedd6455b52cd33e4dad387b8c4be56d35f33c86d9e5730 /mesos-355f00b4-958d-4578-8d42-1b6509d9d11f-S48.d2d27562-e31d-4a8d-a46f-5284a41b10bf
Container not running d9d256bf9df5b322064e69866f9d482aa073ea2b67eea7335c74a3f440db2e65 /mesos-355f00b4-958d-4578-8d42-1b6509d9d11f-S48.2f803c08-0d57-4752-b172-eb875ba15bdb
Container not running d9fa5d75765c140cf1d92c446e85e450e6599b23407ecd1f6782ab40a63b8415 /mesos-355f00b4-958d-4578-8d42-1b6509d9d11f-S48.774c05af-d679-4c4f-bbe2-24afb37211a8
Error: No such image or container: da7d5edc4a967929889cbfff956140191ff9e76f2bc6a633ecfd81b00c794f45
Container not running da7d5edc4a967929889cbfff956140191ff9e76f2bc6a633ecfd81b00c794f45
Container not running dbc831d205bb7764140701b74126527147ee11722c686e2f0a68642b0696b75c /mesos-355f00b4-958d-4578-8d42-1b6509d9d11f-S48.54e53a86-c1a3-403b-ac3e-5e3360253d0d
Container not running fef99a14b6a6194fede5c6536ce5ed70d4293566cb31a35845734acfff058904 /mesos-355f00b4-958d-4578-8d42-1b6509d9d11f-S48.9a999470-d855-4d72-a722-ab0cac88668b
Error: No such image or container: c28e76941974e662bb83b7cda955425b70196fd5c79b3215de99236682107279
then the gc work would not work.
If I manually remove the error containers and run again the command , it will work well .
Just run "GRACE_PERIOD_SECONDS=1296000 docker-gc" command
The old containers we have more than 100.
I'd like to run this on my mac. Could that be facilitated?
docker-gc
removes all image tags that are used in my custom images. I'm running docker-gc
daily on my CI server. The CI jobs build the Dockerfiles every time and because docker-gc
removes the image tags they have to be refetched once a day.
Step 1: Create a Dockerfile
:
FROM node:5.9.1-slim
CMD ["node", "-v"]
Step 2: Build it, tag it, run it. (this is what my CI job does)
docker build -t foobar .
docker run foobar
Step 3: Confirm cached steps.
docker build -t foobar .
# Everything should be cached.
Step 4: Garbage collection.
# Use a small GRACE_PERIOD_SECONDS for this demo.
# In production I use the default value.
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc \
-e "GRACE_PERIOD_SECONDS=1" spotify/docker-gc
Step 5: Build it again.
docker build -t foobar .
The FROM: node:5.9.1-slim
step is cached.
Docker pulls the node:5.9.1-slim
image again. From the README:
we take extra care to not remove any image tags (e.g., ubuntu:14.04, busybox, etc) that are in use by containers
Maybe I have the wrong expectations from it. Is there any way that I can stop it from deleting my image tags besides using the exclude env variable? I'd like to use it as last resort as it's not maintainable if new custom images show up that use other image tags.
Docker version 1.9.1, build a34a1d5
After the container exits, the garbage are still there. Did i miss anything?
FYI.
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9efcbc88a5a7 spotify/docker-gc "/docker-gc" 3 hours ago Exited (0) 3 hours ago pensive_babbage
ed3e262a531b kubernetes/example-guestbook-php-redis:v2 "/bin/sh -c /run.sh" 7 weeks ago k8s_php-redis.406c1646_frontend1.1-glg6b_default_8f56aae4-1700-11e5-bbc4-005056b462d8_be7f57fd
56145037475a gcr.io/google_containers/pause:0.8.0 "/pause" 7 weeks ago Exited (0) 7 weeks ago k8s_POD.3f830436_frontend1.1-glg6b_default_8f56aae4-1700-11e5-bbc4-005056b462d8_2fa8eda0
4072f04f94b7 kubernetes/example-guestbook-php-redis:v2 "/bin/sh -c /run.sh" 7 weeks ago Exited (137) 7 weeks ago k8s_php-redis.406c1646_frontend1.11.11-ey77r_default_8f536ebe-1700-11e5-bbc4-005056b462d8_805defa3
702acf4ac038 gcr.io/google_containers/pause:0.8.0 "/pause" 7 weeks ago Exited (0) 7 weeks ago k8s_POD.3f830436_frontend1.11.11-ey77r_default_8f536ebe-1700-11e5-bbc4-005056b462d8_9837a786
104aacc3f82a kubernetes/example-guestbook-php-redis:v2 "/bin/sh -c /run.sh" 7 weeks ago Exited (137) 7 weeks ago k8s_php-redis.406c1646_frontend2-d7c10_default_8069cf68-1700-11e5-bbc4-005056b462d8_6a87bd07
ad69bf0c7bb4 gcr.io/google_containers/pause:0.8.0 "/pause" 7 weeks ago Exited (0) 7 weeks ago k8s_POD.3f830436_frontend2-d7c10_default_8069cf68-1700-11e5-bbc4-005056b462d8_b9b421f8
c3d2e7ff2673 kubernetes/example-guestbook-php-redis:v2 "/bin/sh -c /run.sh" 7 weeks ago Exited (137) 7 weeks ago k8s_php-redis.406c1646_frontend2-rxdc3_default_7d730dff-1700-11e5-bbc4-005056b462d8_5978a680
34f8428bbe87 kubernetes/example-guestbook-php-redis:v2 "/bin/sh -c /run.sh" 7 weeks ago Exited (137) 7 weeks ago k8s_php-redis.406c1646_frontend2-g0b5x_default_7c4affa6-1700-11e5-bbc4-005056b462d8_8d471ab5
561c3a2d848b gcr.io/google_containers/pause:0.8.0 "/pause" 7 weeks ago Exited (0) 7 weeks ago k8s_POD.3f830436_frontend2-rxdc3_default_7d730dff-1700-11e5-bbc4-005056b462d8_c0070f2f
a040e2208567 kubernetes/example-guestbook-php-redis:v2 "/bin/sh -c /run.sh" 7 weeks ago k8s_php-redis.406c1646_frontend2-phomo_default_7c3bc0ec-1700-11e5-bbc4-005056b462d8_66a07d2f
a0828ebd1424 gcr.io/google_containers/pause:0.8.0 "/pause" 7 weeks ago Exited (0) 7 weeks ago k8s_POD.3f830436_frontend2-g0b5x_default_7c4affa6-1700-11e5-bbc4-005056b462d8_4ed343d8
34f88178f812 kubernetes/example-guestbook-php-redis:v2 "/bin/sh -c /run.sh" 7 weeks ago k8s_php-redis.406c1646_frontend1.11.11-o64ha_default_7aa914bd-1700-11e5-bbc4-005056b462d8_ed59ff7b
675ff1bc9874 kubernetes/example-guestbook-php-redis:v2 "/bin/sh -c /run.sh" 7 weeks ago k8s_php-redis.406c1646_frontend1.11.11-m90st_default_7aaa6160-1700-11e5-bbc4-005056b462d8_cc3df47b
960eb976f699 gcr.io/google_containers/pause:0.8.0 "/pause" 7 weeks ago Exited (0) 7 weeks ago k8s_POD.3f830436_frontend2-phomo_default_7c3bc0ec-1700-11e5-bbc4-005056b462d8_a499b54b
0d69c7ba1746 gcr.io/google_containers/pause:0.8.0 "/pause" 7 weeks ago Exited (0) 7 weeks ago k8s_POD.3f830436_frontend1.11.11-o64ha_default_7aa914bd-1700-11e5-bbc4-005056b462d8_ee66382d
74242b609cd2 gcr.io/google_containers/pause:0.8.0 "/pause" 7 weeks ago Exited (0) 7 weeks ago k8s_POD.3f830436_frontend1.11.11-m90st_default_7aaa6160-1700-11e5-bbc4-005056b462d8_6ad1a950
d6db1e21bd0e kubernetes/example-guestbook-php-redis:v2 "/bin/sh -c /run.sh" 7 weeks ago k8s_php-redis.406c1646_frontend2-skzkr_default_60b56ee5-1700-11e5-bbc4-005056b462d8_3e709dc3
efab6cd76f1e gcr.io/google_containers/pause:0.8.0 "/pause" 7 weeks ago Exited (0) 7 weeks ago k8s_POD.3f830436_frontend2-skzkr_default_60b56ee5-1700-11e5-bbc4-005056b462d8_421e0263
de5c65a6d56a kubernetes/example-guestbook-php-redis:v2 "/bin/sh -c /run.sh" 7 weeks ago Exited (137) 7 weeks ago k8s_php-redis.406c1646_frontend2-05zzs_default_56aea9cb-1700-11e5-bbc4-005056b462d8_6c2aa19c
7a2eaffb65fc gcr.io/google_containers/pause:0.8.0 "/pause" 7 weeks ago Exited (0) 7 weeks ago k8s_POD.3f830436_frontend2-05zzs_default_56aea9cb-1700-11e5-bbc4-005056b462d8_f0ae6639
316eb5ef5112 kubernetes/example-guestbook-php-redis:v2 "/bin/sh -c /run.sh" 7 weeks ago Exited (137) 7 weeks ago k8s_php-redis.406c1646_frontend1.11.11-o4loc_default_53b89715-1700-11e5-bbc4-005056b462d8_1b89f736
fe49dc0d98ad gcr.io/google_containers/pause:0.8.0 "/pause" 7 weeks ago Exited (0) 7 weeks ago k8s_POD.3f830436_frontend1.11.11-o4loc_default_53b89715-1700-11e5-bbc4-005056b462d8_96aabde1
b3145d2d2e12 kubernetes/example-guestbook-php-redis:v2 "/bin/sh -c /run.sh" 7 weeks ago k8s_php-redis.406c1646_frontend1.1-wii8j_default_51253f1d-1700-11e5-bbc4-005056b462d8_6b595f97
87d82260121e kubernetes/example-guestbook-php-redis:v2 "/bin/sh -c /run.sh" 7 weeks ago k8s_php-redis.406c1646_frontend1.11.11-89lm7_default_516961a1-1700-11e5-bbc4-005056b462d8_b597a08e
...
And NO ERROR has been reported.
ubuntu 14.04
$ docker version
Client version: 1.7.1
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 786b29d
OS/Arch (client): linux/amd64
Server version: 1.7.1
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 786b29d
OS/Arch (server): linux/amd64
It would be great if the change log for the debian build could be updated to make upgrading easier.
On debian jessie (8):
dpkg-buildpackage: binary-only upload (no source included)
Now running lintian...
E: docker-gc: no-copyright-file
E: docker-gc: extended-description-is-empty
W: docker-gc: binary-without-manpage usr/sbin/docker-gc
Finished running lintian.
Can be avoided by using --no-lintian
, eg:
$ debuild --no-lintian -us -uc -b
Example of docker
usage in the script:
cat containers.keep |
xargs -n 1 docker inspect -f '{{.Config.Image}}' 2>/dev/null |
sort | uniq |
xargs -n 1 docker inspect -f '{{.Id}}' 2>/dev/null |
sort | uniq > images.used
Is this by design? Or can I make a pull request to unify the method of calling docker
?
mkdir -p "$STATE_DIR" && cd "$STATE_DIR"
When I run docker-gc
on Ubuntu 14.04.2 LTS, I get the following error message:
date: invalid date ‘"2015-07-29 16:16:2’
/usr/sbin/docker-gc: line 69: 1438186643 - : syntax error: operand expected (error token is "- ")
Am I doing something wrong? Thanks!
When built as a debian package it creates /var/lib/docker-gc/
with perms drwxr-xr-x
and owned by root
.
The script then tries to write to this directory, which fails if docker-gc
is run as a regular user, eg:
$ /usr/sbin/docker-gc
/usr/sbin/docker-gc: line 111: containers.all: Permission denied
Just noticed my hourly docker-gc cron was removing my data only containers 😱
Is the only way to prevent this to add them as an exception? Could docker-gc check for VolumesFrom
?
Right now to set images and containers to exclude from the cleanup we need to:
Far simpler to allow environmental variables which contain a comma separated list of the containers or images.
Having to put the excluded images and containers into files and then map the volume complicates things a lot in some cases, here's an example: Jenkins (which is dockerized but has control over the hosts docker server by mounting the docker socket as a volume) runs the docker-gc regularly. In order to specify the containers and images to exclude, Jenkins needs to first put the files on the host (which requires additional volumes mounted into Jenkins) and then map those same files into the docker gc container. If we could pass in the excluded images and containers as environmental variables when the docker gc container is run it would be much simpler.
This proposal is for two new environmental variables called EXCLUDE_CONTAINERS
and EXCLUDE_IMAGES
. They would be used as follows (example):
$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -e EXCLUDE_CONTAINERS=container-one,container-two -e EXCLUDE_IMAGES=image-one,image-two spotify/docker-gc
The functionality would be:
Excluded containers:
/etc/docker-gc-exclude-containers
file exists it is ignored./etc/docker-gc-exclude-containers
file and get the excluded containers from there (or exclude no containers if the file doesn't exist).Excluded images:
/etc/docker-gc-exclude
file exists it is ignored./etc/docker-gc-exclude
file and get the excluded images from there (or exclude no images if the file doesn't exist).I want to test the behaviour of this component before put it on my infrastructure, do you have a load testing script to increase the number of containers and memory consumption ?
I am requesting for an advice.
After upgrading to Docker 1.10, docker-gc
ignored my EXCLUDE_FROM_GC
setting and removed nearly all my local Docker images.
We set a grace period of two weeks, and if there are no containers to remove, the script fails to remove any images.
Please add an option to run the script just to show what would be removed instead of removing right away.
Thank you for docker-gc, it is working nicely for us.
What I did notice is that it doesn't currently remove Dead
containers (or it tries and is unsuccessful).
It looks like docker-gc wants to keep them:
$ docker ps -a | grep Dead
45c3be6ad58e myimage "myproc" 4 days ago Dead
66feab2765bd myimage "myproc" 4 days ago Dead
2a45be87379e myimage "myproc" 4 days ago Dead
b8d073da4fac myimage "myproc" 4 days ago Dead
c0dba5cc5f20 myimage "myproc" 4 days ago Dead
$ grep 45c3b /var/lib/docker-gc/*
/var/lib/docker-gc/containers.all:45c3be6ad58e726f792bd740376551cae7072815e0ae5cfd80a663d7809dc173
/var/lib/docker-gc/containers.exited:45c3be6ad58e726f792bd740376551cae7072815e0ae5cfd80a663d7809dc173
/var/lib/docker-gc/containers.keep:45c3be6ad58e726f792bd740376551cae7072815e0ae5cfd80a663d7809dc173
/var/lib/docker-gc/containers.reap.tmp:45c3be6ad58e726f792bd740376551cae7072815e0ae5cfd80a663d7809dc173
/var/lib/docker-gc/exclude_container_ids:45c3be6ad58e
$ grep 66fea /var/lib/docker-gc/*
/var/lib/docker-gc/containers.all:66feab2765bd8527628436ae8b81980348de74855b0289407be3d4e4fec58bee
/var/lib/docker-gc/containers.exited:66feab2765bd8527628436ae8b81980348de74855b0289407be3d4e4fec58bee
/var/lib/docker-gc/containers.keep:66feab2765bd8527628436ae8b81980348de74855b0289407be3d4e4fec58bee
/var/lib/docker-gc/containers.reap.tmp:66feab2765bd8527628436ae8b81980348de74855b0289407be3d4e4fec58bee
/var/lib/docker-gc/exclude_container_ids:66feab2765bd
Although not necessarily common, it would be good to cover these or at least output them to a .dead
file which can be monitored and addressed a person or another tool.
Our production RHEL docker bloat is pretty hellacious. I would be able to hardly "contain" myself were I able to welcome docker-gc
into my CentOS boxen to help clean up.
Thanks in advance for your consideration of this feature request.
It would be great if one could configure the grace period $GRACE_PERIOD_SECONDS. I suppose a good way would be to have a /etc/default/docker-gc
file that you can source in your script. Such a file would just contain one line export GRACE_PERIOD_SECONDS=3600
.
This would help a lot! Thanks!
Michel
I haven't yet tried it out (cuz the install required doing stuff on my machine that I don't yet want to do...), but it looks like containers that were created (e.g., via docker create busybox
), but not started, will be garbage-collected because the "FinishedAt" timestamp is "0001-01-01T00:00:00Z", which is certainly more than an hour ago.
Am I misreading the code here?
since not everyone will be using the same version of the server API, the docker-gc client should be able detect and use the appropriate version of the docker API.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.