Как очистить кэш Docker и освободить место в системе

Сколько дискового пространства использует Docker?

Первый шаг - узнать, сколько дискового пространства использует Docker. Мы можем использовать команду docker system df, чтобы получить представление о том, сколько дискового пространства занимают различные артефакты.

Docker использует 36,18 ГБ для образов, 834,8 кБ для контейнеров, 15,31 ГБ для локальных томов и 1,13 ГБ для кэша сборки Docker. В общей сложности это

около 50 ГБ пространства, и большая его часть может быть освобождена.

Какое пространство мы можем вернуть без ущерба для производительности сборки Docker?

Удаление неиспользуемых образов и слоев Docker в целом вполне безопасно - если только вы не собираете в CI. Для CI очистка слоев может повлиять на производительность, поэтому лучше этого не делать. Вместо этого перейдите к нашему разделу, посвященному CI.

Удаление контейнеров из кэша Docker

Мы можем использовать команду docker container prune, чтобы очистить дисковое пространство, используемое контейнерами. Эта команда удалит все остановленные контейнеры из системы.

Мы можем опустить флаг -f здесь и в последующих примерах, чтобы получить запрос на подтверждение перед удалением артефактов.

 

Какие контейнеры не используются?

Мы можем узнать идентификаторы неиспользуемых контейнеров, выполнив команду docker ps с фильтрами по статусу контейнера. Контейнер считается неиспользуемым, если он имеет статус exited или dead.

Если мы хотим узнать размер неиспользуемого контейнера, мы можем заменить флаг -q на -s, чтобы получить размер и другие метаданные о контейнере.

Удаление всех контейнеров

Если мы хотим удалить все контейнеры из системы, мы можем остановить все запущенные контейнеры, а затем использовать ту же команду prune. Для этого нужно передать вывод docker ps -q в команду docker stop или docker kill, если вы хотите уничтожить контейнер принудительно.

Другой вариант - команда docker rm, которую можно использовать вместе с командой docker ps -a -q для удаления всех контейнеров.Другой вариант - это docker rm команда, с которой можно использовать docker ps -a -q удалить все контейнеры.

Команда docker rm принудительно удаляет запущенный контейнер по сигналу SIGKILL. Это то же самое, что и команда docker kill. Команда docker ps -a -q выведет список всех контейнеров в системе, включая запущенные, и передаст его в команду docker rm.

Удаление образов

Образы Docker могут занимать значительный объем дискового пространства. Мы накапливаем новые образы при изменении базовых образов или создаем новые, например, с помощью docker build. Мы можем использовать команду docker image prune для удаления неиспользуемых образов из системы.

По умолчанию она удаляет только болтающиеся образы, которые не связаны ни с одним контейнером и не имеют тегов.

 

Мы освободили более 2,7 ГБ пространства за счет удаления висящих изображений. Но, если вспомнить вывод команды df нашей системы docker, у нас есть 34,15 ГБ восстанавливаемых образов.

Откуда взялось остальное пространство? Это образы в нашей системе, которые помечены или связаны с контейнером. Мы можем выполнить команду docker image prune- a, чтобы принудительно удалить и эти образы, предполагая, что они не используются.

 

Таким образом, мы удаляем все неиспользуемые образы, не связанные с контейнером, а не только болтающиеся.

Удаление томов

Тома никогда не очищаются автоматически в Docker, потому что они могут содержать ценные данные. Но если мы знаем, что данные в томе нам больше не нужны, мы можем удалить его с помощью команды docker volume prune. При этом удаляются все анонимные тома, не используемые никакими контейнерами.

Интересно, что мы видим, что не освободили ни одного места. Это потому, что у нас есть тома, связанные с контейнерами. Мы можем увидеть эти тома, выполнив команду docker volume ls.

Мы получаем вывод, в котором указаны драйвер и имя тома. Команда docker volume prune удаляет только анонимные тома. Эти тома не имеют имени и конкретного названия.

 

Удаление кэша сборки

Чтобы удалить кэш сборки Docker, мы можем выполнить команду docker buildx prune, чтобы очистить кэш сборки от сборщика по умолчанию.

 

Если мы хотим удалить кэш сборки для конкретного сборщика, мы можем использовать флаг --builder, чтобы указать имя сборщика.

Удаление сетей

Хотя сети Docker не занимают дискового пространства на нашей машине, они создают сетевые мосты, iptables и записи в таблице маршрутизации. Поэтому, как и в случае с другими артефактами, мы можем удалить неиспользуемые сети с помощью команды docker network prune, чтобы очистить их.

Удаление всего с помощью docker system prune

Эквивалент docker clean all более известен как Docker prune. Мы можем удалить все неиспользуемые артефакты, созданные Docker, запустив docker system prune. При этом будут удалены все неиспользуемые контейнеры, образы, сети и кэш сборки.

 

 

По умолчанию Docker prune не удаляет тома и удаляет только висящие образы Docker. Мы можем использовать флаг --volumes, чтобы также удалить тома. Мы также можем добавить флаг -a, чтобы удалить все образы, не связанные с контейнером.

Управление кэшем сборок Docker в CI

Если вы собираете образы Docker в среде CI, вы, конечно, можете использовать и вышеприведенные команды. Однако ваши сборки могут не в полной мере использовать преимущества кэша сборок Docker по следующим структурным причинам:

В среде CI с эфемерными бегунами, такими как GitHub Actions или GitLab CI, кэш сборок не сохраняется во всех сборках без сохранения/загрузки по сети куда-нибудь за пределы эфемерного бегуна. Сохранение и загрузка кэша происходят медленно из-за низкой скорости передачи данных по сети.

По умолчанию все CI-бегунки являются эфемерными, если только вы не запускаете свои собственные.

Если есть дисковое пространство, оно обычно ограничено 10-15 ГБ. Таким образом, если вы создаете большие изображения с большим количеством слоев, вы, скорее всего, исчерпаете его.

Даже если вы создаете очень маленькие образы и храните в кэше Docker только основные слои на каждом CI runner, ваши сборки, скорее всего, не будут использовать кэш и, следовательно, будут довольно медленными, поскольку вычисление каждого слоя на каждой сборке может занять некоторое время.