清理docker产生的垃圾文件_davidhopper的博客_清理docker缓存

link之家

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

相关文章推荐

慷慨大方的胡萝卜 · K3终极折腾记＜一＞_k3刷openwrt- ...· 5 天前 ·

苦恼的洋葱 · 90后这些女演员，有戏 - 知乎· 1 年前 ·

睿智的甜瓜 · 《唐顿庄园2》上映，取景地曝光！从英式庄园到 ...· 1 年前 ·

眼睛小的热带鱼 · 2004年，周星驰弃用了洪金宝，拍出此片，完 ...· 1 年前 ·

博学的鸵鸟 · 1.85秒破百！Rimac Concept ...· 1 年前 ·

伤情的核桃 · 决战新势力造车2.0时代，电动屋的DOCK模 ...· 1 年前 ·

无意中感觉磁盘空间不够用，于是使用 df -a 命令查看，结果令人大吃一惊，全是docker干的好事，在 /var/lib/docker/aufs 里生成了一堆垃圾：

davidhopper@davidhopper-ThinkPad-P50s:~$ df -a
文件系统          1K-块     已用    可用 已用% 挂载点
sysfs                 0        0       0     - /sys
proc                  0        0       0     - /proc
udev            8112832        0 8112832    0% /dev
devpts                0        0       0     - /dev/pts
tmpfs           1627828     9580 1618248    1% /run
/dev/sda6      84293120 77948404 2039772   98% /
securityfs            0        0       0     - /sys/kernel/security
tmpfs           8139124    18040 8121084    1% /dev/shm
tmpfs              5120        4    5116    1% /run/lock
tmpfs           8139124        0 8139124    0% /sys/fs/cgroup
cgroup                0        0       0     - /sys/fs/cgroup/systemd
pstore                0        0       0     - /sys/fs/pstore
efivarfs              0        0       0     - /sys/firmware/efi/efivars
cgroup                0        0       0     - /sys/fs/cgroup/net_cls,net_prio
cgroup                0        0       0     - /sys/fs/cgroup/perf_event
cgroup                0        0       0     - /sys/fs/cgroup/cpu,cpuacct
cgroup                0        0       0     - /sys/fs/cgroup/pids
cgroup                0        0       0     - /sys/fs/cgroup/devices
cgroup                0        0       0     - /sys/fs/cgroup/cpuset
cgroup                0        0       0     - /sys/fs/cgroup/rdma
cgroup                0        0       0     - /sys/fs/cgroup/blkio
cgroup                0        0       0     - /sys/fs/cgroup/hugetlb
cgroup                0        0       0     - /sys/fs/cgroup/freezer
cgroup                0        0       0     - /sys/fs/cgroup/memory
systemd-1             -        -       -     - /proc/sys/fs/binfmt_misc
debugfs               0        0       0     - /sys/kernel/debug
mqueue                0        0       0     - /dev/mqueue
hugetlbfs             0        0       0     - /dev/hugepages
fusectl               0        0       0     - /sys/fs/fuse/connections
configfs              0        0       0     - /sys/kernel/config
/dev/sda1        262144    33084  229060   13% /boot/efi
binfmt_misc           0        0       0     - /proc/sys/fs/binfmt_misc
tmpfs           1627828       56 1627772    1% /run/user/1000
gvfsd-fuse            0        0       0     - /run/user/1000/gvfs
/dev/sda6      84293120 77948404 2039772   98% /var/lib/docker/aufs

首先使用最简单的方法，清理当前未运行的所有Docker容器：

docker system prune

运行结果如下：

davidhopper@davidhopper-ThinkPad-P50s:~/code/apollo$ docker system prune
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 dangling images
Are you sure you want to continue? [y/N] y
Deleted Volumes:
333739e346364a7d515cdfc585f5231dd7f74a9e71431d152f6efc4da3bcb303
419184335b3c6130cb47b98c672e9666479ef0ff27cd2d20e173b55800507052
94165565a1f9d0553d18de62f86264596747f1b38c651b5e4f68391607e8453d
08d67461fa141609d0905f1209526131ce60864d1bf27650511a6bcc88197107
3aeb8f32513a1813f6b50726a233f16b20bb896b5cf3e51197c86e2cc10be374
3af830103bdedc7f035be9d2bdbd1104733c274f3ce629784cdf9daee8ac070e
78e7ab8000386d61050034a64eee041a2743b60c466598286f276534529db551
155c34c18faf8d234412a999b28d1d6de8517b68eac5dc47e58964a0efb24a06
200d23a03f40cb1b8af8e5368805370d45195448fbad0944bcb9730f2140d462
51b2e0825e25de4c42475245a83b2119ce45e75da811ad6df1525f7ff2888a36
559532c3877cf5641e21c15fca6d923266b6548a4aef834667b0c66ca78cde38
a05cf184006b1301eb91e2ebcb9cca6d5868265f56bdac0aefd5228979fd8c74
c21d336b8205ea12e27414c3a00eef6a329222ea7552b825d3889ef042783820
3e573f8d84fd7923415b46a90017ff5cfeb2bd2931e4ec54c45c4bd62664042d
3ee39b3a5e49b605d4069e99c4c1d01db6a210d28cbdc350672b33accd2b0f3b
a0fe3e6d80b6fb4dc6ca2159789e512912fb4ffccd0df1183bafc55c4e804563
3e062023110a4c13e7915da03ffaad3dbaa558c590a6b2274c2fb09ad54abd6c
69276b6274956a28abfe50fdf459a0042ecba6978e379e035399c9272c930b57
de1a0669765d765699b47999c59ed74f93fc0545fe8d280cefdd2cf9e2b31379
33766d8c693b826d9da48d419c15b90fcfbac26eb9939749aef94218a31a767b
45a2047d0581ad07ebd0164e69897f5ae99144a4f0422b72f184281ae47e0b4d
7191a9c6cea03c4aa1aac1c742228c46e3d7e2577645a037d62600be7249a649
7b45e555bca1d941af284743396753199f7bea33e7bf3f3362f385ec074b4450
08cb6f6b2c1d83796e9bcdd6eb6d2930ba80f98721ed1215d9bd6c75148a2608
0a786b212dc4e76225ae3e90dfd92c6eba5a4f60f465d86e62990fe22311ba1c
2a50f3203d93d60e115ec3b3ba643b3213f98d3c793730332de0178a9f7b5c45
3b50fae52487f178325d0347f75eb2502195daf5e39ba156a37752d3d62cd915
9067fa92cee1da6d1044ce51d616dc0cad67ac31e16f4f208ba840599dcb0b21
cb07e29eabcbb62bbcbe13443267a96599747ca52b685a71b7233cf94d876d38
67c55c6079ff257be64a59ee83d08c463591aebd5496dd1f134c33205d9f5c12
0a994bec4d112f6b012b7be4f5b7ad25c557c01f4392cf02546eceb697913240
90d85444a338c247414adc209e42a46c89d30cc9c1c52d29c0d63a5e35b5d70c
ec2bb3abb42e7450005e9c9b30305a5763e44dc03a70f313062d57ef8062b10a
09d99b0fd826d7463c1816228953c0492107916283de2b1ccb7fa8e22c2de324
1ad2def94eaa92707b9cf3b7ef288b57c64cff0094103f776657aaeacae8c939
92f633c27c6796091311e83617d4fb3b1526689b5b6ada33f58214ffa80c1f5e
053bacc4b3bf55149f918368238ffe50c1ed777558092b7b883b2cda2b7a0313
15118045d54acb0e63c0ebd4460a1a1666b3c930b95d351a1b831419eb3f2226
2852c53d5b177522c67ffd9d916d66328ede26275c27a80745812b1c28b8d47f
abe49f612dc9e8250f464772c726850415a051562ffcd922dc796a71bb94d061
6927af521e03ec75a09dbfe0a86bbf69928773841c538a2fc094bc4368bd3138
6d97a92956067706ba5d8ac9d01e99294d8ca28e4182a81c0662f77faf8e372b
8496afb1946e3f5863a23c8394f4065293e26dbc2555bf474d0328f56a613331
829e41a7d593b75633868c72bb81123d32f2a14b656f1409c57da6bc984fa233
9205da799d47bc613bf7b1955ea78712f16b4edf2a79b450f55ffb6111dee609
923a72e6bde7fb13fae29995611f9d28b0bdd4cf6a53250c45006edbe795d120
e31e6d693398b033843b0ad9cfceec09b9e1b47f7a9f4b2bec275e5e6a23fa3b
0163e1b3e1d90e20410e33b5d95eec75b55819c1117fdd57c655c31ed589f524
479c0acef02c7b1ddcb5863198868f71b6b2f3275146de73f9c884a9f50dd32e
7a231567bbc73d11621d34cdacc45061cfe060e78210782e18fec100578fe56a
Total reclaimed space: 26.96GB

如果空间释放得还够多，就想办法删除 /var/lib/docker/aufs 文件夹，最朴素的想法是直接删除：

sudo rm -rf /var/lib/docker/aufs

结果令人失望，提示信息如下：

davidhopper@davidhopper-ThinkPad-P50s:~$ sudo rm -rf /var/lib/docker/aufs
[sudo] davidhopper 的密码： 
rm: 无法删除'/var/lib/docker/aufs': 设备或资源忙

用命令 cat /proc/mounts | grep "docker" 查找设备加载情况，果然有aufs：

davidhopper@davidhopper-ThinkPad-P50s:~$ cat /proc/mounts | grep "docker"
/dev/sda6 /var/lib/docker/aufs ext4 rw,relatime,errors=remount-ro,data=ordered 0 0

没办法，逼我用绝招，先缷载设备，再删除之：

sudo umount /var/lib/docker/aufs
sudo rm -rf /var/lib/docker/aufs

再次使用 df -a 命令查看，结果令人神清气爽：

davidhopper@davidhopper-ThinkPad-P50s:~$ df -a
文件系统          1K-块     已用     可用 已用% 挂载点
sysfs                 0        0        0     - /sys
proc                  0        0        0     - /proc
udev            8112832        0  8112832    0% /dev
devpts                0        0        0     - /dev/pts
tmpfs           1627828     9584  1618244    1% /run
/dev/sda6      84293120 65296764 14691412   82% /
securityfs            0        0        0     - /sys/kernel/security
tmpfs           8139124    18256  8120868    1% /dev/shm
tmpfs              5120        4     5116    1% /run/lock
tmpfs           8139124        0  8139124    0% /sys/fs/cgroup
cgroup                0        0        0     - /sys/fs/cgroup/systemd
pstore                0        0        0     - /sys/fs/pstore
efivarfs              0        0        0     - /sys/firmware/efi/efivars
cgroup                0        0        0     - /sys/fs/cgroup/net_cls,net_prio
cgroup                0        0        0     - /sys/fs/cgroup/perf_event
cgroup                0        0        0     - /sys/fs/cgroup/cpu,cpuacct
cgroup                0        0        0     - /sys/fs/cgroup/pids
cgroup                0        0        0     - /sys/fs/cgroup/devices
cgroup                0        0        0     - /sys/fs/cgroup/cpuset
cgroup                0        0        0     - /sys/fs/cgroup/rdma
cgroup                0        0        0     - /sys/fs/cgroup/blkio
cgroup                0        0        0     - /sys/fs/cgroup/hugetlb
cgroup                0        0        0     - /sys/fs/cgroup/freezer
cgroup                0        0        0     - /sys/fs/cgroup/memory
systemd-1             -        -        -     - /proc/sys/fs/binfmt_misc
debugfs               0        0        0     - /sys/kernel/debug
mqueue                0        0        0     - /dev/mqueue
hugetlbfs             0        0        0     - /dev/hugepages
fusectl               0        0        0     - /sys/fs/fuse/connections
configfs              0        0        0     - /sys/kernel/config
/dev/sda1        262144    33084   229060   13% /boot/efi
binfmt_misc           0        0        0     - /proc/sys/fs/binfmt_misc
tmpfs           1627828       52  1627776    1% /run/user/1000
gvfsd-fuse            0        0        0     - /run/user/1000/gvfs

为了让docker以后不再占用更多空间，我们指定docker目录的最大空间，命令如下：

mkdir -p /var/lib/docker/devicemapper/devicemapper  
dd if=/dev/zero of=/var/lib/docker/devicemapper/devicemapper/data bs=1M count=0 seek=1024

建立的文件最大尺寸为 1MB * 1024 = 10 GB

如果删除垃圾文件后，导致Docker无法使用，则可使用如下方法将相关文件全部删除，然后重新安装Docker。删除相关文件的方法如下：

查找Docker缓存文件位置

sudo find / -name "docker"

在我机器上结果如下：

/sys/fs/cgroup/memory/docker
/sys/fs/cgroup/blkio/docker
/sys/fs/cgroup/hugetlb/docker
/sys/fs/cgroup/pids/docker
/sys/fs/cgroup/cpuset/docker
/sys/fs/cgroup/perf_event/docker
/sys/fs/cgroup/devices/docker
/sys/fs/cgroup/net_cls,net_prio/docker
/sys/fs/cgroup/freezer/docker
/sys/fs/cgroup/cpu,cpuacct/docker
/sys/fs/cgroup/systemd/docker
/etc/default/docker
/etc/docker
/etc/init.d/docker
/var/lib/docker
/run/docker
find: `/run/user/1000/gvfs': 权限不够
/usr/lib/docker
/usr/share/code/resources/app/extensions/docker
/usr/share/bash-completion/completions/docker
/usr/bin/docker
/home/davidhopper/Qt5.10.0/5.10.0/Src/qtwebengine/src/3rdparty/chromium/third_party/protobuf/jenkins/docker
/home/davidhopper/.cache/bazel/_bazel_davidhopper/install/5b1e8be5d1d6766f635a7db5967707e9/_embedded_binaries/embedded_tools/tools/build_defs/docker
/home/davidhopper/.vscode/extensions/njpwerner.autodocstring-0.2.0/.vscode-test/Visual Studio Code.app/Contents/Resources/app/extensions/docker
/home/davidhopper/code/apollo/docker
/home/davidhopper/code/protobuf-master/jenkins/docker
/home/davidhopper/code/apollo1215/apollo/docker

2.删除Docker缓存

sudo rm -rf /home/davidhopper/.cache/bazel/_bazel_davidhopper/install/5b1e8be5d1d6766f635a7db5967707e9/_embedded_binaries/embedded_tools/tools/build_defs/docker

Docker file生成镜像的时候是如何缓存的？比如我安装一个东西耗时两个小时，但是构建成功之后再构建一次他就很快了，说明它缓存了，现在我的疑惑是如果我稍微改变了一点东西，如何保证他不需要在再耗时两个小时。 docker build过程中每执行一步RUN命令，就生成一个镜像，另外镜像之间有血缘关系，

1.镜像缓存1.镜像缓存：在构建或者下载镜像时候，当镜像层已经存在的时候，直接使用使用缓存，不需要进行重新构建镜像，如果我们希望在构建镜像时不使用缓存，可以在 docker build 命令中加上 –no-cache 参数。如果我们改变 Docker file 指令的执行顺序，或者修改或添加指令，都会使缓存失效。 2. Docker file 在执行的时候，当有执行过相同的代码并且顺序也一致的情况下，

<div class="post-text" itemprop="text"> Is it possible to force Docker to cache a directory? I would like to do this because I am using vendoring in Go 1.6 (via <a href="https://glide.sh" rel="nofollow">Glide</a>) and a majority of my build times are spent fetching the same dependencies as the previous build. If there is a way of forcing Docker to cache a directory, is there any way to let Docker know when to invalidate the cache (ex., when <code>glide.lock</code> changes)?