Очистить кэш docker compose

Обновлено: 04.07.2024

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

Такой подход предоставил разработчику возможность запускать любые приложения, не загрязняя локальную машину. Однако, когда мы запускаем контейнеры, развертываем сложные стеки приложений, создаем собственные образы и извлекаем их, потребление памяти в файловой системе хоста может значительно увеличиться.

Если мы не очищали локальную машину в течение некоторого времени, то результаты этой команды могут удивить:

$ docker system df

Пример потребления памяти Docker в файловой системе хоста Пример потребления памяти Docker в файловой системе хоста

Эта команда показывает использование диска Docker в нескольких категориях:

Образы (Images) : размер образов, извлеченных из реестра и созданных локально.
Контейнеры (Containers) : дисковое пространство, занимаемое слоями чтения-записи каждого из контейнеров, работающих в системе.
Локальные тома (Local Volumes) : в случае, если хранение осуществляется на хосте, но вне файловой системы контейнера.
Кэш сборки (Build Cache) : кэш, сгенерированный процессом сборки образа (касается BuildKit в Docker 18.09).

Из вывода выше видно, что большое количество дискового пространства можно восстановить. Поскольку оно не используется Docker, его можно вернуть хост-машине.

Использование диска контейнерами

Каждый раз, когда создается контейнер, в папке /var/lib/docker на хост-машине появляется несколько папок и файлов. Среди них:

Папка /var/lib/docker/containers/ID (ID — уникальный идентификатор контейнера). Если контейнер использует драйвер логгирования по умолчанию, все логи будут сохранены в файле JSON внутри нее. Создание слишком большого количества логов может повлиять на файловую систему хост-машины.
Папка в /var/lib/docker/overlay2 , содержащая слой чтения-записи контейнера (overlay2 является предпочтительным драйвером хранилища в большинстве дистрибутивов Linux). Если контейнер сохраняет данные в своей собственной файловой системе, они будут храниться в /var/lib/docker/overlay2 на хост-машине.

Представим, что у нас есть совершенно новая система, в которой только что был установлен Docker.

Во-первых, запустим контейнер NGINX:

$ docker container run --name www -d -p 8000:80 nginx:1.16

Снова запустив команду df, мы увидим:

один образ размером 126 Мбайт. Его загрузил NGINX : 1.16 , когда мы запустили контейнер;

контейнер www, запускающийся из образа NGINX.

Поскольку контейнер запущен, а образ в данный момент используется, освобождаемого пространства пока нет. Так как его размер (2B) незначителен, и поэтому его нелегко отследить в файловой системе, создадим пустой файл размером 100 Мбайт в файловой системе контейнера. Для этого мы используем удобную команду dd из контейнера www .

$ docker exec -ti www \
dd if=/dev/zero of=test.img bs=1024 count=0 seek=$[1024*100]

Этот файл создается в слое чтения-записи, связанном с этим контейнером. Если мы снова проверим вывод команды df, то увидим, что он теперь занимает некоторое дополнительное дисковое пространство.

Где находится этот файл на хосте? Проверим:

$ find /var/lib/docker -type f -name test.img
/var/lib/docker/overlay2/83f177. 630078/merged/test.img
/var/lib/docker/overlay2/83f177. 630078/diff/test.img

Не вдаваясь глубоко в детали — этот файл был создан на слое чтения-записи контейнера, который управляется драйвером overlay2. Если мы остановим контейнер, используемое им дисковое пространство станет пригодным для восстановления. Посмотрим:

Как можно восстановить это пространство? Путем удаления контейнера, что приведет к удалению связанного с ним слоя чтения-записи.

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

Из вывода видно, что больше нет места, используемого контейнерами, и, поскольку образ больше не используется (контейнер не работает), пространство, которое он использует в файловой системе хоста, может быть восстановлено:

Примечание: если образ используется хотя бы одним контейнером, занимаемое им дисковое пространство не может быть освобождено.

Подкоманда prune, которую мы применяли выше, удаляет остановленные контейнеры. Если нам нужно удалить все — и запущенные, и остановленные, мы можем использовать одну из следующих команд (обе эквивалентны):

Примечание: во многих случаях стоит использовать флаг --rm при запуске контейнера, чтобы он автоматически удалялся при остановке процесса PID 1, тем самым немедленно освобождая неиспользуемое пространство.

Использование диска образами

Существует несколько видов образов, которые не видны напрямую конечному пользователю:

Промежуточные — те, что ссылаются на другие (дочерние) и не могут быть удалены.
Висящие — это те, на которые больше нет ссылок. Они занимают некоторое место на диске и могут быть удалены.

Следующие команды отображают висящие образы в системе:

$ docker image ls -f dangling=true
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> 21e658fe5351 12 minutes ago 71.3MB

Чтобы удалить их, можно пойти долгим путем:

$ docker image rm $(docker image ls -f dangling=true -q)

Или использовать подкоманду prune:

Использование диска кэшем сборки

В релизе Docker 18.09 представлены усовершенствования процесса сборки с помощью BuildKit . Использование этого инструмента позволяет повысить производительность, управление хранилищем, функциональность и безопасность. Мы не будем подробно его описывать, а просто посмотрим, как его включить и как он влияет на использование диска.

Рассмотрим следующее фиктивное приложение Node.Js и связанный с ним Dockerfile:

Dockerfile определяет, как построить образ из приведенного выше кода:

Создадим образ как обычно и без включенного BuildKit:

$ docker build -t app:1.0 .

При проверке использования диска мы увидим только базовый ( node:13-alpine был загружен в начале сборки) и конечный образ сборки ( app: 1.0 ):

$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 2 0 109.3MB 109.3MB (100%)
Containers 0 0 0B 0B
Local Volumes 0 0 0B 0B
Build Cache 0 0 0B 0B

Теперь соберем версию образа 2.0 с BuildKit. Нужно просто установить DOCKER_BUILDKIT в 1:

$ DOCKER_BUILDKIT=1 docker build -t app:2.0 .

При повторной проверке использования диска видим, что был создан кэш сборки (Build Cache):

$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 2 0 109.3MB 109.3MB (100%)
Containers 0 0 0B 0B
Local Volumes 0 0 0B 0B
Build Cache 11 0 8.949kB 8.949kB

Для его удаления можно выполнить:

$ docker builder prune

WARNING! This will remove all dangling build cache.
Are you sure you want to continue? [y/N] y
Deleted build cache objects:
rffq7b06h9t09xe584rn4f91e
ztexgsz949ci8mx8p5tzgdzhe
3z9jeoqbbmj3eftltawvkiayi
Total reclaimed space: 8.949kB

Total reclaimed space: 8.949kB

Очистка всего и сразу

В приведенных выше примерах каждая из команд контейнера, образа и тома предоставляет подкоманду prune для освобождения дискового пространства. Она доступна на системном уровне Docker, поэтому удаляет все сразу:

$ docker system prune
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all dangling images
- all dangling build cache

Are you sure you want to continue? [y/N]

Выполнение этой команды время от времени для очистки диска — хорошая привычка.

Если мы не очищали локальную машину в течение некоторого времени, то результаты этой команды могут удивить:

Пример потребления памяти Docker в файловой системе хоста

Эта команда показывает использование диска Docker в нескольких категориях:

Образы (Images): размер образов, извлеченных из реестра и созданных локально.
Контейнеры (Containers): дисковое пространство, занимаемое слоями чтения-записи каждого из контейнеров, работающих в системе.
Локальные тома (Local Volumes): в случае, если хранение осуществляется на хосте, но вне файловой системы контейнера.
Кэш сборки (Build Cache): кэш, сгенерированный процессом сборки образа (касается BuildKit в Docker 18.09).

Из вывод а выше видно, что большое количество дискового пространства можно восстановить. Поскольку оно не используется Docker, его можно вернуть хост-машине.

Использование диска контейнерами

Папка /var/lib/docker/containers/ID (ID — уникальный идентификатор контейнера). Если контейнер использует драйвер логгирования по умолчанию, все логи будут сохранены в файле JSON внутри нее. Создание слишком большого количества логов может повлиять на файловую систему хост-машины.
Папка в /var/lib/docker/overlay2 , содержащая слой чтения-записи контейнера (overlay2 является предпочтительным драйвером хранилища в большинстве дистрибутивов Linux). Если контейнер сохраняет данные в своей собственной файловой системе, они будут храниться в /var/lib/docker/overlay2 на хост-машине.

Представим, что у нас есть совершенно новая система, в которой только что был установлен Docker.

Во-первых, запустим контейнер NGINX:

Снова запустив команду df , мы увидим:

один образ размером 126 Мбайт. Его загрузил NGINX: 1.16, когда мы запустили контейнер;
контейнер www, запускающийся из образа NGINX.

Этот файл создается в слое чтения-записи, связанном с этим контейнером. Если мы снова проверим вывод команды df , то увидим, что он теперь занимает некоторое дополнительное дисковое пространство.

Где находится этот файл на хосте? Проверим:

Подкоманда prune , которую мы применяли выше, удаляет остановленные контейнеры. Если нам нужно удалить все — и запущенные, и остановленные, мы можем использовать одну из следующих команд (обе эквивалентны):

Использование диска образами

Существует несколько видов образов, которые не видны напрямую конечному пользователю:

Промежуточные — те, что ссылаются на другие (дочерние) и не могут быть удалены.
Висящие — это те, на которые больше нет ссылок. Они занимают некоторое место на диске и могут быть удалены.

Следующие команды отображают висящие образы в системе:

Чтобы удалить их, можно пойти долгим путем:

$ docker image rm $(docker image ls -f dangling=true -q)

Или использовать подкоманду prune :

В случае, если нужно удалить все образы сразу (а не только висящие), можно запустить следующую команду. Однако это не позволит удалить те, которые используются контейнером в данный момент:

Использование диска томами

Тома используются для хранения данных вне файловой системы контейнера. Например, когда контейнер запускает приложение с сохранением состояния, данные должны оставаться за его пределами и быть отделены от его жизненного цикла. Тома также используются потому, что тяжелые операции файловой системы внутри контейнера плохо влияют на производительность.

Допустим, мы запускаем контейнер на основе MongoDB, а затем используем его для тестирования бэкапа, который мы сделали ранее (он доступен локально в файле bck.json):

Данные в файле бэкапа будут храниться на хосте в папке /var/lib/docker/volumes . Почему эти данные не сохраняются в слое контейнера? Причина в том, что в Dockerfile образа mongo расположение /data/db (где mongo хранит свои данные по умолчанию) определяется как том.

Извлечение Dockerfile, используемого для сборки образа контейнера MongoDB

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

Окончив тестирование бэкапа, мы останавливаем или удаляем контейнер. Однако том не удаляется, если мы не сделаем этого явно — он остается, потребляя дисковое пространство. Тогда мы можем пойти долгим путем:

Или использовать prune :

Использование диска кэшем сборки

В релизе Docker 18.09 представлены усовершенствования процесса сборки с помощью BuildKit. Использование этого инструмента позволяет повысить производительность, управление хранилищем, функциональность и безопасность. Мы не будем подробно его описывать, а просто посмотрим, как его включить и как он влияет на использование диска.

Рассмотрим следующее фиктивное приложение Node.Js и связанный с ним Dockerfile :

Dockerfile определяет, как построить образ из приведенного выше кода:

Создадим образ как обычно и без включенного BuildKit:

Теперь соберем версию образа 2.0 с BuildKit. Нужно просто установить DOCKER_BUILDKIT в 1:

При повторной проверке использования диска видим, что был создан кэш сборки (Build Cache):

Для его удаления можно выполнить:

Очистка всего и сразу

Выполнение этой команды время от времени для очистки диска — хорошая привычка.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Docker Tips: Clean Up Your Local Machine" автора Luc Juggery.

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

Общее потребление

Docker – крутая штука, наверное сегодня мало кто в этом сомневается. Всего несколько лет назад этот продукт предоставил нам совершенно новый способ построения, доставки и запуска любого окружения, позволяя значительно сэкономить ресурсы процессора и оперативной памяти. В дополнение к этому (а для кого-то это будет даже самым важным) Docker позволил нам невероятно упростить и унифицировать управление жизненным циклом используемых рабочих сред.

Однако, за все эти прелести современной жизни приходится платить. Когда мы запускаем контейнеры, скачиваем или создаем собственные образы, разворачиваем сложные экосистемы, нам приходится платить. И платим мы, в том числе, дисковым пространством.

Если вы никогда не задумывались о том, сколько же места реально занято на вашей машине Docker’ом, то можете быть неприятно удивлены выводом этой команды:

Здесь отображено использование диска Docker’ом в различных разрезах:

образы (images) – общий размер образов, которые были скачаны из хранилищ образов и построены в вашей системе;
контейнеры (containers) – общий объем дискового пространства, используемый запущенными контейнерами (имеется ввиду общий объем слоев чтения-записи всех контейнеров);
локальные тома (local volumes) – объем локальных хранилищ, примонтированных к контейнерам;
кэш сборки (build cache) – временные файлы, сгенерированные процессом построения образов (при использовании инструмента BuildKit, доступного начиная с Docker версии 18.09).

Готов поспорить, что уже после этого простого перечисления вы горите желанием почистить диск от мусора и вернуть к жизни драгоценные гигабайты (прим. перев.: особенно, если за эти гигабайты вы ежемесячно перечисляете арендную плату).

Использование диска контейнерами

Каждый раз при создании контейнера на хостовой машине в каталоге /var/lib/docker создается несколько файлов и каталогов, среди которых стоит отметить следующие:

Каталог /var/lib/docker/containers/ID_контейнера – при использовании стандартного драйвера логгирования именно сюда сохраняются журналы событий в JSON-формате. Слишком подробные логи, а также логи, которые никто не читает и не обрабатывает иными способами, часто становятся причиной переполнения дисков.
Каталог /var/lib/docker/overlay2 – содержит слои чтения-записи контейнеров (overlay2 – предпочитаемые драйвер в большинстве дистрибутивов Linux). Если контейнер сохраняет данные в своей файловой системе, то именно в этом каталоге они и будут размещены.

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

Запустим какой-нибудь контейнер, например, NGINX:

Что происходит с диском:

образы (images) занимают 126 Мб, это тот самый NGINX, который мы запустили в контейнере;
контейнеры (containers) занимают смешные 2 байта.

Судя по выводу, у нас еще нет пространства, которое мы могли бы высвободить. Так как 2 байта это совершенно несерьезно, давайте представим, что наш NGINX неожиданно для всех написал куда-то 100 Мегабайт данных и создал внутри себя файл test.img именно такого размера.

Снова исследуем использование дискового пространства на хосте. Мы увидим, что контейнер (containers) занимает там 100 Мегабайт.

Думаю, ваш пытливый мозг уже задается вопросом, где же находится наш файл test.img. Давайте его поищем:

Не вдаваясь в подробности можно отметить, что файл test.img удобно расположился на уровне чтения-записи, управляемом драйвером overlay2. Если же мы остановим наш контейнер, то хост подскажет нам, что это место, в принципе, можно высвободить:

Как мы можем это сделать? Удалением контейнера, которое повлечет за собой очистку соответствующего пространства на уровне чтения-записи.

С помощью следующей команды вы можете удалить все установленные контейнеры одним махом и очистить ваш диск от всех созданных ими на уровне чтения-записи файлов:

Итак, мы высвободили 104,9 Мегабайта удалением контейнера. Но так как мы уже не используем скачанный ранее образ, то он тоже становится кандидатом на удаление и высвобождение наших ресурсов:

Внимание: до тех пор, пока образ используется хотя бы одним контейнером, вы не сможете использовать этот трюк.

Субкоманда prune, которую мы использовали выше, дает эффект только на остановленных контейнерах. Если мы хотим удалить не только остановленные, но и запущенные контейнеры, следует использовать одну из этих команд:

Заметки на полях: если при запуске контейнера использовать параметр --rm, то при его остановке будут высвобождено все дисковое пространство, которое он занимал.

Использование диска образами

Есть несколько типов образов, которые напрямую не видны конечному пользователю:

intermediate образы, на основе которых собраны другие образы в – они не могут быть удалены, если вы используете контейнеры на базе этих самых «других» образов;
dangling образы – это такие intermediate образы, на которые не ссылается ни один из запущенных контейнеров – они могут быть удалены.
С помощью следующей команды вы можете проверить наличие в вашей системе dangling образов:

Удалить их можно следующим способом:

Мы можем использовать также субкоманду prune:

Если мы вдруг захотим удалить вообще все образы (а не только dangling) одной командой, то можно сделать так:

Использование диска томами

Тома (volumes) применяются для хранения данных за пределами файловой системы контейнера. Например, если мы хотим сохранить результаты работы какого-либо приложения, чтобы использовать их как-то еще. Частым примером являются базы данных.

Давайте запустим контейнер MongoDB, примонтируем к нему внешний по отношению к контейнеру том, и восстановим из него бэкап базы данных (у нас он доступен в файле bck.json):

Данные будут находиться на хостовой машине в каталоге /var/lib/docker/volumes. Но почему не на уровне чтения-записи контейнера? Потому что в Dockerfile образа MongoDB каталог /data/db (в котором MongoDB по умолчанию хранит свои данные) определен как том (volume).

Заметки на полях: многие образы, в результате работы которых должны создаваться данные, используют тома (volumes) для сохранения этих самых данных.

Когда мы наиграемся с MongoDB и остановим (а может даже и удалим) контейнер, том не будет удален. Он продолжит занимать наше драгоценное дисковое пространство до тех пор, пока мы явно не удалим его такой командой:

Ну или мы можем использовать уже знакомую нам субкоманду prune:

Использование диска для кэша сборки образов

В Docker 18.09 процесс создания образов претерпел некоторые изменения благодаря инструменту BuildKit. С помощью этой штуки увеличивается скорость процесса, оптимизируется управление хранением данных и безопасностью. Здесь мы не будем рассматривать все детали этого замечательного инструмента, остановимся лишь нам том, как он затрагивает вопросы использования дискового пространства.

Предположим, что у нас есть совершенно простое приложение Node.Js:

Dockerfile для сборки образа выглядит так:

Давайте соберем образ обычным способом, без использования BuildKit:

Если мы проверим использование дискового пространства, то увидим, что место занимают только базовый образ (node:13-alpine) и конечный образ (app:1.0):

Давайте соберем вторую версию нашего приложения, уже с использованием BuildKit. Для этого нам лишь необходимо установить переменную DOCKER_BUILDKIT в значение 1:

Если мы сейчас проверим использование диска, то увидим, что теперь там участвует кэш сборки (buid-cache):

Для его очистки воспользуемся следующей командой:

Очистить все!

Итак, мы рассмотрели очистку дискового пространства, занятого контейнерами, образами и томами. В этом нам помогает субкоманда prune. Но ее можно использовать и на системном уровне docker, и она очистит все, что только сможет:

Если вы по каким-либо причинам экономите дисковое пространство на машине с Docker, то периодический запуск этой команды стоит ввести в привычку.

Когда я впервые начал использовать docker, он меня поразил. Уверен, что и вы испытали нечто подобное. Время шло, а docker не переставал меня удивлять. Например, однажды он занял все свободное место на диске. Пока я останавливал и запускал контейнеры, скачивал классные штуки с docker hub, гигабайты быстро таяли, заполняясь висячими (dangling) томами, остановленными контейнерами и ненужными образами.

Запомнить их довольно сложно, и я поместил эти команды в скрипт. В общем, для очистки можно использовать специальные контейнеры, например docker-gc от spotify, или запомнить команды (да, я знаю: когда разберешься с функциями команд, они запомнятся сами собой). Однако вы можете не захотеть выполнять все эти процедуры для очистки docker-окружения.

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

Использование базовой команды docker system

Осмотр docker-окружения

Команда docker system df выдает подробную статистику о контейнерах, образах и томах. Она также сообщает, сколько места можно освободить, выполнив очистку.

docker system df

Подробная информация о docker-окружении, полученная с помощью docker system df -v

Верните себе драгоценное пространство

Очистить систему можно с помощью команды docker system prune. По умолчанию будут удалены остановленные контейнеры, висячие образы (слои, не связанные с используемыми образами), тома и сети, не относящиеся к работающим контейнерам. Опция -a позволяет удалить не только висячие, но и вообще все неиспользуемые образы (не ассоциированные с запущенными контейнерами). Опция -f подавляет запросы на подтверждения. Обе опции по умолчанию выключены.

docker system prune

Удаляем неиспользуемые образы с помощью docker system prune -a

Команда prune полезна в том случае, когда нужно удалить только висячие образы и остановленные контейнеры. Выполнив docker image prune, docker container prune, вы избавитесь от ненужных образов и контейнеров.

Удаляем все ненужные контейнеры с помощью docker container prune

Удаляем все ненужные образы с помощью docker image prune

Подытожим: приведенные ниже команды (с опциями и вариациями) помогут освободить место на диске:

Надеюсь, теперь и у вас есть набор простых команд, которые позволят с легкостью вернуть утраченное дисковое пространство. Спасибо за внимание.

И ещё одна интересная выжимка фактов о докере, которая поможет в кратчайшие сроки начать его продуктивное использование. Цель данной статьи…

В продолжение прошлой статьи рассмотрим пример настройки ротации логов контейнеров на примере CentOs 7. В моём случае stdout и stderr контейнеров…

С недавнего времени начал рассматривать переход с lxc-контейнеров под управлением Proxmox на более гибкий Docker, в основе которого лежат те…

Читайте также: