У меня есть несколько док-контейнеров, работающих на AWS EC2, папка / var / lib / docker / overlay2 очень быстро увеличивается в размере диска.
Мне интересно, безопасно ли удалять его содержимое? или если в докере есть какая-то команда, чтобы освободить место на диске.
ОБНОВИТЬ:
На самом деле я docker system prune -a
уже пробовал , что восстановило 0Kb.
Также размер моего диска / docker / overlay2 намного больше, чем вывод из docker system df
После прочтения документации докеров и ответа BMitch я считаю, что трогать эту папку - глупая идея, и я попробую другие способы освободить место на диске.
docker
docker-compose
docker-machine
qichao_he
источник
источник
docker image prune --all
и тогдаdocker system prune -a
. Он освободил мое дисковое пространство примерно на 50 ГБ, которое использовалось файлами в / var / lib / docker / overlay2. Ноdocker system prune -a
этого было бы достаточно. Кроме того , мои особенности конфигурации:OS: Ubuntu 20
,Docker : 19.03.12
Ответы:
Docker использует / var / lib / docker для хранения ваших образов, контейнеров и локальных именованных томов. Удаление этого может привести к потере данных и, возможно, остановить двигатель. Подкаталог overlay2, в частности, содержит различные уровни файловой системы для изображений и контейнеров.
Чтобы очистить неиспользуемые контейнеры и образы, см
docker system prune
.. Также есть варианты удаления томов и даже изображений с тегами, но они не включены по умолчанию из-за возможности потери данных.источник
docker system prune -a
, что восстановило 0кб места. Прямо сейчас для меня дело в том, что размер диска / docker / overlay2 намного больше, чем вывод изdocker system df
. Вот почему я продолжаю копаться в этой проблеме. Еще раз спасибо за ваш ответ, сэр. Думаю, мне нужно больше узнать о документации докера или, возможно, полностью стереть докер и перезапустить его. Мне нужно сохранить только базу данных postgres, и я смонтировал ее/var/lib/docker
а не один подкаталог, который оставит его в несогласованном состоянии.Я обнаружил, что это работает лучше всего для меня:
По умолчанию Docker не удаляет именованные изображения, даже если они не используются. Эта команда удалит неиспользуемые изображения.
Обратите внимание, что каждый слой изображения представляет собой папку внутри
/usr/lib/docker/overlay2/
папки.источник
docker system df
показано (возможно, у вас все еще нет места, и эту злуюoverlay2
свалку мусора нужно уничтожить вручную.У меня была эта проблема ... Это был огромный журнал. Журналы здесь:
Вы можете управлять этим в командной строке запуска или в файле создания. Смотрите там: Настройка драйверов ведения журнала
Я лично добавил эти 3 строки в свой файл docker-compose.yml:
источник
overlay2
. В моем случае, общая емкость для/var/lib/docker
была 50GB и 36GB из него был поглощен одним файлом:/var/lib/docker/overlay2/<container id>/diff/var/log/faillog
. Исходя из предположения, что этот файл не является центральным для поддержания всего работоспособности, мой краткосрочный совет - просто удалить его (и, возможно, я также откорректирую свойdocker-compose
).также были проблемы с быстрорастущими
overlay2
/var/lib/docker/overlay2
- это папка, в которой докеры хранят записываемые слои для вашего контейнера.docker system prune -a
- может работать, только если контейнер остановлен и снят.в моем случае я смог выяснить, что занимает пространство, изучив его
overlay2
.эта папка содержит другие папки с хеш-именами. у каждого из них есть несколько папок, включая
diff
папку.diff
папка - содержит фактическую разницу, записанную контейнером с точной структурой папок в качестве вашего контейнера (по крайней мере, так было в моем случае - ubuntu 18 ...)поэтому я привык
du -hsc /var/lib/docker/overlay2/LONGHASHHHHHHH/diff/tmp
выяснять, что/tmp
внутри моего контейнера находится загрязненная папка .поэтому в качестве обходного пути я использовал
-v /tmp/container-data/tmp:/tmp
параметр дляdocker run
команды для сопоставления внутренней/tmp
папки с хостом и настройки cron на хосте для очистки этой папки.Задача cron была простой:
sudo nano /etc/crontab
*/30 * * * * root rm -rf /tmp/container-data/tmp/*
save and exit
ПРИМЕЧАНИЕ:
overlay2
это системная папка докеров, и они могут изменить ее структуру в любое время. Все вышесказанное основано на том, что я там видел. Пришлось войти в структуру папок докеров только потому, что в системе полностью не хватило места и даже не позволяло мне использовать ssh в контейнере докеров.источник
/var/log/apache2/error.log
. Я сбрасываю error.log и access.log и добавляю новый том, чтобыBackgroud
Вину за проблему можно разделить между неправильной конфигурацией томов контейнера и проблемой с утечкой (невозможностью освобождения) временных данных, записанных в эти тома докера. Мы должны сопоставить (либо с папками хоста, либо с другими требованиями к постоянному хранилищу) все временные папки / журналы / рабочие папки нашего контейнера, в которые наши приложения часто и / или часто пишут. Docker не несет ответственности за очистку всех автоматически создаваемых так называемых EmptyDirs, расположенных по умолчанию в
/var/lib/docker/overlay2/*/diff/*
. Содержимое этих "непостоянных" папок должно автоматически очищаться докером после остановки контейнера, но, по-видимому, этого не происходит (их может быть даже невозможно очистить со стороны хоста, если контейнер все еще работает - и он может работать в течение нескольких месяцев вовремя).Обходной путь
Обходной путь требует тщательной ручной очистки, и хотя он уже описан в другом месте, вы все же можете найти некоторые подсказки из моего тематического исследования, которое я попытался сделать как можно более поучительным и обобщаемым.
Итак, что случилось, так это то, что приложение-виновник (в моем случае
clair-scanner
) сумело записать за несколько месяцев сотни гигабайт данных во/diff/tmp
вложенную папку докера.overlay2
Так как все эти подпапки в
/diff/tmp
были довольно понятны (все имели формуclair-scanner-*
и устаревшие даты создания), я остановил связанный контейнер (docker stop clair
) и осторожно удалил эти устаревшие подпапкиdiff/tmp
, начиная с одной (самой старой), и тестирование влияния на движок докеров (которое потребовало перезапуска [systemctl restart docker
] для освобождения дискового пространства):Я освободил сотни гигабайт дискового пространства без необходимости переустанавливать докер или очищать все его папки. Все запущенные контейнеры должны были быть остановлены в какой-то момент, потому что для освобождения дискового пространства потребовался перезапуск демона докера, поэтому сначала убедитесь, что ваши отказоустойчивые контейнеры правильно работают на / другом узле / ах). Я бы хотел, чтобы
docker prune
команда также могла охватывать устаревшие/diff/tmp
(или даже/diff/*
) данные (с помощью еще одного переключателя).Этой проблеме уже 3 года, вы можете прочитать ее богатую и красочную историю на форумах Docker, где в 2019 году был предложен вариант, нацеленный на журналы приложений вышеуказанного решения, и, похоже, работал в нескольких настройках: https: // Forums.docker.com/t/some-way-to-clean-up-identify-contents-of-var-lib-docker-overlay/30604
источник
ВНИМАНИЕ: НЕ ИСПОЛЬЗУЙТЕ В ПРОИЗВОДСТВЕННОЙ СИСТЕМЕ
Хорошо, давайте сначала попробуем системную обрезку
Не так уж и здорово, вроде очистили несколько мегабайт. А теперь сойдем с ума:
Ницца! Просто помните, что это НЕ рекомендуется ни на одном сервере, кроме одноразового сервера. На этом этапе внутренняя база данных Docker не сможет найти ни одного из этих оверлеев, что может вызвать непредвиденные последствия.
источник
/var/lib/docker
каталога (пока демон остановлен и предполагается, что каталог не содержит специальных файловых систем для монтирования или чего-то подобного) на самом деле является действенным быстрым и грязным способом вернуться к исходной точке. Я не уверен, почему вы получаете все отрицательные голоса. Docker пытается самовосстанавливаться и распознает, когда вся надежда потеряна, и при/var/lib/docker
необходимости повторно инициализирует каталог.НЕ ДЕЛАЙТЕ ЭТОГО В ПРОИЗВОДСТВЕ
Ответ @ ravi-luthra технически работает, но у него есть некоторые проблемы!
В моем случае я просто пытался восстановить дисковое пространство.
lib/docker/overlay
Папка принимает 30GB пространства , и я только запустить несколько контейнеров на регулярной основе . Похоже, у докера есть проблема с утечкой данных, и некоторые временные данные не очищаются при остановке контейнера.Итак, я пошел дальше и удалил все содержимое
lib/docker/overlay
папки. После этого экземпляр My docker стал непригодным для использования. Когда я пытался запустить или построить какой-либо контейнер, я получил эту ошибку:Затем методом проб и ошибок я решил эту проблему, запустив
(ВНИМАНИЕ: это приведет к удалению всех ваших данных внутри томов докеров)
Поэтому не рекомендуется делать такую грязную очистку, если вы полностью не понимаете, как работает система.
источник
Все в / var / lib / docker - это файловые системы контейнеров. Если вы остановите все свои контейнеры и обрежете их, у вас должна получиться пустая папка. Вы, вероятно, действительно этого не хотите, поэтому не пытайтесь случайно удалить что-то там. Не удаляйте вещи в / var / lib / docker напрямую. Иногда это может сойти с рук, но по многим причинам это не рекомендуется.
Вместо этого сделайте это:
Вы увидите самые большие файлы, показанные внизу. Если хотите, выясните, в каких контейнерах находятся эти файлы, введите эти контейнеры
docker exec -ti containername -- /bin/sh
и удалите некоторые файлы.Вы также можете выполнять
docker system prune -a -f
ежедневную / еженедельную работу cron, если вы не оставляете остановленные контейнеры и тома вокруг, которые вам небезразличны. Лучше выяснить причины, по которым он растет, и исправить их на уровне контейнера.источник
У меня недавно была аналогичная проблема, overlay2 становился все больше и больше, но я не мог понять, что занимало большую часть пространства.
df
показал мне, что overlay2 имеет размер около 24 ГБ.С помощью
du
я попытался выяснить, что занимает это место… и потерпел неудачу.Разница заключалась в том, что удаленные файлы (в моем случае в основном файлы журналов) все еще используются процессом (Docker). Таким образом, файл не отображается,
du
но отображается пространство, которое он занимаетdf
.Помогла перезагрузка хост-машины. Перезапуск контейнера докеров, вероятно, уже помог бы… Эта статья на linuxquestions.org помогла мне понять это.
источник
добавление к приведенному выше комментарию, в котором люди предлагают сократить систему, например, очистить оборванные тома, изображения, выходные контейнеры и т. д. Иногда ваше приложение становится виновником, оно генерирует слишком много журналов за короткое время, и если вы используете пустой прямой том (локальные тома ) этим заполняем разделы / var. В этом случае мне показалось, что приведенная ниже команда очень интересна, чтобы выяснить, что занимает место на моем диске с разделом / var.
du -ahx / var / lib | sort -rh | голова -n 30
Эта команда выведет список из 30 первых, которые занимают больше всего места на одном диске. Это означает, что если вы используете внешнее хранилище с вашими контейнерами, выполнение команды du занимает много времени. Эта команда не будет считать подключенные тома. И намного быстрее. Вы получите точные каталоги / файлы, которые занимают место. Затем вы можете перейти в эти каталоги и проверить, какие файлы полезны или нет. если эти файлы требуются, вы можете переместить их в какое-либо постоянное хранилище, внеся изменения в приложение, чтобы использовать постоянное хранилище для этого местоположения, или изменив местоположение этих файлов. А для отдыха вы можете их очистить.
источник
Я использовал "docker system prune -a", он очистил все файлы под томами и оверлей2
источник