Pull to refresh

Comments 33

Просто оставлю это здесь… Образ для автоматической очистки неиспользуемых объектов по расписанию в Docker Swarm (работает и просто как Docker Service )

По умолчанию удаляются следующие типы обьектов:
container
volume
network

hub.docker.com/r/pdacity/docker_gc
github.com/pdacity/docker_gc
pdacity Очень интересно, спасибо! Не знаю, нужно ли вам это, но запустил pull request с файлом README_EN.md, чтобы больше пользователей могло ознакомиться и использовать ваш образ.
Да, спасибо за английскую версию доки. Уже смержил. Наверное позже обьеденю в один README.md чтобы совсем удобнее было…

Вот так несложно, оказывается, поучаствовать в OpenSource-движении ))

Ну когда то надо начинать :) Сделал сам — поделись с другими.

UFO just landed and posted this here
добавил в скрипт и удаление неиспользуемых 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 можно безболезненно грохнуть?
Нет, не стоит…

Команда
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
там очень неспроста находится…

Фильтры — да, это очень крутая возможность. Снижает сильно необходимость строить идиотские пайплайны с grep/awk.

Рекомендую 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. Это как раз тот классический хабраслучай, когда комментарии ценнее статьи :)

Мне интересно, как остановить и удалить контейнер, у которого был поставлен resrart always

docker rm -f <имя контейнера> — стопроц должно сработать. Ну, и stop на него тоже должен работать

не работает, все равно пересоздаются…

пересоздаются != перезапускаются. Это надо зарубить себе на носу.
Если же контейнеры пересоздаются — надо искать кто это делает. Оркестратор какой вроде кубернетеса. Или пайплайн. Или кто-то особо умный обернул, скажем, докер-компоуз в систеди юнит. Телепатов нет. Дайте, пожалуйста, больше деталей

оставлю пару скриптов, которые активно пользую:


➜ 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
Помню, в стародавние времена статья на хабре ценилась за те комментарии, которые шли к ней. Добавил ваш коммент в закладки :)

а чем эффект отличается от озвученного в статье docker system prune?

Ок, спрошу по другому. Что порекомендуете записать в 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

Использовать dind сборки — тогда проблем с кэшем не возникает. Не возникает проблем с конкуретностью сборок. В минусах — больше время сборки, нужно отдельно кэши пробрасывать

Sign up to leave a comment.

Articles