Чи безпечно чистити докер / overlay2 /

Я отримав кілька контейнерів докерів, що працюють на AWS EC2, папка / var / lib / docker / overlay2 дуже швидко зростає в розмірі диска.

Цікаво, чи безпечно видаляти його вміст? або якщо докер має якусь команду, щоб звільнити певне використання диска.

ОНОВЛЕННЯ:

Насправді я docker system prune -aвже спробував , і я повернув 0 Кб.

Також розмір мого диска / docker / overlay2 набагато більший, ніж вихідний з docker system df

Прочитавши документацію докера та відповідь BMitch, я вважаю дурною ідеєю торкатися цієї папки, і я спробую інші способи повернути собі місце на диску.

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

Щоб очистити невикористані контейнери та зображення, див docker system prune. Існують також варіанти видалення томів і навіть зображень із тегами, але вони не ввімкнені за замовчуванням через можливість втрати даних.

Я виявив, що це найкраще для мене працює:

docker image prune --all

За замовчуванням Docker не видаляє іменовані зображення, навіть якщо вони не використовуються. Ця команда видалить невикористані зображення.

Зверніть увагу, що кожен шар на зображенні є папкою всередині /usr/lib/docker/overlay2/папки.

У мене була ця проблема ... Це журнал був величезним. Журнали знаходяться тут:

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

Ви можете керувати цим у командному рядку запуску або у файлі створення. Дивіться там: Налаштування драйверів реєстрації

Я особисто додав ці 3 рядки у свій файл docker-compose.yml:

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

також мали проблеми зі швидко зростаючим 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це папка системного докера, і вони можуть будь-коли змінити її структуру. Все вище базується на тому, що я там бачив. Довелося переходити у структуру папок docker лише тому, що системі повністю не вистачало місця і навіть не дозволяло мені ssh в контейнер docker.

Backgroud

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

Обхідний шлях

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

Отже, те, що сталося, - це програма-винуватець (у моєму випадку clair-scanner), яка за кілька місяців змогла записати сотні концертів даних у /diff/tmpпідпапку docker'soverlay2

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, тому переконайтеся, що спочатку ваші резервні контейнери працюють належним чином на / інших вузлах. Хоча я хотів би, щоб 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

ПОПЕРЕДЖЕННЯ: НЕ ВИКОРИСТОВУЙТЕ В СИСТЕМІ ВИРОБНИЦТВА

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

НЕ РОБІТЬ ЦЕ НА ВИРОБНИЦТВІ

Відповідь @ 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

Тому не рекомендується робити такі брудні очищення, якщо ви повністю не зрозуміли, як працює система.

Усе в / 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, якщо ви не залишаєте зупинені контейнери та обсяги навколо, які вам важливі. Краще з’ясувати причини, за якими вона зростає, та виправити їх на рівні контейнера.

Нещодавно у мене була подібна проблема, накладення2 ставало все більше і більше, але я не міг зрозуміти, що поглинає основну частину простору.

df показав мені, що overlay2 розміром близько 24 Гб.

З duЯ спробував з'ясувати , що займало простір ... і не вдалося.

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

Допомогло перезавантаження головного комп'ютера. Перезапуск контейнера докера, мабуть, вже допоміг би ... Ця стаття на linuxquestions.org допомогла мені це зрозуміти.

додавання до вищезазначеного коментаря, в якому люди пропонують обрізати систему, як чіткі звисаючі томи, зображення, контейнери виходу тощо. Коли-небудь ваш додаток стає винуватцем, він створює занадто багато журналів за короткий час, і якщо ви використовуєте порожній прямий том (локальні томи ) це заповнення розділів / var. У цьому випадку мені здалося, що команда нижче цікаво зрозуміти, що займає простір на моєму розділі диска / var.

du -ahx / var / lib | сортувати -rh | голова -н 30

Ця команда перелічить 30 найкращих, які займають найбільше місця на одному диску. Означає, що якщо ви використовуєте зовнішній накопичувач із своїми контейнерами, це забирає багато часу для запуску команди du. Ця команда не враховуватиме обсяги монтування. І набагато швидше. Ви отримаєте точні каталоги / файли, які займають простір. Тоді ви можете зайти в ці каталоги і перевірити, які файли корисні чи ні. якщо ці файли потрібні, тоді ви можете перемістити їх у якесь постійне сховище, внісши зміни в додаток, щоб використовувати постійне сховище для цього місця або змінити місце розташування цих файлів. А для відпочинку ви можете їх очистити.

Я використав "docker system prune -a", він очистив усі файли під томами та overlay2

    [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 ..