Безопасно ли чистить докер /overlay2/

Question

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

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

Спасибо!

---

ОБНОВИТЬ:

Я действительно пытался docker system prune -a уже, который исправил 0Kb.

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

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

Answer 1

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

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

Answer 2

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

docker image prune --all

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

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

Answer 3

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

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

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

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

my_container:
  logging:
    options:
      max-size: 10m

Answer 4

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

Answer 5

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

      docker buildx prune --all

а также

      docker builder prune --all

Answer 6

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

Answer 7

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

• docker system prune -a && docker volume prune.

Answer 8

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

/# 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 не сможет найти ни одного из этих оверлеев, и это может привести к непредвиденным последствиям.

Answer 9

«Официальный» ответ, очистка с помощью « prune"команды, на самом деле не очищает мусор в папке.

Итак, чтобы ответить на исходный вопрос, что можно сделать:

Отказ от ответственности: будьте осторожны при применении этого. Это может привести к поломке вашего объекта Docker!

• Перечислите имена папок (хэши) в
• Проверьте свои объекты Docker (изображения, контейнеры и т. д.), которые вам нужны (остановленный контейнер или образ, который в данный момент не находится внутри какого-либо контейнера, не означает, что они вам не нужны).
• Когда вы проверите, вы увидите, что он дает вам хэши, связанные с вашим объектом, включая папки.
• Делать против папок
• Обратите внимание на все папки, найденные с помощью grep
• Теперь вы можете удалять папки, на которые не ссылается какой-либо объект Docker, который вам нужен.

Пример:

Допустим, в вашем каталоге есть эти папки,

      a1b28095041cc0a5ded909a20fed6dbfbcc08e1968fa265bc6f3abcc835378b5
021500fad32558a613122070616963c6644c6a57b2e1ed61cb6c32787a86f048

И у вас есть только одно изображение с идентификатором c777cf06a6e3.

Затем сделайте следующее:

      docker inspect c777cf06a6e3 | grep a1b2809
docker inspect c777cf06a6e3 | grep 021500

Представьте, что первая команда что-то нашла, а вторая ничего.

Затем вы можете удалить папку 0215... overlay2:

      rm -r 021500fad32558a613122070616963c6644c6a57b2e1ed61cb6c32787a86f048

Чтобы ответить на заголовок вопроса:

• Да, безопасно удалить папку dxirectly overlay2, если вы обнаружите, что она не используется.
• Нет, небезопасно удалять его напрямую, если вы обнаружите, что он используется, или вы не уверены.

Answer 10

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

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

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

Answer 11

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

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

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

Итак, я удалил все содержимое 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

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

Answer 12

Основываясь на ответе user2536614 я написал следующий скрипт со счетчиками и индикаторами выполнения.

Однако с момента написания сценария я заметил, что дополнительные каталоги на наших серверах сборки являются временными — то есть Docker, похоже, очищается, хотя и медленно. Я не знаю, расстроится ли Докер, если возникнет конфликт за удаление каталогов. Наше текущее решение — использовать документ с большими дополнительными накладными расходами (150+ ГБ).

      #!/bin/bash
[[ $(id -u) -eq 0 ]] || exec sudo /bin/bash -c "$(printf '%q ' "$BASH_SOURCE" "$@")"
progname=$(basename $0)
quiet=false
no_dry_run=false
while getopts ":qn" opt
do
    case "$opt" in
      q)
          quiet=true
          ;;
      n)
          no_dry_run=true
          ;;
      ?)
          echo "unexpected option ${opt}"
          echo "usage: ${progname} [-q|--quiet]"
          echo "    -q: no output"
          echo "    -n: no dry run (will remove unused directories)"
          exit 1
          ;;
    esac
done
shift "$(($OPTIND -1))"

[[ ${quiet} = false ]] || exec /bin/bash -c "$(printf '%q ' "$BASH_SOURCE" "$@")" > /dev/null

echo "Running as: $(id -un)"

progress_bar() {
    local w=80 p=$1;  shift
    # create a string of spaces, then change them to dots
    printf -v dots "%*s" "$(( $p*$w/100 ))" ""; dots=${dots// /.};
    # print those dots on a fixed-width space plus the percentage etc.
    printf "\r\e[K|%-*s| %3d %% %s" "$w" "$dots" "$p" "$*";
}

cd /var/lib/docker/overlay2
echo cleaning in ${PWD}
i=1
spi=1
sp="/-\|"
directories=( $(find . -mindepth 1 -maxdepth 1 -type d | cut -d/ -f2) )
images=( $(docker image ls --all --format "{{.ID}}") )
total=$((${#directories[@]} * ${#images[@]}))
used=()
for d in "${directories[@]}"
do
    for id in ${images[@]}
    do
        ((++i))
        progress_bar "$(( ${i} * 100 / ${total}))" "scanning for used directories ${sp:spi++%${#sp}:1} "
        docker inspect $id | grep -q $d
        if [ $? ]
        then
            used+=("$d")
            i=$(( $i + $(( ${#images[@]} - $(( $i % ${#images[@]} )) )) ))
            break
        fi
    done
done
echo -e "\b\b " # get rid of spinner
i=1
used=($(printf '%s\n' "${used[@]}" | sort -u))
unused=( $(find . -mindepth 1 -maxdepth 1 -type d | cut -d/ -f2) )
for d in "${used[@]}"
do
    ((++i))
    progress_bar "$(( ${i} * 100 / ${#used[@]}))" "scanning for unused directories ${sp:spi++%${#sp}:1} "
    for uni in "${!unused[@]}"
    do
        if [[ ${unused[uni]} = $d ]]
        then
            unset 'unused[uni]'
            break;
        fi
    done
done
echo -e "\b\b " # get rid of spinner
if [ ${#unused[@]} -gt 0 ]
then
    [[ ${no_dry_run} = true ]] || echo "Could remove:  (to automatically remove, use the -n, "'"'"no-dry-run"'"'" flag)"
    for d in "${unused[@]}"
    do
        if [[ ${no_dry_run} = true ]]
        then
            echo "Removing $(realpath ${d})"
            rm -rf ${d}
        else
            echo " $(realpath ${d})"
        fi
    done
    echo Done
else
    echo "All directories are used, nothing to clean up."
fi

Answer 13

Я перешел к папке, содержащей overlay2. Используя , я обнаружил, что в файле overlay2 было 25 ГБ мусора. Бегdocker system prune -afсказалTotal Reclaimed Space: 1.687MB, поэтому я подумал, что он не смог его очистить. Тем не менее, я тогда побежалdu -shc overlay2/*снова только для того, чтобы увидеть, что в overlay2 было всего 80 КБ, так что это сработало.

Будьте осторожны, докер врёт :).

Answer 14

Для меня обрезка изображения и объема не сработала.

Сначала проверьте использование дискового пространства. Вы можете ретранслировать на ncdu; лучший интерфейс утилиты дискового пространства, который я могу найти. Он отобразит занятое пространство в каталоге и множество полезных встроенных элементов управления для управления файловой системой. Это даст вам четкое представление о том, какой конкретный процесс и каталог занимает больше памяти.

      sudo ncdu -x /var 

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

      docker volume rm $(docker volume ls -qf dangling=true)

Также в качестве стандартной практики ограничиваются журналы контейнеров. По умолчанию Docker будет хранить журналы контейнера неопределенно долго. Вы можете ограничить объем дискового пространства, используемого журналами контейнера, установив ограничение в файле конфигурации демона Docker (/etc/docker/daemon.json). Например, вы можете добавить следующую строку, чтобы ограничить размер журналов контейнера 50 МБ. Если файла daemon.json нет, вы можете добавить его.

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

После внесения изменений в файл конфигурации демона вам необходимо перезапустить демон Docker с помощью команды sudo service docker restart.

Answer 15

В моем случае,systemctl stop dockerзатемsystemctl start dockerкак-то автоматически освобождается место/var/lib/docker/*

Answer 16

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

Answer 17

У меня была та же проблема, в моем случае это было потому, что каталог var/lib/docker был смонтирован в работающий контейнер (в моем случае google/cadvisor), поэтому он заблокировал очистку папки docker prune. Остановка контейнера, запуск docker prune и повторный запуск контейнера решили проблему.

Answer 18

Причина, по которой каталог overlay2 заполнен, заключается в том, что в одном из контейнеров есть записи журнала. По крайней мере, так было с моим докером. Docker Stop and Start решает эту проблему, но это временное решение. Вы либо закроете логи, либо контейнеры будут перезапускаться каждый день.

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

      du -sh /var/lib/docker/containers/*

Answer 19

Docker, по-видимому, хранит слои образов старых версий образа для запуска контейнеров. Это может произойти, если вы обновите изображение работающего контейнера (тот же тег), не останавливая его, например:

      docker-compose pull
docker-compose up -d

Бег docker-compose down до того, как обновление решило проблему, в моем случае простои не были проблемой.

Answer 20

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

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

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

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

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

Answer 21

Возможно, эта папка не ваша проблема, не используйте результат df -hс докером. Используйте команду ниже, чтобы увидеть размер каждой из ваших папок:

      echo; pwd; echo; ls -AlhF; echo; du -h --max-depth=1; echo; du-sh

Answer 22

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

      sudo systemctl stop docker
sudo rm -r /var/lib/docker/overlay2
sudo mkdir /var/lib/docker/overlay2
sudo systemctl start docker

Answer 23

      docker system prune -af && docker image prune -af

Answer 24

Я использовал "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 ..