Почему новый контейнер на маленьком образе докера говорит, что его диск заполнен 10 ГБ, а это не так?
Я запускаю это в Debian 10 AppVM в QubesOS. В Debian 10 я делаю:
sudo apt-get -y install docker.io
sudo docker pull node:13-buster-slim
На момент написания это дает мне docker v18.09.1, по умолчанию использующий драйвер хранилища overlay2.
root@coviz:~# sudo docker --version
Docker version 18.09.1, build 4c52b90
root@coviz:~# docker info | grep Storage
Storage Driver: overlay2
root@coviz:~#
У моего хоста докеров теперь есть только этот образ докера 181M без контейнеров. Хост-докер использует только 0,5 ГБ из доступных 20 ГБ. Много свободного места.
root@coviz:~# sudo docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
root@coviz:~# sudo docker image ls -a
REPOSITORY TAG IMAGE ID CREATED SIZE
node 13-buster-slim e4217af9b7c7 9 days ago 181MB
root@coviz:~# sudo docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 1 0 180.7MB 180.7MB (100%)
Containers 0 0 0B 0B
Local Volumes 0 0 0B 0B
Build Cache 0 0 0B 0B
root@coviz:~#
Я работаю над созданием Dockerfile для своего проекта, поэтому я выполняю следующую команду, чтобы развернуть новый контейнер из приведенного выше базового изображения и поместить меня в оболочку на этом временном контейнере.
root@coviz:~# docker run --rm -it --entrypoint /bin/bash e4217af9b7c7
root@97a318c599ab:/#
Вскоре я столкнулся с проблемами при тестировании команд для установки зависимостей с помощью apt-get. Я думаю, проблема в том, что apt нужно хранить данные кеша в /var/lib/apt/lists/. Фактическая ошибка at least one invalid signature was encountered, но на самом деле это проблема с заполнением диска (проверка ключа apt не выполняется, потому что не удается сохранить подпись на диске). Запуск apt-clean не помогает; он уже пуст. Это свежая тара на основе свежего образа.
Проверка диска с помощью df в этом новом контейнере сразу показывает, что доступно только 17 МБ дискового пространства, но я могу учитывать только ~ 200 МБ с du. Опять же, это свежий контейнер, поэтому я очень сомневаюсь, что это проблема с файлом, застрявшим в состоянии «удаление», все еще открытым процессом.
root@97a318c599ab:/# df -h
Filesystem Size Used Avail Use% Mounted on
overlay 9.6G 9.1G 17M 100% /
tmpfs 64M 0 64M 0% /dev
tmpfs 255M 0 255M 0% /sys/fs/cgroup
/dev/xvda3 9.6G 9.1G 17M 100% /etc/hosts
shm 64M 0 64M 0% /dev/shm
tmpfs 285M 0 285M 0% /proc/asound
tmpfs 285M 0 285M 0% /proc/acpi
tmpfs 285M 0 285M 0% /proc/scsi
tmpfs 285M 0 285M 0% /sys/firmware
root@97a318c599ab:/# du -sh /*
4.8M /bin
4.0K /boot
0 /dev
612K /etc
20K /home
12M /lib
4.0K /lib64
4.0K /media
4.0K /mnt
5.2M /opt
du: cannot access '/proc/11/task/11/fd/4': No such file or directory
du: cannot access '/proc/11/task/11/fdinfo/4': No such file or directory
du: cannot access '/proc/11/fd/4': No such file or directory
du: cannot access '/proc/11/fdinfo/4': No such file or directory
0 /proc
136K /root
8.0K /run
4.1M /sbin
4.0K /srv
0 /sys
2.2M /tmp
160M /usr
5.9M /var
root@97a318c599ab:/#
Более того, docker ps -s показывает, что размер "записываемого слоя" в моем контейнере пуст (0B):
root@coviz:~# docker ps -a -s
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES SIZE
320af1498086 e4217af9b7c7 "docker-entrypoint.s…" 15 minutes ago Up 15 minutes epic_leakey 0B (virtual 181MB)
root@coviz:~#
Так почему же диск этого нового док-контейнера (на основе образа размером ~ 200 МБ) заполнен? Что занимает эти ~ 9 ГБ неучтенного пространства?
Это проблема, связанная с тем, как QubesOS также размещает свое дисковое пространство для AppVM.
Это было дисковое пространство на хосте докеров (Debian 10 AppVM). Обратите внимание, что его 20 ГБ свободного дискового пространства находятся в /rw/ но доступное дисковое пространство подключено к / то же самое, что сообщалось внутри контейнера.
user@coviz:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda3 9.6G 9.1G 17M 100% /
none 9.6G 9.1G 17M 100% /usr/lib/modules
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.0G 0 1.0G 0% /dev/shm
tmpfs 777M 17M 760M 3% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 776M 0 776M 0% /sys/fs/cgroup
/dev/xvdb 20G 418M 20G 3% /rw
tmpfs 32M 12K 32M 1% /run/user/1000
user@coviz:~$
Решение было добавить конфигурацию к /rw/config/qubes-bind-dirs.d/ это связывает докеры '/var/lib/docker и /etc/docker в /rw/. Это не только фактически дает контейнерам докеров доступ к большему «частному хранилищу» Qubes, но также делает это хранилище постоянным при перезагрузках.
Вышесказанное может быть достигнуто, выполнив следующее на вашей Debian 10 AppVM:
sudo mkdir -p /rw/config/qubes-bind-dirs.d
sudo cat << EOF > /rw/config/qubes-bind-dirs.d/50_user.conf
binds+=( '/var/lib/docker' )
binds+=( '/etc/docker' )
EOF
В Qubes> = r4.0 qubes-bind-dirs. переехал из /rw/config/ к /usr/lib/ [1]:
sudo mkdir -p /usr/lib/qubes-bind-dirs.d
sudo cat << EOF > /usr/lib/qubes-bind-dirs.d/50_user.conf
binds+=( '/var/lib/docker' )
binds+=( '/etc/docker' )
EOF
А затем перезагрузите AppVM. Когда он вернется, это будет примерно так:
root@coviz:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda3 9.6G 8.9G 217M 98% /
none 9.6G 8.9G 217M 98% /usr/lib/modules
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.0G 0 1.0G 0% /dev/shm
tmpfs 777M 17M 760M 3% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 776M 0 776M 0% /sys/fs/cgroup
/dev/xvdb 20G 617M 20G 4% /rw
tmpfs 32M 12K 32M 1% /run/user/1000
root@coviz:~# docker run --rm -it --entrypoint /bin/bash e4217af9b7c7
root@66766a23ca1b:/# df -h
Filesystem Size Used Avail Use% Mounted on
overlay 20G 618M 20G 4% /
tmpfs 64M 0 64M 0% /dev
tmpfs 246M 0 246M 0% /sys/fs/cgroup
/dev/xvdb 20G 618M 20G 4% /etc/hosts
shm 64M 0 64M 0% /dev/shm
tmpfs 274M 0 274M 0% /proc/asound
tmpfs 274M 0 274M 0% /proc/acpi
tmpfs 274M 0 274M 0% /proc/scsi
tmpfs 274M 0 274M 0% /sys/firmware
root@66766a23ca1b:/#