Комментарии 33
Просто оставлю это здесь… Образ для автоматической очистки неиспользуемых объектов по расписанию в Docker Swarm (работает и просто как Docker Service )
По умолчанию удаляются следующие типы обьектов:
container
volume
network
hub.docker.com/r/pdacity/docker_gc
github.com/pdacity/docker_gc
По умолчанию удаляются следующие типы обьектов:
container
volume
network
hub.docker.com/r/pdacity/docker_gc
github.com/pdacity/docker_gc
pdacity Очень интересно, спасибо! Не знаю, нужно ли вам это, но запустил pull request с файлом README_EN.md, чтобы больше пользователей могло ознакомиться и использовать ваш образ.
Да, спасибо за английскую версию доки. Уже смержил. Наверное позже обьеденю в один README.md чтобы совсем удобнее было…
Смержил описания на русском и английском. Добавил реф. :) Теперь красота прям.
github.com/pdacity/docker_gc
github.com/pdacity/docker_gc
добавил в скрипт и удаление неиспользуемых ext. volumes
Обновите локальные репы.
Обновите локальные репы.
docker system dfСпасибо, запомню!
Но почему
du -d1 -h /var/lib/dockerпоказывает почти в два раза больше? Хардлинки? Разреженные файлы? Недостоверность вывода docker system df?
Уточню: docker system prune говорит, что всё чисто.
docker system prune -f -a --volumes что скажет ?
docker system prune -f -a --volumes
untagged…
deleted…
Total reclaimed space: 5.187GB
Все образы удалились (благо, важные были залиты в корпоративный registry).
Теперь
docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 0 0 0B 0B
Containers 0 0 0B 0B
Local Volumes 0 0 0B 0B
Build Cache 0 0 0B 0B
du -d1 -h /var/lib/docker/aufs
320K /var/lib/docker/aufs/layers
3,8G /var/lib/docker/aufs/diff
324K /var/lib/docker/aufs/mnt
3,8G /var/lib/docker/aufs
Эти 3,8G можно безболезненно грохнуть?
Нет, не стоит…
Команда
удаляет все образа, ext. volumes и контейнеры которые не запущены или не задействованы в запущеных контейнерах.
Чтобы сохранить на узле образа, которые например нужны для сборки контейнеров как промежуточные или по иным резонам — рекомендую посмотреть репу из первого комментария. Там небольшая магия — на образ навешивается label и все помеченные образа игнорируются при prune. Но можно и с cli задать фильтр что включать или что исключать.
Вот кусок оригинальной документации где это подробней описано:
docs.docker.com/engine/reference/commandline/system_prune
PS. Особенно не стоит удалять руками напрямую в системе ext. volumes находящиеся в дефолтовом хранилище докера. Потому что файлик:
Команда
docker system prune -f -a --volumesудаляет все образа, ext. volumes и контейнеры которые не запущены или не задействованы в запущеных контейнерах.
Чтобы сохранить на узле образа, которые например нужны для сборки контейнеров как промежуточные или по иным резонам — рекомендую посмотреть репу из первого комментария. Там небольшая магия — на образ навешивается label и все помеченные образа игнорируются при prune. Но можно и с cli задать фильтр что включать или что исключать.
Вот кусок оригинальной документации где это подробней описано:
Filtering
The filtering flag (--filter) format is of “key=value”. If there is more than one filter, then pass multiple flags (e.g., --filter "foo=bar" --filter "bif=baz")
The currently supported filters are:
until (<timestamp>) - only remove containers, images, and networks created before given timestamp
label (label=<key>, label=<key>=<value>, label!=<key>, or label!=<key>=<value>) - only remove containers, images, networks, and volumes with (or without, in case label!=... is used) the specified labels.
The until filter can be Unix timestamps, date formatted timestamps, or Go duration strings (e.g. 10m, 1h30m) computed relative to the daemon machine’s time. Supported formats for date formatted time stamps include RFC3339Nano, RFC3339, 2006-01-02T15:04:05, 2006-01-02T15:04:05.999999999, 2006-01-02Z07:00, and 2006-01-02. The local timezone on the daemon will be used if you do not provide either a Z or a +-00:00 timezone offset at the end of the timestamp. When providing Unix timestamps enter seconds[.nanoseconds], where seconds is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (aka Unix epoch or Unix time), and the optional .nanoseconds field is a fraction of a second no more than nine digits long.
The label filter accepts two formats. One is the label=... (label=<key> or label=<key>=<value>), which removes containers, images, networks, and volumes with the specified labels. The other format is the label!=... (label!=<key> or label!=<key>=<value>), which removes containers, images, networks, and volumes without the specified labels.docs.docker.com/engine/reference/commandline/system_prune
PS. Особенно не стоит удалять руками напрямую в системе ext. volumes находящиеся в дефолтовом хранилище докера. Потому что файлик:
/var/lib/docker/volumes/metadata.db
Рекомендую graph driver перевести на overlay2. Aufs — старое и глючное.
Просто обожаю эти команды:
# Historical command
$ docker rm -f $(docker ps –aq)А если внутренняя команда выведет мусор или пустое множество? В конкретном случае угрозы, конечно, почти нет ) ну, не почистили и не почистили, но в целом это плохая практика.
Например, вариант с xargs выглядит предпочтительнее:
docker ps -aq | xargs -r -I{} docker rm -f {}(Пишу по памяти, поэтому сильно не бейте ногами )))
это не те дроиды, которых вы ищетеот rm, который прославился
Хоть это и не тот rm, который прославился, как напомнил нам maxzhurkin, но все же вы правы: не стоит слепо доверять выводу команд. В следующий раз добавлю комментарий переводчика :)
AlexanderTyutin что в итоге рекомендуете записать в cron?
docker container prune
docker image prune
docker volume prune
docker builder prune
или
docker system prune
docker volume prune
?
— С чего начинать, Ваше Величество? — спросил он. — Начни с начала, — важно ответил Король, — продолжай, пока не дойдешь до конца. Как дойдешь — кончай!... (с) Люис Кэрол, Алиса в стране чудес.
Что добавлять в cron зависит от отго, что ты хочешь получить в результате. Главная мысль — удалять мусор из docker следует механизмами самого docker-а а не системными утилитами.
Например если у тебя на узле активно идет сборка образов, то нет смысла подчищать образа на базе которых идет сборка.
Например если у тебя на узле активно идет сборка образов, то нет смысла подчищать образа на базе которых идет сборка.
Имеет. Но зависит от задачи. Тут момент какой. Предположим, что ты собираешь свой образ из образа, который записан под определенным тегом, но иногда меняется. Если образа в кэше нет — докер его качает из регистри (докер хаба). Если есть — он его никогда не перекачает, если в регистри есть обновленный, пока пользователь сам явно не сделает docker pull. С другой стороны, вы можете мне возразить, что все сборки надо обязательно делать с фиксированных тегов (либо по тегу а-ля v.1.x.x, либо по sha образа), но опять же — у всех разные кейсы
chemtech Рекомендовать лично вам я не могу по причине того, что не знаю вашу инфраструктуру.
Например, у меня есть VPS, который служит чисто для тестовых целей: подключаясь к нему сегодня, мне совешенно не нужно помнить, что там было вчера. Но так как я за него плачу, и быстродействие его мне важно, для меня подойдет docker system prune :) Все нужные мне команды и процессы я быстрее восстанавливаю через команду history нежели docker ps -a.
Но уже в рабочей среде, где важны более наработки нежели направления, я бы воспользовался очисткой кэша, а также советами и образом pdacity. Это как раз тот классический хабраслучай, когда комментарии ценнее статьи :)
Например, у меня есть VPS, который служит чисто для тестовых целей: подключаясь к нему сегодня, мне совешенно не нужно помнить, что там было вчера. Но так как я за него плачу, и быстродействие его мне важно, для меня подойдет docker system prune :) Все нужные мне команды и процессы я быстрее восстанавливаю через команду history нежели docker ps -a.
Но уже в рабочей среде, где важны более наработки нежели направления, я бы воспользовался очисткой кэша, а также советами и образом pdacity. Это как раз тот классический хабраслучай, когда комментарии ценнее статьи :)
Мне интересно, как остановить и удалить контейнер, у которого был поставлен resrart always
оставлю пару скриптов, которые активно пользую:
➜ cat ~/bin/docker_gc
#!/usr/bin/env bash
docker rm -v $(docker ps --filter status=exited -q 2>/dev/null) 2>/dev/null
docker rmi $(docker images --filter dangling=true -q 2>/dev/null) 2>/dev/null%
➜ cat ~/bin/docker_gc_full
#!/usr/bin/env bash
docker_gc
docker rmi -f $(docker images -a -q) 2>/dev/null
Ок, спрошу по другому. Что порекомендуете записать в cron в gitlab runner для очистки от docker образов, остановленных контейнеров, неиспользующихся volume??
Может вот так:
docker rm -v $(docker ps --filter status=exited -q 2>/dev/null) 2>/dev/null
docker rmi $(docker images --filter dangling=true -q 2>/dev/null) 2>/dev/null%
docker volume pruneЗарегистрируйтесь на Хабре, чтобы оставить комментарий
Docker Tips: Очистите свою машину от хлама