很多时候，当我们Docker镜像打包完成后，莫名的镜像大小增加了很多，但是当我们进入到容器内部时，发现容器内部实际占用空间却很小，即很多的空间是被浪费！
究其原因其实是因为，Docker是分层build的（这点大家想必都知道），而中间层执行了某些操作后，我们以为资源被释放了（比如RUN rm xxx），其实可能并没有！
一、先看一下现象
我的有个项目，实际内容的文件只有500M+，加上基础镜像200M+，期望的镜像大小应该是800M左右，但是实际镜像大小如下：
[root@ck102 datacollector-docker]# docker images|grep v10 jiguiquan_datathread v10 b53fcc520771 3 hours ago 1.37GB
是不是实际文件就很多，或者文件在镜像里面重复存在了呢，我们运行项目后，进去看看（如果真的是文件重复了，删除掉即可）：
[root@ck102 datacollector-docker]# docker exec -it -u root mydtv10 /bin/bash bash-5.1# du -h -d 1 1.9M ./bin 0 ./dev 800.0K ./etc 4.0K ./home 4.6M ./lib 0 ./media 0 ./mnt 741.7M ./opt 0 ./proc 0 ./root 0 ./run 92.0K ./sbin 0 ./srv 0 ./sys 36.0K ./tmp 19.6M ./usr 0 ./var 28.0K ./logs 20.0K ./data 0 ./resources 0 ./lib64 768.8M .
可以看到，容器内的文件其实只有768M，那么多出来的600M+到底浪费在哪儿了？
如果没有一个很好的工具，是很难去排查问题的，docker history看到的内容也是很粗粒度的！
二、下载并安装Dive工具
1、Ubuntu/Debian：
wget https://github.com/wagoodman/dive/releases/download/v0.9.2/dive_0.9.2_linux_amd64.deb sudo apt install ./dive_0.9.2_linux_amd64.deb
2、RHEL/Centos：
curl -OL https://github.com/wagoodman/dive/releases/download/v0.9.2/dive_0.9.2_linux_amd64.rpm rpm -i dive_0.9.2_linux_amd64.rpm
3、基于docker安装，因为我们的环境肯定此时已经是有docker的：
docker run --rm -it \ -v /var/run/docker.sock:/var/run/docker.sock \ -v "$(pwd)":"$(pwd)" \ -w "$(pwd)" \ -v "$HOME/.dive.yaml":"$HOME/.dive.yaml" \ wagoodman/dive:latest jiguiquan_datathread:v10
其中：wagoodman/dive:latest是安装的dive镜像，
而jiguiquan_datathread:v10就是我们将要分析的镜像！
三、Dive工具的使用
1、先查看Dive的界面：
可以看到，整个镜像，以及每一层都被详细地分析出来了：
-
镜像有效空间占比只有58%，我们的目标要将镜像占比优化到90%以上！
2、Dive工具的常用命令：
-
Crtl+C ：退出
-
Tab ：切换左边的Layers和右边的Current Layer Contents
-
Crtl+L ：显示某一层的文件变更
-
Crtl+A ：显示所有的文件变更
-
Crtl+A ：显示该层增加的文件（Tab键切换到Current Layer Contents生效）
-
Crtl+R ：显示该层删除的文件（Tab键切换到Current Layer Contents生效）
-
Crtl+M ：显示该层修改的文件（Tab键切换到Current Layer Contents生效）
-
Crtl+B ：显示该层文件的详细属性信息（Tab键切换到Current Layer Contents生效）
四、优化后的效果
具体Docker镜像大小优化的常见思路，会在另一篇博文中描述（这种优化就是一点点进行的，没有固定套路，不同的情况不同处理）
经过镜像打包Dockerfile以及脚本的优化，最终成功将进行大小优化到800M：
[root@ck102 datacollector-docker]# docker images|grep v14 jiguiquan_datathread v14 442ad1c76659 2 hours ago 800MB
通过Dive查看空间利用率：
达到了惊人的99%，显然已经没有进一步优化的空间了！☺
