Безопасно ли чистить docker / overlay2 /

101

У меня есть несколько док-контейнеров, работающих на AWS EC2, папка / var / lib / docker / overlay2 очень быстро увеличивается в размере диска.

Мне интересно, безопасно ли удалять его содержимое? или если в докере есть какая-то команда, чтобы освободить место на диске.


ОБНОВИТЬ:

На самом деле я docker system prune -aуже пробовал , что восстановило 0Kb.

Также размер моего диска / docker / overlay2 намного больше, чем вывод из docker system df

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

qichao_he
источник
ты нашел на это ответ? У меня все еще та же проблема.
Saurabh_Jhingan,
1
Я побежал docker image prune --allи тогда docker system prune -a. Он освободил мое дисковое пространство примерно на 50 ГБ, которое использовалось файлами в / var / lib / docker / overlay2. Но docker system prune -aэтого было бы достаточно. Кроме того , мои особенности конфигурации: OS: Ubuntu 20,Docker : 19.03.12
Binita Бхарати

Ответы:

65

Docker использует / var / lib / docker для хранения ваших образов, контейнеров и локальных именованных томов. Удаление этого может привести к потере данных и, возможно, остановить двигатель. Подкаталог overlay2, в частности, содержит различные уровни файловой системы для изображений и контейнеров.

Чтобы очистить неиспользуемые контейнеры и образы, см docker system prune.. Также есть варианты удаления томов и даже изображений с тегами, но они не включены по умолчанию из-за возможности потери данных.

BMitch
источник
1
Ответ тот же (только тома можно исключить). Если вы удалите что-то внутри и сломаете его, вы получите обе части. Используйте инструменты, предусмотренные для этой работы.
BMitch
1
Папка overlay2 должна содержать слои файловой системы, необходимые для ваших изображений и контейнеров. Вы можете проигнорировать этот совет, но, пожалуйста, не спрашивайте у меня совета о том, как восстановить неисправную систему после того, как вы сломали ее, тем более что я дал вам поддерживаемый способ очистки вашей файловой системы.
BMitch
14
Я пробовал docker system prune -a, что восстановило 0кб места. Прямо сейчас для меня дело в том, что размер диска / docker / overlay2 намного больше, чем вывод из docker system df. Вот почему я продолжаю копаться в этой проблеме. Еще раз спасибо за ваш ответ, сэр. Думаю, мне нужно больше узнать о документации докера или, возможно, полностью стереть докер и перезапустить его. Мне нужно сохранить только базу данных postgres, и я смонтировал ее
qichao_he
8
Скажу, что «поддерживаемый» способ у меня тоже не работает. Выполнение всей системы docker prune -a, удаления docker volume, docker image prune и docker container prune оставляет мне 80% моего диска, используемого Docker. Это со всеми остановленными контейнерами.
Крейг Бретт
1
@franzisk, чтобы очистить все, что вы хотите удалить, /var/lib/dockerа не один подкаталог, который оставит его в несогласованном состоянии.
BMitch
43

Я обнаружил, что это работает лучше всего для меня:

docker image prune --all

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

Обратите внимание, что каждый слой изображения представляет собой папку внутри /usr/lib/docker/overlay2/папки.

Сарке
источник
1
«обрезка изображения» работает намного лучше, чем «обрезка системы». Благодарность!
DavidG
Предупреждение! Это довольно разрушительно, поскольку удаляет все образы неработающих контейнеров. Вы будете перестраивать их часами, если они ваши и еще не добавлены в реестр. Но он по-прежнему не может выходить за рамки того, что docker system dfпоказано (возможно, у вас все еще нет места, и эту злую overlay2свалку мусора нужно уничтожить вручную.
mirekphd
Ну да, снимает изображения.
Сарке
Внимание: в моем случае, когда я использовал docker swarm, он также удалил все помеченные изображения, даже для запущенных контейнеров
velop
Это сработало, но покупатель, будьте осторожны, это удаляет ВСЕ, что не находится в контейнере.
Джим
28

У меня была эта проблема ... Это был огромный журнал. Журналы здесь:

/var/lib/docker/containers/<container id>/<container id>-json.log

Вы можете управлять этим в командной строке запуска или в файле создания. Смотрите там: Настройка драйверов ведения журнала

Я лично добавил эти 3 строки в свой файл docker-compose.yml:

my_container:
  logging:
    options:
      max-size: 10m
Тристан
источник
2
Можете добавить к ответу несколько строк из ссылки?
RTMY
Было бы неплохо также получить информацию о том, как определить, в каком контейнере находится гигантский файл журнала. У меня есть куча контейнеров и файлов журналов, некоторые из них огромные, некоторые крошечные.
Мика Золту
Как это отвечает на вопрос ОП ?!
Славик Мельцер
2
Этот ответ является частичным, особенно если проблема заключалась в «журналах» (может быть, мы сможем улучшить его с помощью некоторых правок?). Пока я не увидел этот ответ, я собирался начать случайное удаление больших каталогов из моего переполненного overlay2. В моем случае, общая емкость для /var/lib/dockerбыла 50GB и 36GB из него был поглощен одним файлом: /var/lib/docker/overlay2/<container id>/diff/var/log/faillog. Исходя из предположения, что этот файл не является центральным для поддержания всего работоспособности, мой краткосрочный совет - просто удалить его (и, возможно, я также откорректирую свой docker-compose).
Д. Вудс
18

также были проблемы с быстрорастущими 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 в контейнере докеров.

user2932688
источник
Спасибо за этот ответ, мы поместили в контейнеры старую базу данных / приложение, которые генерируют много файлов /var/log/apache2/error.log. Я сбрасываю error.log и access.log и добавляю новый том, чтобы
упростить
5

Backgroud

Вину за проблему можно разделить между неправильной конфигурацией томов контейнера и проблемой с утечкой (невозможностью освобождения) временных данных, записанных в эти тома докера. Мы должны сопоставить (либо с папками хоста, либо с другими требованиями к постоянному хранилищу) все временные папки / журналы / рабочие папки нашего контейнера, в которые наши приложения часто и / или часто пишут. Docker не несет ответственности за очистку всех автоматически создаваемых так называемых EmptyDirs, расположенных по умолчанию в /var/lib/docker/overlay2/*/diff/*. Содержимое этих "непостоянных" папок должно автоматически очищаться докером после остановки контейнера, но, по-видимому, этого не происходит (их может быть даже невозможно очистить со стороны хоста, если контейнер все еще работает - и он может работать в течение нескольких месяцев вовремя).

Обходной путь

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

Итак, что случилось, так это то, что приложение-виновник (в моем случае clair-scanner) сумело записать за несколько месяцев сотни гигабайт данных во /diff/tmpвложенную папку докера.overlay2

du -sch /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp

271G total

Так как все эти подпапки в /diff/tmpбыли довольно понятны (все имели форму clair-scanner-*и устаревшие даты создания), я остановил связанный контейнер ( docker stop clair) и осторожно удалил эти устаревшие подпапки diff/tmp, начиная с одной (самой старой), и тестирование влияния на движок докеров (которое потребовало перезапуска [ systemctl restart docker] для освобождения дискового пространства):

rm -rf $(ls -at /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp | grep clair-scanner | tail -1)

Я освободил сотни гигабайт дискового пространства без необходимости переустанавливать докер или очищать все его папки. Все запущенные контейнеры должны были быть остановлены в какой-то момент, потому что для освобождения дискового пространства потребовался перезапуск демона докера, поэтому сначала убедитесь, что ваши отказоустойчивые контейнеры правильно работают на / другом узле / ах). Я бы хотел, чтобы 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

Mirekphd
источник
4

ВНИМАНИЕ: НЕ ИСПОЛЬЗУЙТЕ В ПРОИЗВОДСТВЕННОЙ СИСТЕМЕ

/# df
...
/dev/xvda1      51467016 39384516   9886300  80% /
...

Хорошо, давайте сначала попробуем системную обрезку

#/ docker system prune --volumes
...
/# df
...
/dev/xvda1      51467016 38613596  10657220  79% /
...

Не так уж и здорово, вроде очистили несколько мегабайт. А теперь сойдем с ума:

/# sudo su
/# service docker stop
/# cd /var/lib/docker
/var/lib/docker# rm -rf *
/# service docker start
/var/lib/docker# df
...
/dev/xvda1      51467016 8086924  41183892  17% /
...

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

Рави Лутра
источник
Полное закрытие /var/lib/dockerкаталога (пока демон остановлен и предполагается, что каталог не содержит специальных файловых систем для монтирования или чего-то подобного) на самом деле является действенным быстрым и грязным способом вернуться к исходной точке. Я не уверен, почему вы получаете все отрицательные голоса. Docker пытается самовосстанавливаться и распознает, когда вся надежда потеряна, и при /var/lib/dockerнеобходимости повторно инициализирует каталог.
L0j1k
Господи, наконец, рабочий ответ. Я обрезал и делал что-то в течение 4 часов, но мне нужно было просто остановить службу докеров, положить все в корзину и перезапустить ее.
Оси,
2

НЕ ДЕЛАЙТЕ ЭТОГО В ПРОИЗВОДСТВЕ

Ответ @ ravi-luthra технически работает, но у него есть некоторые проблемы!

В моем случае я просто пытался восстановить дисковое пространство. lib/docker/overlayПапка принимает 30GB пространства , и я только запустить несколько контейнеров на регулярной основе . Похоже, у докера есть проблема с утечкой данных, и некоторые временные данные не очищаются при остановке контейнера.

Итак, я пошел дальше и удалил все содержимое lib/docker/overlayпапки. После этого экземпляр My docker стал непригодным для использования. Когда я пытался запустить или построить какой-либо контейнер, я получил эту ошибку:

failed to create rwlayer: symlink ../04578d9f8e428b693174c6eb9a80111c907724cc22129761ce14a4c8cb4f1d7c/diff /var/lib/docker/overlay2/l/C3F33OLORAASNIYB3ZDATH2HJ7: no such file or directory

Затем методом проб и ошибок я решил эту проблему, запустив

(ВНИМАНИЕ: это приведет к удалению всех ваших данных внутри томов докеров)

docker system prune --volumes -a

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

Шанкар Тьягараджан
источник
1

Все в / var / lib / docker - это файловые системы контейнеров. Если вы остановите все свои контейнеры и обрежете их, у вас должна получиться пустая папка. Вы, вероятно, действительно этого не хотите, поэтому не пытайтесь случайно удалить что-то там. Не удаляйте вещи в / var / lib / docker напрямую. Иногда это может сойти с рук, но по многим причинам это не рекомендуется.

Вместо этого сделайте это:

sudo bash
cd /var/lib/docker
find . -type f | xargs du -b  | sort -n

Вы увидите самые большие файлы, показанные внизу. Если хотите, выясните, в каких контейнерах находятся эти файлы, введите эти контейнеры docker exec -ti containername -- /bin/shи удалите некоторые файлы.

Вы также можете выполнять docker system prune -a -fежедневную / еженедельную работу cron, если вы не оставляете остановленные контейнеры и тома вокруг, которые вам небезразличны. Лучше выяснить причины, по которым он растет, и исправить их на уровне контейнера.

Джейсон Хьюз
источник
0

У меня недавно была аналогичная проблема, overlay2 становился все больше и больше, но я не мог понять, что занимало большую часть пространства.

df показал мне, что overlay2 имеет размер около 24 ГБ.

С помощью duя попытался выяснить, что занимает это место… и потерпел неудачу.

Разница заключалась в том, что удаленные файлы (в моем случае в основном файлы журналов) все еще используются процессом (Docker). Таким образом, файл не отображается, duно отображается пространство, которое он занимает df.

Помогла перезагрузка хост-машины. Перезапуск контейнера докеров, вероятно, уже помог бы… Эта статья на linuxquestions.org помогла мне понять это.

mhe
источник
0

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

du -ahx / var / lib | sort -rh | голова -n 30

Эта команда выведет список из 30 первых, которые занимают больше всего места на одном диске. Это означает, что если вы используете внешнее хранилище с вашими контейнерами, выполнение команды du занимает много времени. Эта команда не будет считать подключенные тома. И намного быстрее. Вы получите точные каталоги / файлы, которые занимают место. Затем вы можете перейти в эти каталоги и проверить, какие файлы полезны или нет. если эти файлы требуются, вы можете переместить их в какое-либо постоянное хранилище, внеся изменения в приложение, чтобы использовать постоянное хранилище для этого местоположения, или изменив местоположение этих файлов. А для отдыха вы можете их очистить.

Амит Бондвал
источник
-5

Я использовал "docker system prune -a", он очистил все файлы под томами и оверлей2

    [root@jasontest volumes]# docker system prune -a
    WARNING! This will remove:
            - all stopped containers
            - all networks not used by at least one container
            - all images without at least one container associated to them
            - all build cache
    Are you sure you want to continue? [y/N] y
    Deleted Images:
    untagged: ubuntu:12.04
    untagged: ubuntu@sha256:18305429afa14ea462f810146ba44d4363ae76e4c8dfc38288cf73aa07485005
    deleted: sha256:5b117edd0b767986092e9f721ba2364951b0a271f53f1f41aff9dd1861c2d4fe
    deleted: sha256:8c7f3d7534c80107e3a4155989c3be30b431624c61973d142822b12b0001ece8
    deleted: sha256:969d5a4e73ab4e4b89222136eeef2b09e711653b38266ef99d4e7a1f6ea984f4
    deleted: sha256:871522beabc173098da87018264cf3e63481628c5080bd728b90f268793d9840
    deleted: sha256:f13e8e542cae571644e2f4af25668fadfe094c0854176a725ebf4fdec7dae981
    deleted: sha256:58bcc73dcf4050a4955916a0dcb7e5f9c331bf547d31e22052f1b5fa16cf63f8
    untagged: osixia/openldap:1.2.1
    untagged: osixia/openldap@sha256:6ceb347feb37d421fcabd80f73e3dc6578022d59220cab717172ea69c38582ec
    deleted: sha256:a562f6fd60c7ef2adbea30d6271af8058c859804b2f36c270055344739c06d64
    deleted: sha256:90efa8a88d923fb1723bea8f1082d4741b588f7fbcf3359f38e8583efa53827d
    deleted: sha256:8d77930b93c88d2cdfdab0880f3f0b6b8be191c23b04c61fa1a6960cbeef3fe6
    deleted: sha256:dd9f76264bf3efd36f11c6231a0e1801c80d6b4ca698cd6fa2ff66dbd44c3683
    deleted: sha256:00efc4fb5e8a8e3ce0cb0047e4c697646c88b68388221a6bd7aa697529267554
    deleted: sha256:e64e6259fd63679a3b9ac25728f250c3afe49dbe457a1a80550b7f1ccf68458a
    deleted: sha256:da7d34d626d2758a01afe816a9434e85dffbafbd96eb04b62ec69029dae9665d
    deleted: sha256:b132dace06fa7e22346de5ca1ae0c2bf9acfb49fe9dbec4290a127b80380fe5a
    deleted: sha256:d626a8ad97a1f9c1f2c4db3814751ada64f60aed927764a3f994fcd88363b659
    untagged: centos:centos7
    untagged: centos@sha256:2671f7a3eea36ce43609e9fe7435ade83094291055f1c96d9d1d1d7c0b986a5d
    deleted: sha256:ff426288ea903fcf8d91aca97460c613348f7a27195606b45f19ae91776ca23d
    deleted: sha256:e15afa4858b655f8a5da4c4a41e05b908229f6fab8543434db79207478511ff7

    Total reclaimed space: 533.3MB
    [root@jasontest volumes]# ls -alth
    total 32K
    -rw-------  1 root root  32K May 23 21:14 metadata.db
    drwx------  2 root root 4.0K May 23 21:14 .
    drwx--x--x 14 root root 4.0K May 21 20:26 ..
user1681424
источник
3
Эта команда не дает ответа на вопрос. Предлагаемая команда даже написана в тексте вопроса ..
MBT
так что за этот ответ проголосовали в прах, но за тот же точный ответ ниже проголосовали 41 раз. Этот сайт не работает.
Адам Захран,