为什么小型 docker 镜像上的新容器显示其磁盘已满 10G 但实际上并非如此?
我在 QubesOS 中的 Debian 10 AppVM 中运行它。在 Debian 10 中,我执行以下操作:
sudo apt-get -y install docker.io
sudo docker pull node:13-buster-slim
在撰写本文时,这为我提供了默认使用“overlay2”存储驱动程序的 docker v18.09.1。
root@coviz:~# sudo docker --version
Docker version 18.09.1, build 4c52b90
root@coviz:~# docker info | grep Storage
Storage Driver: overlay2
root@coviz:~#
我的 docker 主机现在只有这个 181M 的 docker 镜像,没有容器。docker 主机只使用了 20G 可用空间中的 0.5G。有足够的可用空间。
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,因此我执行以下命令从上面的基础镜像启动一个新容器,并将我放入该临时容器的 shell 中
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
立即显示只有 17M 的可用磁盘空间,但我只能用 ~200M 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:~#
那么为什么这个新的 docker 容器的磁盘(基于约 200M 的镜像)已满?是什么占用了这约 9G 的未占用空间?
答案1
这是 QubesOS 为 AppVM 分层磁盘空间方式的一个问题。
这是 docker 主机(Debian 10 AppVM)上的磁盘空间。请注意,其可用磁盘空间为 20G,/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/
将 docker 目录'/var/lib/docker
和/etc/docker
into绑定在一起/rw/
。这不仅实际上使 docker 容器能够访问 Qubes 更大的“私有存储”,而且还使该存储在重启后仍然有效。
通过在 Debian 10 AppVM 上执行以下操作即可实现上述目标:
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' )
binds+=( '/root/.docker' )
EOF
在旧版本的 QubesOS (< r4.0) 中qubes-bind-dirs.d
,/rw/config/
[1]:
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' )
binds+=( '/root/.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:/#