Всё /var/lib/docker пожрал … docker

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

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

Как мне кажется, получилось довольно смешно. Всё написанное в статье выдумка, любые совпадения с реальным миром случайны, если вы вводите в консоль sudo или его аналог - вы делаете это на свой страх и риск. Слова, замененные на другие для соблюдения правил Хабра, выделил курсивом, но думаю всё поймут, что было в оригинале написано.

Без sudo 🏝️

docker system df - общая инфа по тому, сколько где памяти жрётся:

C sudo ⚠️

  1. sudo ncdu /var/lib/docker - чекнуть, что там такого пожрано. Всё ниже может иметь неопределённые последствия, но пока я с ними не встречалась;

  2. Если в /var/lib/docker/containers много Гб, то, скорее всего, дело в логах самого докера. Можно почистить всё через sudo sh -c "truncate -s 0 /var/lib/docker/containers/*/*-json.log";

  3. Огромная папка /var/lib/docker/overlay2. Есть подозрение, что тут неверно считает размер, но факт, что туда набивается лишнего.

  4. Особое внимание стоит обратить на diff - там иногда забивается /tmp/ директория и прочее, что не лежит в файловой системе хоста. Можно прошерстить основные контейнеры и найти тот, который ссылается на эти папки, через docker container inspect --format '{{json .GraphDriver.Data }}' $айди_подозрительного_контейнера} | jq . и сказать а-та-та владельцу.

Если всё очень плохо, то остаётся только радикальное решение - рестарт докера и перезагрузка бокса.

@snakers4
01.02.2024 12:29 UTC
Первоисточник

Комментарии

@milssky
01.02.2024 08:25 UTC
0

Какая любовь к... лишнему :D

@akod67
01.02.2024 08:39 UTC
+5

Лайфхак - все контейнеры поднимать с чем-то вроде (в терминах ансибла)

  log_driver: json-file
  log_opt:
    max-file: "5"
    max-size: "10m"
@snakers4
01.02.2024 09:01 UTC
0

Для продовых сервисов маст

@werter_l
13.02.2024 15:37 UTC
0

И не в терминах ансибла )

cat /etc/docker/daemon.json

{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "5"
}
}

@ryanl
02.02.2024 03:49 UTC
+3

Радикальное решение через sudo - это rm -rf /var/lib/docker. Я так с перепугу удалил докер и его директорию, когда на лаптопе с 1TB-ым диском папка /var/lib/docker съела 737GB и система перестала грузиться.

@snakers4
03.02.2024 09:29 UTC
0

Не уверен кстати, что так можно делать без последствий.
Всё-таки лучше понять, что именно жрёт, и точечно удалять и самое главное, не допускать впредь, или высказать коллеге а-та-та.

@alex518
03.02.2024 19:22 UTC
+1

Я имел дело со следующим багом докера: если при импортировании образа выключить компьютер, то есть не дать докеру полностью загрузить и распаковать слой образа, то эти данные остануться лежать в /var/lib/docker/overlay2 мёртвым грузом и они даже не удаляются командой prune, докер просто не видит недоимпортированный слой.

@AMK83
04.02.2024 07:06 UTC
+2

Написано с юмором, читается легко и интересно :) Что-то для себя узнал новое. Автору конечно благодарность!

@snakers4
04.02.2024 07:07 UTC
0

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

@Psychosynthesis
14.03.2025 15:34 UTC
0

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

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

Он (докер) ещё и в логи гадит, кстати, но их чистить хотя бы понятно как.