# docker --version
Docker version 1.10.3, build 99b71ce

# docker info
Containers: 3
 Running: 0
 Paused: 0
 Stopped: 3
Images: 29
Server Version: 1.10.3
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 99
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 3.13.0-83-generic
Operating System: <unknown>
OSType: linux
Architecture: x86_64
CPUs: 24
Total Memory: 125.9 GiB
Name: dev34-devc
ID: VKMX:YMJ2:3NGV:5J6I:5RYM:AVBK:QPOZ:ODYE:VQ2D:AF2J:2LEM:TKTE
WARNING: No swap limit support

Я также должен показать, что в докере нет контейнеров, томов или изображений:

$ docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

$ docker volume ls
DRIVER              VOLUME NAME

странный; особенно из-за;

Containers: 3
 Running: 0
 Paused: 0
 Stopped: 3
Images: 29

что не соответствует результату docker images / docker ps .

В какой операционной системе вы работаете?

Operating System: <unknown>

@tonistiigi есть идеи?

Это было потом. Думаю, тем временем начались некоторые процессы.

Состояние, о котором я говорю (у меня сейчас):

$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0

А у меня еще есть:

$ sudo du -hs /var/lib/docker/aufs/diff/a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
296M    /var/lib/docker/aufs/diff/a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea

Мы на Ubuntu Lucid с обновленным ядром = /

$ uname -a
Linux dev34-devc 3.13.0-83-generic #127-Ubuntu SMP Fri Mar 11 00:25:37 UTC 2016 x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 10.04.1 LTS
Release:        10.04
Codename:       lucid

Кажется, интересный вопрос.
возможно ли воспроизвести это? @bukzor

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

`` #! bash

! / bin / bash

set -eu

echo "ВНИМАНИЕ: это остановит ВСЕ процессы докеров и удалит ВСЕ образы докеров."
read -p "Продолжить (да / нет)?"
если ["$ REPLY"! = "y"]; тогда
echo «Прерывание».
выход 1
фи

xdocker () {exec xargs -P10 -r -n1 --verbose docker "$ @"; }

установить -x

удалить контейнеры

докер ps -q | xdocker stop
докер ps -aq | xdocker rm

удалить теги

образы докеров | sed 1d | grep -v '^'| col 1 2 | sed 's / /: /' | xdocker rmi

удалить изображения

образы докеров -q | xdocker rmi
образы докеров -aq | xdocker rmi

удалить тома

том докера ls -q | xdocker volume rm
``

Один из возможных способов, которым я это вижу, - это если есть ошибки при размонтировании aufs. Например, если есть ошибки EBUSY, вероятно, конфигурация образа уже была удалена раньше.

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

Это было бы интересно, но похоже на работу на целый день.
Я не могу этого сделать.

Вот еще несколько данных о (произвольно выбранном) проблемном различии выше, a800 .

`` #! ш
$ docker-find a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea | sudo xargs -n1 wc -l | sort -rn

• sudo find / nail / var / lib / docker '(' -path '/ nail / var / lib / docker / aufs / diff / ' -o -path '/ nail / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -print
• grep a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
• sudo find / nail / var / lib / docker '(' -path '/ nail / var / lib / docker / aufs / diff / ' -o -path '/ nail / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -type f -print0
• sudo xargs -0 -P20 grep -l a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
  15 / гвоздь / var / lib / docker / aufs / Layers / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579
  14 / гвоздь / var / lib / docker / aufs / Layers / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579-init
  13 / гвоздь / var / lib / docker / aufs / Layers / 993e4988c510ec3ab4f6d139740a059df40585576f8196817e573a9684554c5c
  12 / гвоздь / var / lib / docker / aufs / Layers / cf9fd1c4a64baa39b6d6d9dac048ad2fff3c3fe13924b07377e767eed230ba9f
  11 / гвоздь / var / lib / docker / aufs / Layers / 4e6afb958b5ee6dea6d1a886d19fc9c780d4ecc4baeebfbde31f9bb97732d10d
  10 / гвоздь / var / lib / docker / aufs / Layers / 23ce5a473b101d85f0e9465debe5a0f3b8a2079b99528a797b02052d06bc11d8
  9 / гвоздь / var / lib / docker / aufs / Layers / 95e68d59a8704f2bb52cc1306ca910ddb7af8956eb7c57970fcf7d8b3d9baddb
  8 / гвоздь / var / lib / docker / aufs / Layers / ac6b8ff4c0e7b91230ebf4c1caf16f06c1fdceff6111fd58f4ea50fc2dd5050b
  7 / гвоздь / var / lib / docker / aufs / Layers / fd895b6f56aedf09c48dba97931a34cea863a21175450c31b6ceadde03f7b3da
  6 / гвоздь / var / lib / docker / aufs / Layers / d5bbef5adf2efb6f15d4f96c4bee21beb955255d1ec17baf35de66e98e6c7328
  5 / nail / var / lib / docker / aufs / Layers / 9646360df378b88eae6f1d6288439eebd9647d5b9e8a471840d4a9d6ed5d92a4
  4 / гвоздь / var / lib / docker / aufs / Layers / a8001a0e9515cbbda89a54120a89bfd9a3d0304c8d2812401aba33d22a2358ea
  0 / nail / var / lib / docker / image / aufs / layerdb / sha256 / d1c659b8e3d0e893e95c8eedc755adcb91a1c2022e1090376b451f7206f9b1c0 / cache-id

So we see there's a chain of child layers, with `f3286009193` as the tip.

$ docker-find f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 '$'

• sudo find / nail / var / lib / docker '(' -path '/ nail / var / lib / docker / aufs / diff / ' -o -path '/ nail / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -print
• grep --color 'f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 $'
  / nail / var / lib / docker / aufs / Layers / f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579
• sudo find / nail / var / lib / docker '(' -path '/ nail / var / lib / docker / aufs / diff / ' -o -path '/ nail / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -type f -print0
• sudo xargs -0 -P20 grep --color -l 'f3286009193f95ab95a16b2561331db06803ac536cea921d9aa64e1564046579 $'
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / mount-id

So that layer was used in mount `eb809c0321`. I don't find any references to that mount anywhere:

$ docker-find eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e

• sudo find / nail / var / lib / docker '(' -path '/ nail / var / lib / docker / aufs / diff / ' -o -path '/ nail / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -print
• grep --color eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / mount-id
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / init-id
  / nail / var / lib / docker / image / aufs / layerdb / mounts / eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e / parent
• sudo find / nail / var / lib / docker '(' -path '/ nail / var / lib / docker / aufs / diff / ' -o -path '/ nail / var / lib / docker / aufs / mnt / ' ' ) '-prune -o -type f -print0
• sudo xargs -0 -P20 grep --color -l eb809c0321a2501e61763333bc0dfb33ea0539c15957587f5de003ad21b8275e
  ``

Есть ли способ узнать, для какого контейнера использовалось это крепление?
В документе только говорится, что идентификатор монтирования больше не равен идентификатору контейнера, что не очень помогает.
https://docs.docker.com/engine/userguide/storagedriver/aufs-driver/

@bukzor eb809c0321 - идентификатор контейнера. Документы означают, что идентификатор aufs ( f3286009193f в вашем случае) не является идентификатором контейнера.

/ cc @dmcgowan тоже

@tonistiigi ОК.

Тогда, очевидно, гора изжила свой контейнер.

В какой момент жизненного цикла контейнера очищается крепление?
Это временные записываемые aufs для запущенных / остановленных контейнеров?

@bukzor (rw) mount удаляется при удалении контейнера. Размонтирование происходит при остановке процесса контейнера. Папки Diff - это место, где хранится содержимое отдельного слоя, независимо от того, смонтирован этот слой или нет.

@bukzor Связь между идентификатором aufs и идентификатором контейнера можно найти по адресу image/aufs/layerdb/mounts/<container-id>/mount-id . Просто зная идентификатор aufs, самый простой способ найти идентификатор контейнера - это найти для него каталог image/aufs/layerdb . Если ничего не найдено, значит, очистка не была завершена чисто.

Возникла аналогичная проблема.

Мы ежедневно запускаем CI на сервере демона докеров. / var / lib / docker / aufs / diff занимает довольно много места на диске, чего не должно быть.

По-прежнему 2gb в aufs/diff после попытки всего разумного, предложенного здесь или в связанных потоках (включая сценарий bash

Если не считать правильного исправления, есть ли простой способ удалить оставшиеся крепления без одновременного удаления всех других образов? (Если в настоящее время контейнеры не запущены, я думаю, не должно быть никаких монтировок, верно?)

У меня такая же проблема. Я использую эту машину для тестирования множества контейнеров, а затем фиксирую / удаляю. Мой каталог / var / lib / docker / aufs в настоящее время занимает 7,9 ГБ. Мне придется переместить этот каталог в другую точку монтирования, потому что объем хранилища в нем ограничен. :(

# du -sh /var/lib/docker/aufs/diff/
1.9T    /var/lib/docker/aufs/diff/

@mcallaway Все в aufs/diff будет записью fs, выполняемой в контейнере.

У меня такая же проблема. Все контейнеры, которые у меня есть, находятся в рабочем состоянии, но есть много каталогов aufs diff, которые не относятся к этим контейнерам и относятся к старым удаленным контейнерам. Я могу удалить их вручную, но это не вариант. Для такого поведения должна быть причина.

Использую k8s 1.3.5 и docker 1.12.

Помогло выполнение docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc spotify/docker-gc .

У меня такая же проблема. Я использую Gitlab CI с dind (докер в докере).

ИМХО, когда изображение в реестре было обновлено в том же теге и было извлечено, затем связанный контейнер был перезапущен, старый контейнер и изображение не собираются в сборку, если вы не запустите spotify/docker-gc .

Может кто-нибудь еще это подтвердит?

@kayrus правильно, докер не будет автоматически предполагать, что "немаркированный" образ также должен быть _удален_. Контейнеры все еще могут использовать этот образ, и вы все еще можете запускать новые контейнеры из этого образа (ссылаясь на него по его идентификатору). Вы можете удалить "болтающиеся" изображения с помощью docker rmi $(docker images -qa -f dangling=true) . Кроме того, docker 1.13 получит команды управления данными (см. Https://github.com/docker/docker/pull/26108), которые позволят вам легко очищать неиспользуемые образы, контейнеры и т. Д.

@thaJeztah действительно ли /var/lib/docker/aufs/diff/ содержит "немаркированные" изображения?

@kayrus да, они являются частью изображений (с тегами и без тегов)

получение аналогичной проблемы, без контейнеров / изображений / томов, ~ 13 ГБ различий

$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.12.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 1030
 Dirperm1 Supported: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor
Kernel Version: 3.13.0-32-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 3.861 GiB
Name: gitrunner
ID: GSAW:6X5Z:SHHU:NZIM:O76D:P5OE:7OZG:UFGQ:BOAJ:HJFM:5G6W:5APP
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 127.0.0.0/8

$ docker volume ls
DRIVER              VOLUME NAME
$ docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
$

$ df -h
Filesystem                                 Size  Used Avail Use% Mounted on
...
/dev/mapper/gitrunner--docker-lib--docker   18G   15G  2.6G  85% /var/lib/docker

/var/lib/docker# sudo du -sm aufs/*
13782   aufs/diff
5       aufs/layers
5       aufs/mnt

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 1.12.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: xfs
 Dirs: 1122

Здесь та же проблема. Я понимаю, что 1.13 может получать команды управления данными, но пока я просто хочу безопасно удалить содержимое этого каталога, не убивая Docker.

Это относительно блокирующий момент.

То же самое. По-прежнему нет официального решения?

Я несколько раз поднимал этот вопрос в (Сообщество Docker) Slack. Каждый раз, когда горстка людей просматривает список сценариев / команд сборки мусора, я должен запускать их как решение.

Хотя они помогли (читай: не решено - пространство все еще приближается к полному), я думаю, мы все можем согласиться с тем, что это не идеальное долгосрочное решение.

@jadametz 1.13 содержит docker system prune .
Кроме того, я не уверен, чем еще может помочь Docker (открыт для предложений). Образы попадают в систему не просто сами по себе, а через извлечение, сборку и т. Д.

Что касается фактически потерянных слоев (в системе нет изображений, ссылающихся на них), нам нужно будет рассмотреть это отдельно.

У меня точно такая же проблема!

docker info Containers: 0 Running: 0 Paused: 0 Stopped: 0 Images: 0 Server Version: 1.12.1 Storage Driver: aufs Root Dir: /var/lib/docker/aufs Backing Filesystem: extfs Dirs: 2501 Dirperm1 Supported: false Logging Driver: json-file Cgroup Driver: cgroupfs Plugins: Volume: local Network: bridge host null overlay Swarm: inactive Runtimes: runc Default Runtime: runc Security Options: apparmor Kernel Version: 3.13.0-96-generic Operating System: Ubuntu 14.04.2 LTS OSType: linux Architecture: x86_64 CPUs: 8 Total Memory: 14.69 GiB Name: ip-172-31-45-4 ID: R5WV:BXU5:AV6T:GZUK:SAEA:6E74:PRSO:NQOH:EPMQ:W6UT:5DU4:LE64 Docker Root Dir: /var/lib/docker Debug Mode (client): false Debug Mode (server): false Registry: https://index.docker.io/v1/ WARNING: No swap limit support Insecure Registries: 127.0.0.0/8

Никаких изображений, контейнеров или томов. 42 ГБ в aufs / diff

Все, что поможет безопасно очистить этот каталог, было бы очень полезно! Пробовал все в этой ветке безуспешно. Спасибо.

@adamdry только сторонний скрипт: https://github.com/docker/docker/issues/22207#issuecomment -252560212

Спасибо @kayrus, я действительно пробовал это, и это немного увеличило мое общее использование диска и, похоже, ничего не сделало с каталогом aufs / diff.

Я также пробовал docker system prune который не работал. И я попробовал docker rmi $(docker images -qa -f dangling=true) но не нашел изображений для удаления.

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

### FYI I am a Docker noob so I don't know if this causes any underlying issues but it does work for me - use at your own risk ###

Здесь много вдохновения: http://stackoverflow.com/questions/30984569/error-error-creating-aufs-mount-to-when-building-dockerfile

docker rm -f $(docker ps -a -q) && docker rmi -f $(docker images -q) && docker rmi -f $(docker images -a -q)
service docker stop
rm -rf /var/lib/docker/aufs
rm -rf /var/lib/docker/image/aufs
rm -f /var/lib/docker/linkgraph.db
service docker start

@adamdry Лучше не использовать -f при выполнении rm / rmi, так как это скроет ошибки при удалении.
Я рассматриваю текущую ситуацию ... когда -f скрывает ошибку, а затем у нас остается некоторое оставшееся состояние, которое полностью невидимо для пользователя ... как ошибку.

Я также вижу это на совершенно новой и неудивительной установке:

root<strong i="6">@builder</strong>:/var/lib/docker# docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.12.4
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 63
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay host null bridge
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options:
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 3.625 GiB
Name: builder
ID: 2WXZ:BT74:G2FH:W7XD:VVXM:74YS:EA3A:ZQUK:LPID:WYKF:HDWC:UKMJ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
Insecure Registries:
 127.0.0.0/8
root<strong i="7">@builder</strong>:/var/lib/docker# docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
root<strong i="8">@builder</strong>:/var/lib/docker# docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
root<strong i="9">@builder</strong>:/var/lib/docker# du -hd2
4.0K    ./swarm
6.0M    ./image/aufs
6.0M    ./image
4.0K    ./trust
28K ./volumes
4.0K    ./containers
276K    ./aufs/layers
292K    ./aufs/mnt
1.5G    ./aufs/diff <-------------------------
1.5G    ./aufs
4.0K    ./tmp
72K ./network/files
76K ./network
1.5G    .
root<strong i="10">@builder</strong>:/var/lib/docker# 

@robhaswell Поскольку это новая установка, вы хотите попробовать это? https://github.com/docker/docker/issues/22207#issuecomment -266784433

@adamdry Я уже удалил /var/lib/docker/aufs как он блокировал мою работу. Чего вы ожидаете от ваших инструкций? Если они предотвратят повторение проблемы в будущем, я могу попытаться воссоздать проблему и попробовать ваши инструкции. Однако если цель состоит в том, чтобы просто освободить место, я уже этого добился.

@robhaswell Да, это было

Если во время сборки процесс сборки прерывается во время процесса сборки уровня (который также содержит большой двоичный объект для копирования) с последующей остановкой контейнера, он оставляет данные в / var / lib / docker / aufs / diff /. Появилось болтающееся изображение. Очистка тоже не освободила место. Можно ли включить его как часть очистки системы докеров? Только удаление данных blob внутри этой папки освобождает пространство, что, я не уверен, вызовет какие-либо проблемы или нет.

Версия докера: 1.13.0-rc1

Во время сборки, если процесс сборки прерывается во время процесса сборки слоя (который также содержит большой двоичный объект для копирования) с последующей остановкой контейнера, он оставляет данные

Это тоже могло быть причиной моих проблем - я прерываю множество сборок.

Во время docker pull наблюдались следующие два случая:

1. если процесс прерывается, когда он говорит загрузить (который загружает слой изображения в / var / lib / docker / tmp /), он очищает все данные в этой папке
2. Если процесс прерывается, когда он говорит об извлечении (который, как я полагаю, извлекает слой из tmp в / var / lib / docker / aufs / diff /), он очищает как данные tmp, так и diff blob.

В процессе сборки образа

1. При прерывании процесса при «Отправке контекста сборки демону докера» (который копирует данные большого двоичного объекта в моем случае в / var / lib / docker / tmp /), он остается там навсегда и не может быть очищен никакими командами, кроме ручного удаления. Я не уверен, как обрабатываются обновления изображения.
2. Пока строится слой, содержащий данные blob, скажем, большая установка программного обеспечения, если процесс прерывается, контейнер докера продолжает работать с образом. В моем случае только одноуровневые данные blob, которые уже доступны в папке tmp, составляют все изображение. Но, если контейнер останавливается с помощью команды docker stop, случаются два случая:
   а. если процесс монтирования все еще происходит, он оставит данные в папках tmp и diff.
   б. Если данные скопированы в папку diff, он удалит данные из папки tmp и оставит данные в папке diff и, возможно, в папке монтирования.

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

Если одно изображение должно быть построено из 2 слоев, 1 слой создается, а второй прерывается, сокращение системы Docker, похоже, очищает данные для контейнера уровня, который был прерван и контейнер остановлен. Но он не очищает данные предыдущих слоев в случае прерывания. Кроме того, он не отражал общее требуемое дисковое пространство. Выполните эти тесты на AWS, ubuntu 14.04, x86_64 битной системе с файловой системой aufs. Проведите тест docker prune с помощью docker 1.13.0 rc3 и docker 1.12

@thaJeztah
Пожалуйста, дайте мне знать, если я что-то неправильно интерпретирую.

Я открыл проблему из-за того, что файлы /var/lib/docker/tmp не очищаются; https://github.com/docker/docker/issues/29486

Сокращение системы Docker, похоже, очищает данные для контейнера уровня, который был прерван и контейнер остановлен. Но он не очищает данные предыдущих слоев в случае прерывания.

Я попытался воспроизвести эту ситуацию, но не смог увидеть это на простом случае;

Начните с чистой установки пустого /var/lib/docker , создайте большой файл для
тестирование и Dockerfile;

mkdir repro && cd repro
fallocate -l 300M bigfile

cat > Dockerfile <<EOF
FROM scratch
COPY ./bigfile /
COPY ./bigfile /again/
COPY ./bigfile /and-again/
EOF

запустить docker build и отменить во время сборки, но _после_ сборки
контекст был отправлен;

docker build -t stopme .
Sending build context to Docker daemon 314.6 MB
Step 1/4 : FROM scratch
 --->
Step 2/4 : COPY ./bigfile /
 ---> 28eb6d7b0920
Removing intermediate container 98876b1673bf
Step 3/4 : COPY ./bigfile /again/
^C

проверить содержимое /var/lib/docker/aufs/

du -h /var/lib/docker/aufs/
301M    /var/lib/docker/aufs/diff/9127644c356579741348f7f11f50c50c9a40e0120682782dab55614189e82917
301M    /var/lib/docker/aufs/diff/81fd6b2c0cf9a28026cf8982331016a6cd62b7df5a3cf99182e7e09fe0d2f084/again
301M    /var/lib/docker/aufs/diff/81fd6b2c0cf9a28026cf8982331016a6cd62b7df5a3cf99182e7e09fe0d2f084
601M    /var/lib/docker/aufs/diff
8.0K    /var/lib/docker/aufs/layers
4.0K    /var/lib/docker/aufs/mnt/9127644c356579741348f7f11f50c50c9a40e0120682782dab55614189e82917
4.0K    /var/lib/docker/aufs/mnt/81fd6b2c0cf9a28026cf8982331016a6cd62b7df5a3cf99182e7e09fe0d2f084
4.0K    /var/lib/docker/aufs/mnt/b6ffb1d5ece015ed4d3cf847cdc50121c70dc1311e42a8f76ae8e35fa5250ad3-init
16K /var/lib/docker/aufs/mnt
601M    /var/lib/docker/aufs/

запустите команду docker system prune чтобы очистить изображения, контейнеры;

docker system prune -a
WARNING! This will remove:
    - all stopped containers
    - all volumes not used by at least one container
    - all networks not used by at least one container
    - all images without at least one container associated to them
Are you sure you want to continue? [y/N] y
Deleted Images:
deleted: sha256:253b2968c0b9daaa81a58f2a04e4bc37f1dbf958e565a42094b92e3a02c7b115
deleted: sha256:cad1de5fd349865ae10bfaa820bea3a9a9f000482571a987c8b2b69d7aa1c997
deleted: sha256:28eb6d7b09201d58c8a0e2b861712701cf522f4844cf80e61b4aa4478118c5ab
deleted: sha256:3cda5a28d6953622d6a363bfaa3b6dbda57b789e745c90e039d9fc8a729740db

Total reclaimed space: 629.1 MB

проверить содержимое /var/lib/docker/aufs/

du -h /var/lib/docker/aufs/
4.0K    /var/lib/docker/aufs/diff
4.0K    /var/lib/docker/aufs/layers
4.0K    /var/lib/docker/aufs/mnt/b6ffb1d5ece015ed4d3cf847cdc50121c70dc1311e42a8f76ae8e35fa5250ad3-init
8.0K    /var/lib/docker/aufs/mnt
20K /var/lib/docker/aufs/

Я вижу, что -init mount осталось позади, я проверю, сможем ли мы решить
что (хотя это просто пустой каталог)

Единственная разница в dockerfile, который я использовал, заключалась в том, что (для создания разных слоев)
С нуля
КОПИРОВАТЬ ["./bigfile", "randomNoFile1", /]
КОПИРОВАТЬ ["./bigfile", "randomNoFile2", /]
EOF

Я не уверен, имеет ли это значение.

Нет, проблема не в пустых папках инициализации. В моем случае это был te blob. Тем не менее, я могу перепроверить его в понедельник и обновить.

Кроме того, использовался файл размером 5 ГБ, созданный путем чтения байтов из dev urandom.
В вашем случае один и тот же файл добавляется 2 раза. Будет ли это создавать один слой и монтировать из него 2-й слой или это будет 2 отдельных слоя? В моем случае это всегда 2 отдельных слоя.

@thaJeztah
Спасибо за такой быстрый ответ по проблеме. Добавление этой функции было бы большим подспорьем!

@ monikakatiyar16 Я попытался воспроизвести это тоже, отменив сборку несколько раз во время команд ADD и RUN но после удаления ничего не удалось передать в aufs/diff . Я не мог понять, какой контейнер вы останавливаете, потому что контейнеры не должны запускаться во время операций ADD/COPY . Мы будем очень признательны, если вы сможете собрать репродуктор, который мы могли бы запустить.

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

@tonistiigi @thaJeztah
Я чувствую, что ты прав. Фактически нет контейнеров, которые указаны как активные и работающие. Вместо этого есть мертвые контейнеры. Сокращение системы Docker в моем случае не сработало, возможно, потому, что процесс не был убит с помощью Ctrl + C. Вместо этого он продолжал работать в фоновом режиме. В моем случае это могло быть причиной того, что он не смог удалить эти капли.

Когда я прерываю процесс с помощью Ctrl + C, процесс сборки прекращается, но процесс для docker-untar остается активным в фоновом режиме, который продолжает работать над созданием образа. (Примечание: / var / lib / docker мягко связан с / home / lib / docker для использования томов EBS для больших данных на AWS)

root 12700 10781 7 11:43 ? 00:00:04 docker-untar /home/lib/docker/aufs/mnt/d446d4f8a7dbae162e7578af0d33ac38a63b4892905aa86a8d131c1e75e2828c

Я прикрепил скрипт, который использовал для создания больших файлов и построения изображения (gc_maxpush_pull.sh)

Также добавлено поведение процесса сборки для создания образа - прерывание его с помощью Ctrl + C (DockerBuild_WOProcessKill) и создание образа - прерывание его с помощью Ctrl + C - завершение процесса (DockerBuild_WithProcessKill)

Используя команды -

Чтобы создать большой файл: ./gc_maxpush_pull.sh 1 5gblayer 0 512 1

Для создания изображений: ./gc_maxpush_pull.sh 1 5gblayer 1 512 1

DockerBuild.zip

Шаги по воспроизведению:

1. Создайте большой файл размером 5 ГБ
2. Запустите процесс сборки и прервите его только после того, как отправка контекста сборки завершится и он фактически скопирует большой двоичный объект.
3. Через некоторое время он завершает создание образа и показывает его в образах докеров (как в случае 1, прикрепленном мной - DockerBuild_WOProcessKill)
4. Если процесс убит, он занимает некоторое время и оставляет данные большого двоичного объекта в / diff (что должно происходить при внезапном прерывании процесса, как прикреплено в файле - DockerBuild_WithProcessKill)

Если то, что я предполагаю, верно, то это может быть не проблема с docker prune, вместо этого с уничтожением сборки docker, которая у меня почему-то не работает.

Есть ли изящный способ прервать или остановить процесс создания образа, который также позаботится об очистке скопированных данных (как обрабатывается в docker pull)?

Раньше не убивал процесс. Мне также любопытно, что делает docker-untar и почему он монтирует его в папки / mnt и / diff, а затем очищает папку / mnt?

Проверено с помощью Docker версии 1.12.5, сборка 7392c3b на AWS.

информация о докере
Контейнеры: 2
Бег: 0
Приостановлено: 0
Остановлено: 2
Изображения: 0
Версия сервера: 1.12.5
Драйвер хранилища: aufs
Корневой каталог: / home / lib / docker / aufs
Резервная файловая система: extfs
Режиссеры: 4
Dirperm1 Поддерживается: false
Драйвер логирования: json-файл
Драйвер Cgroup: cgroupfs
Плагины:
Объем: местный
Сеть: оверлейный мост нулевой хост
Рой: неактивен
Время выполнения: runc
Время выполнения по умолчанию: runc
Параметры безопасности: apparmor
Версия ядра: 3.13.0-105-generic
Операционная система: Ubuntu 14.04.4 LTS
OSType: linux
Архитектура: x86_64
Процессоры: 2
Общий объем памяти: 3,859 Гбайт
Имя: мастер
ID: 2 NQU: D2C5 : 5 WPL: IIDR : P6FO: OAG7: GHW6: ZJMQ: VDHI : B5CI: XFZJ: ZSZM
Корневой каталог Docker: / home / lib / docker
Режим отладки (клиент): false
Режим отладки (сервер): false
Реестр: https://index.docker.io/v1/
ВНИМАНИЕ: нет поддержки ограничения свопинга
Небезопасные реестры:
127.0.0.0/8

@ monikakatiyar16 Когда я вручную убиваю процесс untar во время сборки, я получаю Error processing tar file(signal: killed): в выводе сборки. Оставление контейнера в docker ps -a - это правильное поведение, то же самое происходит при любой ошибке сборки и позволяет вам отлаживать проблемы, которые привели к сбою сборки. У меня нет проблем с удалением этого контейнера, и если я это сделаю, все данные в /var/lib/docker/aufs будут очищены.

@tonistiigi Да, вы правы. Я смог удалить том, связанный с контейнером, и он очистил все после того, как убил процесс docker-untar. В этом случае также работает сокращение системы Docker.

Фактическая проблема с оставшимися томами заключалась в том, что, не убивая процесс docker-untar, я попытался удалить контейнер докера вместе с томами, что дало следующую ошибку:

docker rm -v -f $(docker ps -a -q)
Error response from daemon: Driver aufs failed to remove root filesystem 97931bf059a0ec219efd3f762dbb173cf9372761ff95746358c08e2b61f7ce79: rename /home/lib/docker/aufs/diff/359d27c5b608c9dda1170d1e34e5d6c5d90aa2e94826257f210b1442317fad70 /home/lib/docker/aufs/diff/359d27c5b608c9dda1170d1e34e5d6c5d90aa2e94826257f210b1442317fad70-removing: device or resource busy

Журналы демона:

Error removing mounted layer 78fb899aab981557bc2ee48e9738ff4c2fcf2d10a1984a62a77eefe980c68d4a: rename /home/lib/docker/aufs/diff/d2605125ef072de79dc948f678aa94dd6dde562f51a4c0bd08a210d5b2eba5ec /home/lib/docker/aufs/diff/d2605125ef072de79dc948f678aa94dd6dde562f51a4c0bd08a210d5b2eba5ec-removing: device or resource busy ERRO[0956] Handler for DELETE /v1.25/containers/78fb899aab98 returned error: Driver aufs failed to remove root filesystem 78fb899aab981557bc2ee48e9738ff4c2fcf2d10a1984a62a77eefe980c68d4a: rename /home/lib/docker/aufs/diff/d2605125ef072de79dc948f678aa94dd6dde562f51a4c0bd08a210d5b2eba5ec /home/lib/docker/aufs/diff/d2605125ef072de79dc948f678aa94dd6dde562f51a4c0bd08a210d5b2eba5ec-removing: device or resource busy ERRO[1028] Error unmounting container 78fb899aab981557bc2ee48e9738ff4c2fcf2d10a1984a62a77eefe980c68d4a: no such file or directory

Похоже, что прямо сейчас нужно следовать порядку прерывания сборки докера:
Interrupt docker build > Kill docker untar process > remove container and volume : docker rm -v -f $(docker ps -a -q)

Для docker v1.13.0-rc4 это может быть Interrupt docker build > Kill docker untar process > docker system prune -a

Кажется, это работает отлично. Нет проблем с очисткой, вместо этого единственная проблема заключается в том, что процесс docker-untar не убивается вместе с процессом docker-build.

Я буду искать / обновлять / регистрировать новую проблему для постепенного прерывания сборки докера, которая также останавливает процесс docker-untar вместе с ней.

(Проверено с помощью docker v1.12.5 и v1.13.0-rc4)

Обновление: при убийстве docker-untar при отправке контекста сборки демону docker выдает ошибку в сборке: Error response from daemon: Error processing tar file(signal: terminated) , но во время копирования слоя это не так (для меня)

Спасибо за терпение и за то, что уделили время!

Я вижу, что /var/lib/docker/aufs постоянно увеличивается в размере у рабочего режима docker swarm. Эта штука в основном автономна, управляется менеджером роя и очень мало ручного создания контейнера, за исключением некоторых команд обслуживания здесь и там.

Я запускаю docker exec в служебных контейнерах; не уверен, что это может быть причиной.

Чтобы решить эту проблему в моем случае, я решил запустить другого воркера, установить для полного узла значение --availability=drain и вручную переместить пару монтированных томов.

ubuntu@ip-172-31-18-156:~$ docker --version
Docker version 1.12.3, build 6b644ec

Это уже давно поразило наш CI-сервер. Это нужно исправить.

@orf спасибо

Здесь та же проблема. Ни контейнеры, ни тома, ни удаление образов, ни команды очистки Docker 1.13 не имеют никакого эффекта.

Я также подтверждаю, что отменил некоторые сборки изображений. Может быть, это оставляет папки, которые тоже недостижимы.
Сейчас я буду использовать старый добрый метод rm, но это явно ошибка.

Файлы в / var / lib / docker / aufs / diff заполняют 100% места для файловой системы / dev / sda1 размером 30 ГБ.

корень @ Ubuntu : / var / lib / docker / aufs / diff # df -h

Используемый размер файловой системы Доступность% Установлено
udev 14G 0 14G 0% / dev
tmpfs 2,8 ГБ 273 МБ 2,5 ГБ 10% / запуск
/ dev / sda1 29 ГБ 29 ГБ 0100% /
tmpfs 14 ГБ 0 14 ГБ 0% / dev / shm
tmpfs 5.0M 0 5.0M 0% / запуск / блокировка
tmpfs 14 ГБ 0 14 ГБ 0% / sys / fs / cgroup
/ dev / sdb1 197 ГБ 60 МБ 187 ГБ 1% / mnt
tmpfs 2,8 ГБ 0 2,8 ГБ 0% / запуск / пользователь / 1000

du -h -d 1 / var / lib / docker / aufs / diff | grep '[0-9] G>'
показывает

4.1 ГБ / var / lib / docker / aufs / diff / a0cde42cbea362bbb2a73ffbf30059bcce7ef0256d1d7e186264f915d15
14G / var / lib / docker / aufs / diff / 59aee33d8a607b5315ce103cd99f17b4dfdec73c9a2f3bb2afc7d02bfae
20 ГБ / var / lib / docker / aufs / diff

Также попробовал удалить систему докеров , это не помогло.

Кто-нибудь нашел решение этой продолжающейся проблемы сверхбольших файлов в diff до того, как эта ошибка будет исправлена ​​в коде?

Да, метод уже был дан, но вот фрагмент апокалипсиса, который просто уничтожает все, что я поставил здесь на работе (кроме локальных папок для томов). Чтобы вставить bashrc или другой файл конфигурации bash.

``
псевдоним docker-full-cleanup = 'func_full-cleanup-docker'

func_full-cleanup-docker () {

echo "ПРЕДУПРЕЖДЕНИЕ: это удалит из докера все: тома, контейнеры и образы. Осмелитесь ли вы? [да / нет]»
читать выбор

если [("$ choice" == "y") -o ("$ choice" == "Y")]
тогда
sudo echo "> проверка прав sudo [ОК]"
sizea = sudo du -sh /var/lib/docker/aufs

echo "Stopping all running containers"
containers=`docker ps -a -q`
if [ -n "$containers" ]
then
  docker stop $containers
fi

echo "Removing all docker images and containers"
docker system prune -f

echo "Stopping Docker daemon"
sudo service docker stop

echo "Removing all leftovers in /var/lib/docker (bug #22207)"
sudo rm -rf /var/lib/docker/aufs
sudo rm -rf /var/lib/docker/image/aufs
sudo rm -f /var/lib/docker/linkgraph.db

echo "Starting Docker daemon"
sudo service docker start

sizeb=`sudo du -sh /var/lib/docker/aufs`
echo "Size before full cleanup:"
echo "        $sizea"
echo "Size after full cleanup:"
echo "        $sizeb"

фи
} `` `

Я выполнил команду rm -rf, чтобы удалить файлы из папки diff. Возможно, придется заглянуть в сценарий, если папка diff снова займет все дисковое пространство.
Надеюсь, что эта проблема будет исправлена ​​в коде, а не для ее решения.

Привет, у меня такая же проблема в докере 1.10.2, я использую кубернетес. это моя версия докера:

Containers: 7
 Running: 0
 Paused: 0
 Stopped: 7
Images: 4
Server Version: 1.10.2
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 50
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 4.4.0-31-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 1.954 GiB
Name: ubuntu-k8s-03
ID: NT23:5Y7J:N2UM:NA2W:2FHE:FNAS:56HF:WFFF:N2FR:O4T4:WAHC:I3PO
Debug mode (server): true
 File Descriptors: 10
 Goroutines: 23
 System Time: 2017-02-14T15:25:00.740998058+09:00
 EventsListeners: 0
 Init SHA1: 3e247d0d32543488f6e70fbb7c806203f3841d1b
 Init Path: /usr/lib/docker/dockerinit
 Docker Root Dir: /var/lib/docker
WARNING: No swap limit support

Я пытаюсь отследить весь неиспользуемый каталог diff в /var/lib/docker/aufs/diff и /var/lib/docker/aufs/mnt/ , анализируя файлы слоев в /var/lib/docker/image/aufs/imagedb , вот сценарий, который я использовал:

https://gist.github.com/justlaputa/a50908d4c935f39c39811aa5fa9fba33

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

/var/log/upstart/docker.log:

DEBU[0277] Cleaning up old shm/mqueue mounts: start.
DEBU[0277] Cleaning up old shm/mqueue mounts: done.
DEBU[0277] Clean shutdown succeeded
Waiting for /var/run/docker.sock
DEBU[0000] docker group found. gid: 999
DEBU[0000] Server created for HTTP on unix (/var/run/docker.sock)
DEBU[0000] Using default logging driver json-file
INFO[0000] [graphdriver] using prior storage driver "aufs"
DEBU[0000] Using graph driver aufs
INFO[0000] Graph migration to content-addressability took 0.00 seconds
DEBU[0000] Option DefaultDriver: bridge
DEBU[0000] Option DefaultNetwork: bridge
INFO[0000] Firewalld running: false
DEBU[0000] /sbin/iptables, [--wait -t nat -D PREROUTING -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT -m addrtype --dst-type LOCAL ! --dst 127.0.0.0/8 -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -D PREROUTING]
DEBU[0000] /sbin/iptables, [--wait -t nat -D OUTPUT]
DEBU[0000] /sbin/iptables, [--wait -t nat -F DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -X DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -F DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -X DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -F DOCKER-ISOLATION]
DEBU[0000] /sbin/iptables, [--wait -t filter -X DOCKER-ISOLATION]
DEBU[0000] /sbin/iptables, [--wait -t nat -n -L DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t nat -N DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -n -L DOCKER]
DEBU[0000] /sbin/iptables, [--wait -t filter -n -L DOCKER-ISOLATION]
DEBU[0000] /sbin/iptables, [--wait -t filter -C DOCKER-ISOLATION -j RETURN]
DEBU[0000] /sbin/iptables, [--wait -I DOCKER-ISOLATION -j RETURN]
/var/run/docker.sock is up
DEBU[0000] Registering ipam driver: "default"
DEBU[0000] releasing IPv4 pools from network bridge (dcfcc71060f02440ae53da5ee0f083ca51c33a290565f1741f451754ae6b4257)
DEBU[0000] ReleaseAddress(LocalDefault/10.254.69.0/24, 10.254.69.1)
DEBU[0000] ReleasePool(LocalDefault/10.254.69.0/24)
DEBU[0000] Allocating IPv4 pools for network bridge (159d0a404ff6564b4fcfe633f0c8c123c0c0606d28ec3b110272650c5fc1bcb6)
DEBU[0000] RequestPool(LocalDefault, 10.254.69.1/24, , map[], false)
DEBU[0000] RequestAddress(LocalDefault/10.254.69.0/24, 10.254.69.1, map[RequestAddressType:com.docker.network.gateway])
DEBU[0000] /sbin/iptables, [--wait -t nat -C POSTROUTING -s 10.254.69.0/24 ! -o docker0 -j MASQUERADE]
DEBU[0000] /sbin/iptables, [--wait -t nat -C DOCKER -i docker0 -j RETURN]
DEBU[0000] /sbin/iptables, [--wait -t nat -I DOCKER -i docker0 -j RETURN]
DEBU[0000] /sbin/iptables, [--wait -D FORWARD -i docker0 -o docker0 -j DROP]
DEBU[0000] /sbin/iptables, [--wait -t filter -C FORWARD -i docker0 -o docker0 -j ACCEPT]
DEBU[0000] /sbin/iptables, [--wait -t filter -C FORWARD -i docker0 ! -o docker0 -j ACCEPT]
DEBU[0000] /sbin/iptables, [--wait -t filter -C FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT]
DEBU[0001] /sbin/iptables, [--wait -t nat -C PREROUTING -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0001] /sbin/iptables, [--wait -t nat -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER]
DEBU[0001] /sbin/iptables, [--wait -t nat -C OUTPUT -m addrtype --dst-type LOCAL -j DOCKER ! --dst 127.0.0.0/8]
DEBU[0001] /sbin/iptables, [--wait -t nat -A OUTPUT -m addrtype --dst-type LOCAL -j DOCKER ! --dst 127.0.0.0/8]
DEBU[0001] /sbin/iptables, [--wait -t filter -C FORWARD -o docker0 -j DOCKER]
DEBU[0001] /sbin/iptables, [--wait -t filter -C FORWARD -o docker0 -j DOCKER]
DEBU[0001] /sbin/iptables, [--wait -t filter -C FORWARD -j DOCKER-ISOLATION]
DEBU[0001] /sbin/iptables, [--wait -D FORWARD -j DOCKER-ISOLATION]
DEBU[0001] /sbin/iptables, [--wait -I FORWARD -j DOCKER-ISOLATION]
WARN[0001] Your kernel does not support swap memory limit.
DEBU[0001] Cleaning up old shm/mqueue mounts: start.
DEBU[0001] Cleaning up old shm/mqueue mounts: done.
DEBU[0001] Loaded container 0790b33ec8e5345ac944d560263b8e13cb75f80dd82cd25753c7320bbcb2747c
DEBU[0001] Loaded container 0e36a6c9319e6b7ca4e5b5408e99d77d51b1f4e825248c039ba0260e628c483d
DEBU[0001] Loaded container 135fb2e8cad26d531435dcd19d454e41cf7aece289ddc7374b4c2a984f8b094a
DEBU[0001] Loaded container 2c28de46788ce96026ac8e61e99c145ec55517543e078a781e8ce6c8cddec973
DEBU[0001] Loaded container 35eb075b5815e621378eb8a7ff5ad8652819ec851eaa4f7baedb1383dfa51a57
DEBU[0001] Loaded container 6be37a301a8f52040adf811041c140408224b12599aa55155f8243066d2b0b69
DEBU[0001] Loaded container d98ac7f052fef31761b82ab6c717760428ad5734df4de038d80124ad5b5e8614
DEBU[0001] Starting container 2c28de46788ce96026ac8e61e99c145ec55517543e078a781e8ce6c8cddec973
ERRO[0001] Couldn't run auplink before unmount: exit status 22
ERRO[0001] error locating sandbox id d4c538661db2edc23c79d7dddcf5c7a8886c9477737888a5fc2641bc5e66da8b: sandbox d4c538661db2edc23c79d7dddcf5c7a8886c9477737888a5fc2641bc5e66da8b not found
WARN[0001] failed to cleanup ipc mounts:
failed to umount /var/lib/docker/containers/2c28de46788ce96026ac8e61e99c145ec55517543e078a781e8ce6c8cddec973/shm: invalid argument
ERRO[0001] Failed to start container 2c28de46788ce96026ac8e61e99c145ec55517543e078a781e8ce6c8cddec973: error creating aufs mount to /var/lib/docker/aufs/mnt/187b8026621da2add42330c9393a474fcd9af2e4567596d61bcd7a40c85f71da: invalid argument
INFO[0001] Daemon has completed initialization
INFO[0001] Docker daemon                                 commit=c3959b1 execdriver=native-0.2 graphdriver=aufs version=1.10.2
DEBU[0001] Registering routers
DEBU[0001] Registering HEAD, /containers/{name:.*}/archive

и когда я пытаюсь создать новые контейнеры с помощью docker run , это не удается с сообщением:

docker: Error response from daemon: error creating aufs mount to /var/lib/docker/aufs/mnt/f9609c0229baa2cdc6bc07c36970ef4f192431c1b1976766b3ea23d72c355df3-init: invalid argument.
See 'docker run --help'.

и журнал демона показывает:

DEBU[0173] Calling POST /v1.22/containers/create
DEBU[0173] POST /v1.22/containers/create
DEBU[0173] form data: {"AttachStderr":false,"AttachStdin":false,"AttachStdout":false,"Cmd":["/hyperkube","kubelet","--api-servers=http://localhost:8080","--v=2","--address=0.0.0.0","--enable-server","--hostname-override=172.16.210.87","--config=/etc/kubernetes/manifests-multi","--cluster-dns=10.253.0.10","--cluster-domain=cluster.local","--allow_privileged=true"],"Domainname":"","Entrypoint":null,"Env":[],"HostConfig":{"Binds":["/sys:/sys:ro","/dev:/dev","/var/lib/docker/:/var/lib/docker:rw","/var/lib/kubelet/:/var/lib/kubelet:rw","/var/run:/var/run:rw","/etc/kubernetes/manifests-multi:/etc/kubernetes/manifests-multi:ro","/:/rootfs:ro"],"BlkioDeviceReadBps":null,"BlkioDeviceReadIOps":null,"BlkioDeviceWriteBps":null,"BlkioDeviceWriteIOps":null,"BlkioWeight":0,"BlkioWeightDevice":null,"CapAdd":null,"CapDrop":null,"CgroupParent":"","ConsoleSize":[0,0],"ContainerIDFile":"","CpuPeriod":0,"CpuQuota":0,"CpuShares":0,"CpusetCpus":"","CpusetMems":"","Devices":[],"Dns":[],"DnsOptions":[],"DnsSearch":[],"ExtraHosts":null,"GroupAdd":null,"IpcMode":"","Isolation":"","KernelMemory":0,"Links":null,"LogConfig":{"Config":{},"Type":""},"Memory":0,"MemoryReservation":0,"MemorySwap":0,"MemorySwappiness":-1,"NetworkMode":"host","OomKillDisable":false,"OomScoreAdj":0,"PidMode":"host","PidsLimit":0,"PortBindings":{},"Privileged":true,"PublishAllPorts":false,"ReadonlyRootfs":false,"RestartPolicy":{"MaximumRetryCount":0,"Name":"always"},"SecurityOpt":null,"ShmSize":0,"UTSMode":"","Ulimits":null,"VolumeDriver":"","VolumesFrom":null},"Hostname":"","Image":"gcr.io/google_containers/hyperkube:v1.1.8","Labels":{},"NetworkingConfig":{"EndpointsConfig":{}},"OnBuild":null,"OpenStdin":false,"StdinOnce":false,"StopSignal":"SIGTERM","Tty":false,"User":"","Volumes":{},"WorkingDir":""}
ERRO[0173] Couldn't run auplink before unmount: exit status 22
ERRO[0173] Clean up Error! Cannot destroy container 482957f3e4e92a0ba56d4787449daa5a8708f3b77efe0c603605f35d02057566: nosuchcontainer: No such container: 482957f3e4e92a0ba56d4787449daa5a8708f3b77efe0c603605f35d02057566
ERRO[0173] Handler for POST /v1.22/containers/create returned error: error creating aufs mount to /var/lib/docker/aufs/mnt/f9609c0229baa2cdc6bc07c36970ef4f192431c1b1976766b3ea23d72c355df3-init: invalid argument

кто-нибудь знает, верен ли мой подход или нет? и почему проблема возникает после удаления этих папок?

Я открыл # 31012, по крайней мере, чтобы убедиться, что мы не протечем ни при каких обстоятельствах.
Разумеется, нам также необходимо изучить различные причины ошибок busy

Это кусало меня, сколько я себя помню. Я получил почти те же результаты, что и описанные выше, когда несколько дней назад я переключился на драйвер overlay2 и полностью уничтожил папку aufs ( docker system df говорит 1,5 ГБ, df говорит 15 ГБ) .

У меня было около 1Т различий с использованием хранилища. После перезапуска моего демона докеров я восстановил около 700 ГБ. Значит, я думаю, что остановка демона подрезает их?

К сожалению, перезапуск для меня ничего не делает.

Перезапуск службы не помог. Это серьезный вопрос. Удаление всех контейнеров / изображений не удаляет эти различия.

Остановка демона не приведет к их удалению.

Если вы удалите все контейнеры, но у вас все еще есть diff dirs, то, вероятно, у вас есть просочившиеся слои rw.

Мы только что столкнулись с этой проблемой. /var/lib/docker/aufs/diff занял 28 ГБ и увеличил нашу корневую файловую систему до 100%, что привело к тому, что наш сервер GitLab перестал отвечать. Мы используем докер для GitLab CI. Чтобы исправить это, я использовал некоторые из команд @sogetimaitral, предложенных выше, чтобы удалить временные файлы, и мы снова заработали. Я перезапустил сервер и отправил новую фиксацию для запуска CI, и, похоже, все работает так, как должно.

Я определенно обеспокоен тем, что это повторится снова. В чем дело? Это ошибка докера, которую нужно исправить?

1. Да, есть ошибка (и есть проблемы с удалением, и --force на rm игнорирует эти проблемы)
2. Как правило, не следует записывать много данных в контейнер fs, а вместо этого использовать том (даже одноразовый том). Большой каталог diff указывает на то, что в контейнер fs записываются значительные объемы данных.

Если вы не используете «--force» при удалении, вы не столкнетесь с этой проблемой (или, по крайней мере, вы увидите, что у вас есть куча «мертвых» контейнеров, и вы знаете, как / что очищать).

Я вообще не использую докер вручную. Мы используем gitlab-ci-multi-runner . Может быть, это ошибка на стороне GitLab?

Похоже (по умолчанию) он принудительно удаляет контейнеры; https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/dbdbce2848530df299836768c8ea01e209a2fe40/executors/docker/executor_docker.go#L878. Это может привести к тому, что не удастся удалить контейнер, который будет проигнорирован, и приведет к потерянным различиям.

Хорошо, тогда это говорит мне, что это ошибка gitlab-ci-multi-runner. Это правильная интерпретация? Я счастлив создать для них проблему, чтобы исправить это.

Думаю, это комбинация; "принудительное" удаление упрощает очистку (т.е. случаи, когда контейнер еще не остановлен и т. д.), в то же время (это упомянутая "ошибка" @ cpuguy83 ), оно также может скрывать актуальные проблемы, такие как docker не может удалить файловую систему контейнеров (что может иметь разные причины). В таких случаях емкость удаляется «силой». Без него контейнер остается (но помечен как «мертвый»).

Если бегун gitlab может правильно работать без принудительного удаления, это, вероятно, будет хорошо изменить (или сделать его настраиваемым)

Я использую Drone, и у меня такая же проблема. Я не проверял код, как удаляются контейнеры, но думаю, он тоже удаляется принудительно.

Может быть, проблема с Docker в Docker? Я запускаю Drone с помощью docker-compose.

Я решил пойти дальше и отправить проблему с gitlab-ci-multi-runner, чтобы просто зациклить разработчиков: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

Честно говоря, мы решили эту проблему, запустив Docker gc Spotify с помощью Drone CI.

Эль Эль Мар, мар. 28, 2017 в 15:38, Джеффри Фэйрчайлд <
[email protected]> подписка:

Я решил пойти дальше и отправить проблему gitlab-ci-multi-runner только для того, чтобы
зациклить разработчиков:
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/2304

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/docker/issues/22207#issuecomment-289926298 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AC6Wz197zkjWWOlq1-JOibiQP-xJym9Eks5rqYvegaJpZM4IMGt2
.

@sedouard Спасибо за этот совет! Ежечасный запуск docker-gc из Spotify решил проблему для меня.

У нас эта проблема запускается из Gitlab CI (не работает в докере), используя команды для создания образов / запуска контейнеров (не интеграция Gitlab CI Docker). Мы не используем никаких форм принудительного удаления, просто docker run --rm ... и docker rmi image:tag

РЕДАКТИРОВАТЬ : извините, на самом деле исходная проблема такая же. Разница в том, что запуск spotify/docker-gc _не_ устраняет проблему.

Как вы можете видеть ниже, у меня 0 изображений, 0 контейнеров, ничего!
docker system info согласен со мной, но упоминает Dirs: 38 для хранилища aufs.

Это подозрительно! Если вы посмотрите на /var/lib/docker/aufs/diff/ , мы увидим, что на самом деле там 1,7 ГБ данных, более 41 каталога. И это моя личная коробка, на рабочем сервере 19 ГБ.

Как это очистить? использование spotify/docker-gc не удаляет их.

philippe@pv-desktop:~$ docker images -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

philippe@pv-desktop:~$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

philippe@pv-desktop:~$ docker system info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 17.03.1-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 38
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 4ab9917febca54791c5f071a9d1f404867857fcc
runc version: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-72-generic
Operating System: Ubuntu 16.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 31.34 GiB
Name: pv-desktop
ID: 2U5D:CRHS:RUQK:YSJX:ZTRS:HYMV:HO6Q:FDKE:R6PK:HMUN:2EOI:RUWO
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: silex
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

philippe@pv-desktop:~$ ls -alh /var/lib/docker/aufs/diff/
total 276K
drwxr-xr-x 40 root root 116K Apr 13 15:32 .
drwxr-xr-x  5 root root 4.0K Sep 18  2015 ..
drwxr-xr-x  4 root root 4.0K Jun 17  2016 005d00efb0ba949d627ad439aec8c268b5d55759f6e92e51d7828c12e3817147
drwxr-xr-x  8 root root 4.0K May  2  2016 0968e52874bbfaa938ffc869cef1c5b78e2d4f7a670e19ef47f713868b9bfbdf
drwxr-xr-x  4 root root 4.0K Jun 20  2016 188233e6dcc37e2308e69807ffd19aca3e61be367daae921f2bcb15a1d6237d0
drwxr-xr-x  6 root root 4.0K Jun 20  2016 188233e6dcc37e2308e69807ffd19aca3e61be367daae921f2bcb15a1d6237d0-init
drwxr-xr-x 21 root root 4.0K Apr  8  2016 250ecb97108a6d8a8c41f9d2eb61389a228c95f980575e95ee61f9e8629d5180
drwxr-xr-x  2 root root 4.0K Dec 22  2015 291f16f99d9b0bc05100e463dbc007ef816e0cf17b85d20cf51da5eb2b866810
drwxr-xr-x  2 root root 4.0K May  2  2016 3054baaa0b4a7b52da2d25170e9ce4865967f899bdf6d444b571e57be141b712
drwxr-xr-x  2 root root 4.0K Feb  5  2016 369aca82a5c05d17006b9dca3bf92d1de7d39d7cd908ed665ef181649525464e
drwxr-xr-x  3 root root 4.0K Jun 17  2016 3835a1d1dfe755d9d1ada6933a0ea7a4943caf8f3d96eb3d79c8de7ce25954d2
(...strip)

philippe@pv-desktop:~$ du -hs /var/lib/docker/aufs/diff/
1.7G    /var/lib/docker/aufs/diff/

philippe@pv-desktop:~$ docker system prune -a
WARNING! This will remove:
    - all stopped containers
    - all volumes not used by at least one container
    - all networks not used by at least one container
    - all images without at least one container associated to them
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0 B

Могу ли я безопасно rm -r /var/lib/docker/aufs и перезапустить докер-деамон?

Запуск spotify/docker-gc не очищает этих сирот.

РЕДАКТИРОВАТЬ : спасибо @CVTJNII!

Остановка демона Docker и удаление всего / var / lib / docker будет безопаснее. Удаление / var / lib / docker / aufs в любом случае приведет к потере изображений, поэтому, на мой взгляд, лучше начать с чистого / var / lib / docker. Это «решение», которое я использую уже несколько месяцев для решения этой проблемы.

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

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

@ cpuguy83 : отличные новости, не могли бы вы объяснить, что нужно делать администратору, если это произойдет?

@Silex Это зависит от причины.
Обычно происходит ошибка device or resource busy из-за утечки некоторого монтирования в контейнер. Если вы используете что-то вроде cadvisor, это в значительной степени гарантия, как говорится в инструкции, для монтирования всего каталога докеров в контейнер cadvisor.

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

Если вы используете более новое ядро ​​(3.15+), маловероятно, что вы больше столкнетесь с проблемой, хотя все же может быть крайний случай.

Докер версии 17.06.0-ce, сборка 02c1d87

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

docker system prune -af
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc:ro spotify/docker-gc

Остались файлы:

root<strong i="11">@Dark</strong>:/var/lib/docker/aufs# ls -la *
diff:
total 92
drwx------ 12 root root 45056 Jul 28 17:28 .
drwx------  5 root root  4096 Jul  9 00:18 ..
drwxr-xr-x  4 root root  4096 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882
drwxr-xr-x  6 root root  4096 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882-init
drwxr-xr-x  5 root root  4096 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd
drwxr-xr-x  6 root root  4096 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd-init
drwxr-xr-x  4 root root  4096 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac
drwxr-xr-x  6 root root  4096 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac-init
drwxr-xr-x  4 root root  4096 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4
drwxr-xr-x  6 root root  4096 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4-init
drwxr-xr-x  6 root root  4096 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb
drwxr-xr-x  6 root root  4096 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb-init

layers:
total 52
drwx------ 2 root root 45056 Jul 28 17:28 .
drwx------ 5 root root  4096 Jul  9 00:18 ..
-rw-r--r-- 1 root root     0 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882
-rw-r--r-- 1 root root     0 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882-init
-rw-r--r-- 1 root root     0 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd
-rw-r--r-- 1 root root     0 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd-init
-rw-r--r-- 1 root root     0 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac
-rw-r--r-- 1 root root     0 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac-init
-rw-r--r-- 1 root root     0 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4
-rw-r--r-- 1 root root     0 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4-init
-rw-r--r-- 1 root root     0 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb
-rw-r--r-- 1 root root     0 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb-init

mnt:
total 92
drwx------ 12 root root 45056 Jul 28 17:28 .
drwx------  5 root root  4096 Jul  9 00:18 ..
drwxr-xr-x  2 root root  4096 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882
drwxr-xr-x  2 root root  4096 Jul 10 01:35 78f8ecad2e94fedfb1ced425885fd80bb8721f9fd70715de2ce373986785b882-init
drwxr-xr-x  2 root root  4096 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd
drwxr-xr-x  2 root root  4096 Jul 10 01:35 7caa9688638ea9669bac451b155b65b121e99fcea8d675688f0c76678ba85ccd-init
drwxr-xr-x  2 root root  4096 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac
drwxr-xr-x  2 root root  4096 Jul 12 14:45 b7b7770aae461af083e72e5e3232a62a90f934c83e38830d06365108e302e7ac-init
drwxr-xr-x  2 root root  4096 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4
drwxr-xr-x  2 root root  4096 Jul 10 01:35 d5752b27b341e17e730d3f4acbec04b10e41dc01ce6f9f98ff38208c0647f2e4-init
drwxr-xr-x  2 root root  4096 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb
drwxr-xr-x  2 root root  4096 Jul 10 01:35 e412d3c6f0f5f85e23d7a396d47c459f5d74378b474b27106ab9b82ea829dbfb-init

# docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              0                   0                   0B                  0B
Containers          0                   0                   0B                  0B
Local Volumes       0                   0                   0B                  0B

Как его удалить?

@ haos616 попробуйте docker system prune -af .
Это помогло мне.
Не получилось, пока у меня работал контейнер.

Если это обновление предыдущей версии докера, возможно, эти различия были сгенерированы / оставлены этой версией. Docker 17.06 не удалит контейнер, если не удалось удалить слои (при использовании --force); старые версии сделали, что могло привести к потерянным слоям

@ julian-pani Вначале я так и делал, но это не помогает.

# docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              0                   0                   0B                  0B
Containers          0                   0                   0B                  0B
Local Volumes       0                   0                   0B                  0B

@thaJeztah Нет. Я очищал Докер месяц или два назад. Тогда версия была уже 17.06. Я использовал команду docker system prune -af . Он удалил все.

Запуск https://github.com/spotify/docker-gc в качестве контейнера сработал для меня, но он сделал дополнительный шаг и удалил некоторые из моих необходимых изображений :(

Поэтому я поместил небольшой сценарий оболочки, как показано ниже, на всякий случай.

#!/bin/sh
docker images -q > /etc/docker-gc-exclude    # Save all genuine images as exclude
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc:ro spotify/docker-gc

еще раз спасибо за спотифай

IIUC, сценарий spotify просто вызывает docker rm и docker rmi - действительно ли он удалял потерянные различия?

Просто обратная связь для сообщества, я все это прочитал, и ни одно из решений на самом деле не работает стабильно или надежно. Мое «исправление» заключалось в том, чтобы просто удвоить объем дискового пространства на моих экземплярах AWS. И я слишком хорошо знаю, что это дрянное исправление, но это лучший обходной путь, который я нашел для раздутых aufs Docker. Это действительно нужно исправить.

@fuzzygroup 17.06 больше не должна создавать

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

https://gist.github.com/Karreg/84206b9711cbc6d0fbbe77a57f705979

https://stackoverflow.com/q/45798076/562769 кажется связанным. Я опубликовал быстрое исправление.

К вашему сведению, все еще вижу это с 17.06.1-ce

Containers: 20
 Running: 0
 Paused: 0
 Stopped: 20
Images: 124
Server Version: 17.06.1-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 185
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
runc version: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
init version: 949e6fa
Security Options:
 apparmor
Kernel Version: 4.4.0-83-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 7.796GiB
Name: gitlab-cirunner
ID: PWLR:R6HF:MK3Y:KN5A:AWRV:KHFY:F36D:WASF:7K7B:U7FY:2DJA:DBE2
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

/var/lib/docker/aufs/diff содержит множество каталогов с префиксом -init-removing и -removing :

ffd5477de24b0d9993724e40175185038a62250861516030a33280898243e742-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-init-removing
ffd900de0634992e99c022a16775805dfd0ffd1f6c89fece7deb6b1a71c5e38c-removing

К вашему сведению, все еще вижу это с 17.06.1-ce

Что именно вы все еще видите?
Не должно быть никакого способа утечки каталога diff, хотя каталоги diff все равно будут существовать, если они существовали при обновлении, они все еще будут существовать.

Насколько я могу судить, до сих пор вижу осиротевшие дифференциалы. docker system prune не удалил их, как и docker-gc . Запуск rm -rf /var/lib/docker/aufs/diff/*-removing вручную, похоже, работает.

Да, докер пока не очищает старые осиротевшие каталоги.

Под старыми вы имеете в виду те, которые были созданы из предыдущей версии докера с этой проблемой?

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

Я имею в виду, что за последние полчаса у меня есть 112 новых различий с -removing , так как я их вручную редактировал.

$ ls /var/lib/docker/aufs/diff/ | grep removing | wc -l
112

Вы сказали: «17.06 больше не должен создавать осиротевшие различия, но он пока не очищает старые», но, конечно, это не может быть правильным, или я что-то упускаю? Те, с тегом -removing не осиротели?

@orf В более новом ядре совершенно неожиданно возникают какие-либо проблемы при удалении. Вы устанавливаете /var/lib/docker в контейнер?

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

Мы не монтируем /var/lib/docker в контейнер.

$ uname -a
Linux gitlab-cirunner 4.4.0-83-generic #106~14.04.1-Ubuntu SMP Mon Jun 26 18:10:19 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

У нас работает 14.04 LTS

Дайте мне знать, если я могу что-нибудь предоставить, чтобы помочь отладить это.

По другим причинам (сеть в режиме роя) я перешел с 14.04 на Docker.
машины.
В понедельник, 21 августа 2017 г., в 8:23 orf [email protected] написал:

Мы не монтируем / var / lib / docker в контейнер.

$ uname -a
Linux gitlab-cirunner 4.4.0-83-generic # 106 ~ 14.04.1-Ubuntu SMP Пн 26 июня 18:10:19 UTC 2017 x86_64 x86_64 x86_64 GNU / Linux

У нас работает 14.04 LTS

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/moby/moby/issues/22207#issuecomment-323773033 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AADRIfE2B2HNpbsKyTOj1CwGzulRT2C0ks5saaDPgaJpZM4IMGt2
.

Похоже, что с 17.06.01-н.э. дела обстоят хуже. Я обновил машину сборки до этой версии и сразу же начал видеть каталоги *-init-removing и *-removing оставшиеся как часть процесса сборки. Я остановил службу, удалил каталог /var/lib/docker , перезапустил службу и после нескольких сборок снова был близок к нехватке места на диске. Я снова остановил службу, запустил apt-get purge docker-ce , снова удалил /var/lib/docker и установил версию 17.06.0-ce. Отсутствие дополнительных каталогов в /var/lib/docker/aufs/diff и дисковое пространство являются репрезентативными для образов, находящихся на машине сборки. Я также воспроизвел поведение на своей машине разработки - просто создание образа, кажется, создает эти дополнительные каталоги для каждого слоя образа, поэтому у меня очень быстро закончится дисковое пространство. Опять же, возврат к 17.06.0-ce, похоже, не вызывает проблем, поэтому я пока останусь там.

@mmanderson Спасибо за сообщение. Взглянем на изменения в драйвере AUFS.

@mmanderson Есть ли у вас контейнеры в состоянии Dead в docker ps -a ?

На всех моих серверах сборки докеров не хватает места.

Я обновился примерно за последнюю неделю до версии Docker 17.06.1-ce, сборка 874a737. Я считаю, что больше ничего не изменилось и что эта проблема возникла или проявилась в процессе обновления. Каталог aufs diff огромен, и я уже обрезал все изображения и болтающиеся тома.

issue-22207.txt
@ cpuguy83 Нет контейнеров ни в каком состоянии. Вот то, что я едва продемонстрировал в 17.06.01-CE:

1. Начат с новой установки docker 17.06.01-ce на Ubuntu 16.04.03 LTS (т.е. докер не установлен и нет каталога / var / lib / docker). После установки проверьте пустой каталог / var / lib / docker / aufs / diff.
2. Выполните сборку докеров с помощью довольно простого файла докеров на основе ubuntu: latest - все, что он делает, это извлекает statsd_exporter из github и извлекает его в / usr / bin (см. Прикрепленный файл).
3. После запуска сборки запустите docker ps -a чтобы не отображать ни одного состояния контейнеров. Есть несколько *-remaining папки в /var/lib/docker/aufs/diff папке.
4. Запустите docker system df чтобы проверить образы, контейнер и тома. Результат

TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              2                   0                   132.7MB             132.7MB (100%)
Containers          0                   0                   0B                  0B
Local Volumes       0                   0                   0B                  0B

1. Запуск du -sch /var/lib/docker/*/ показывает 152 /var/lib/docker/aufs/ за
2. Запустите docker rmi $(docker images -q) чтобы удалить созданные слои изображения. Запуск docker system df после этого показывает все нули. Запуск du -sch /var/lib/docker/*/ показывает 152M для /var/lib/docker/aufs/ и есть папки *-remaining для всех папок, в которых их раньше не было, а также существующие папки *-remaining которые все еще там.

@erikh , это проблема, с которой вы столкнулись?

@ cpuguy83 После удаления 17.06.01-ce, удаления каталога / var / lib / docker и установки 17.06.0-ce я пытаюсь запустить ту же сборку. Сбой сборки из-за ошибки ADD from remote URL's , исправленной в 17.06.01. Однако я не получаю никаких каталогов *-remaining для выполненных шагов, и после очистки всего с помощью docker system prune и docker rmi $(docker image -q) /var/lib/docker/aufs/diff каталог

Всем спасибо, это регресс 17.06.1 ...
PR для исправления находится здесь: https://github.com/moby/moby/pull/34587

здорово, спасибо за быстрый патч @ cpuguy83! / cc @erikh

@rogaha! да, спасибо тебе и @ cpuguy83!

Большое спасибо @Karreg за отличный сценарий . После того, как мы избавились от всех старых ophaned diff и снова освободили огромное количество потерянного дискового пространства, мы теперь регулярно используем его для очистки наших виртуальных машин перед установкой новых образов докеров. Отличная помощь и почти идеальный способ решения этой проблемы. @ TP75

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

Сценарий @Karreg у меня отлично сработал, и я освободил все пространство в каталоге diffs.

Имея ту же проблему.
Детали хоста Docker

root @ UbuntuCont : ~ # информация о докере
Контейнеры: 3
Бег: 0
Приостановлено: 0
Остановлено: 3
Фото: 4
Версия сервера: 17.06.1-ce
Драйвер хранилища: aufs
Корневой каталог: / var / lib / docker / aufs
Резервная файловая система: extfs
Режиссеры: 14
Dirperm1 Поддерживается: true
Драйвер логирования: json-файл
Драйвер Cgroup: cgroupfs
Плагины:
Объем: местный
Сеть: мостовой хост macvlan нулевое наложение
Журнал: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Рой: неактивен
Время выполнения: runc
Время выполнения по умолчанию: runc
Двоичный файл инициализации: docker-init
версия containerd: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
версия runc: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
версия инициализации: 949e6fa
Параметры безопасности:
Apparmor
seccomp
Профиль: по умолчанию
Версия ядра: 4.4.0-93-generic
Операционная система: Ubuntu 16.04.3 LTS
OSType: linux
Архитектура: x86_64
Процессоры: 1
Общий объем памяти: 3,358 ГБ
Имя: UbuntuCont
ID: QQA5: DC5S: C2FL: LCC6: XY6E: V3FR: TRW3: VMOQ: QQKD : AP2M: H3JA: I6VX
Корневой каталог Docker: / var / lib / docker
Режим отладки (клиент): false
Режим отладки (сервер): false
Реестр: https://index.docker.io/v1/
Экспериментальный: ложь
Небезопасные реестры:
127.0.0.0/8
Live Restore Enabled: false

корень @ UbuntuCont : / var / lib / docker / aufs / diff # ls
031c85352fe85f07fede77dee0ac9dc2c7723177a819e72c534e1399208c95fa
09d53040e7e6798b5987ea76fe4f84f0906785b94a392a72e8e41a66cd9f242d
09d53040e7e6798b5987ea76fe4f84f0906785b94a392a72e8e41a66cd9f242d-init
0fb1ffc90969e9706801e2a18870f3ecd857a58f1094fbb968b3fa873e4cf2e4
10549179bd21a9c7af018d4ef305bb9196413b9662fce333b607104c40f38781
10d86a48e03cabf9af2c765dc84824809f24674ac339e4b9ffe572f50bd26b9c-init-удаление
10d86a48e03cabf9af2c765dc84824809f24674ac339e4b9ffe572f50bd26b9c-удаление
2e226946e8e6c2b3613de2afcff4cbb9890b6d9bd365fdda121a51ae96ec5606
2e226946e8e6c2b3613de2afcff4cbb9890b6d9bd365fdda121a51ae96ec5606-init
3601f6953132f557df8b52e03016db406168d3d6511d7ff5c08a90925ea288da-init-удаление
3601f6953132f557df8b52e03016db406168d3d6511d7ff5c08a90925ea288da-удаление
4b29141243aea4e70472f25a34a91267ab19c15071862c53e903b99740603d4c-init-удаление
4b29141243aea4e70472f25a34a91267ab19c15071862c53e903b99740603d4c-удаление
520e3fcf82e0fbbb48236dd99b6dee4c5bb9073d768511040c414f205c787dc5-init-удаление
520e3fcf82e0fbbb48236dd99b6dee4c5bb9073d768511040c414f205c787dc5-удаление
59cbb25a4858e7d3eb9146d64ff7602c9abc68509b8f2ccfe3be76681481904f
5d1c661b452efce22fe4e109fad7a672e755c64f538375fda21c23d49e2590f6
605893aba54feee92830d56b6ef1105a4d2166e71bd3b73a584b2afc83319591
63bd53412210f492d72999f9263a290dfee18310aa0494cb92e0d926d423e281-init-удаление
63bd53412210f492d72999f9263a290dfee18310aa0494cb92e0d926d423e281-удаление
72146e759ab65c835e214e99a2037f4b475902fdbe550c46ea0d396fb5ab2779-init-удаление
72146e759ab65c835e214e99a2037f4b475902fdbe550c46ea0d396fb5ab2779-удаление
8147e0b06dcbce4aa7eb86ed74f4ee8301e5fe2ee73c3a80dcb230bd0ddfcc26-init-удаление
8147e0b06dcbce4aa7eb86ed74f4ee8301e5fe2ee73c3a80dcb230bd0ddfcc26-удаление
a72735551217bb1ad01b77dbdbb9b8effa9f41315b0c481f8d74b5606c50deb4
aa58f2000b9f7d1ed2a6b476740c292c3c716e1d4dc04b7718580a490bba5ee8
b552cb853e33a8c758cb664aec70e2c4e85eacff180f56cbfab988a8e10c0174-удаление
cd80c351b81ed13c4b64d9dfdc20c84f6b01cbb3e26f560faf2b63dae12dec55-init-удаление
cd80c351b81ed13c4b64d9dfdc20c84f6b01cbb3e26f560faf2b63dae12dec55-удаление
fe903be376821b7afee38a016f9765136ecb096c59178156299acb9f629061a2
fe903be376821b7afee38a016f9765136ecb096c59178156299acb9f629061a2-init

@kasunsjc, пожалуйста, прочтите сообщения чуть выше вашего.

Подтверждаю, что обновление до 17.06.2-ce решило эту проблему. Мне тоже не пришлось вручную каталоги (в прошлый раз) после обновления.

17.06.2-ce _ кажется_ исправил это и для меня. Здесь больше нет каталогов -removing вернулось приличное количество места.

Я предполагаю, что каталоги -init меня есть в aufs/diff , не связаны (некоторые из них довольно старые). Но все они маленькие, так что это не имеет значения.

Обновление до 17.07.0 решило проблему и здесь, даже docker system prune --all -f не удалял каталоги раньше, но после обновления они автоматически удалялись при перезагрузке.

Подтверждение, что эта проблема была решена в Ubuntu 16.04 с 17.06.2-ce. Как только обновился, пространство очистилось.