docker镜像优化小手段

前言

在docker已经成为标配的时代&＃xff0c;镜像的优化建议大家都耳熟能详&＃xff0c;如指令串联减少layer的层&＃xff0c;使用更小的基础镜像等等。而在实际使用过程中&＃xff0c;生成出来的镜像从100MB到1GB大小都有&＃xff0c;大家都觉得已经按照建议优化了&＃xff0c;已经尽力了。最开始的时候&＃xff0c;还坚持对一些较大的镜像一起来找茬&＃xff0c;看看能做哪些优化。随着项目的增多&＃xff0c;只以镜像大小论英雄的方式了&＃xff0c;实在java哭nodejs笑&＃xff08;只是我们的镜像一般都是java项目较大&＃xff0c;nodejs较小&＃xff0c;不代表具体意义&＃xff09;。最终只能是随机选择镜像审查&＃xff08;其实目的就是给大家压力&＃xff0c;不要随便搞&＃xff09;&＃xff0c;对于镜像要求不能超过上限1GB&＃xff08;正如挤挤还是有的&＃xff0c;镜像减减还是小的&＃xff09;&＃xff0c;除非另外申请。

在我们一段时间的镜像审查中&＃xff0c;发现一个普遍的现象&＃xff0c;镜像越小的反而空间浪费率越高&＃xff08;无用的文件、重复覆盖的文件或者被删除的文件等&＃xff09;。因为对于小镜像&＃xff0c;增加了20MB&＃xff0c;30MB&＃xff0c;也就是从100MB级别增长到200MB级别&＃xff0c;大家真的没有太在意&＃xff0c;在刀耕火种无自动化工具支持的情况下&＃xff0c;只能且行且将就~

人生总有亮光&＃xff0c;程序员总不会单身一辈子的&＃xff0c;dive的出现终于给我们较可行的镜像评分方案。

dive

dive是一个可以查看docker镜像的工具&＃xff0c;可以获取镜像的分层&＃xff0c;分层的文件信息&＃xff08;增删改&＃xff09;&＃xff0c;重复出现或删除的文件&＃xff08;无用空间的浪费&＃xff09;等。

镜像概况

Total Image size: 总的镜像大小

Potential wasted space: 可能的浪费空间&＃xff08;根据文件覆盖、删除等计算得到&＃xff09;

Image efficiency score: 根据各层中浪费的空间大小估算的镜像得分

根据镜像的概况&＃xff0c;我们将得分少于0.9&＃xff08;最大为1&＃xff09;的镜像标记为可优化镜像&＃xff0c;并将浪费空间对应的相应文件展示&＃xff0c;如上图中所示的文件列表以及出现次数。

分层概况

上面图片展示了dive针对镜像的分层情况分析&＃xff0c;基于这些数据我们主要分析以下几点&＃xff1a;

• 对于基础镜像&＃xff08;最底层&＃xff09;大于500MB的&＃xff0c;建议选择更小的基础镜像&＃xff0c;如基于alpine的镜像。
• 对于分层大于10层的镜像&＃xff0c;获取各层的命令汇总展示&＃xff0c;建议调整指令&＃xff0c;是否已使用串连的形式。
• 除基础镜像外的所有层总大小如果大于500MB的&＃xff0c;汇总各层新增、修改文件&＃xff08;对大于1MB的文件重点标&＃xff09;&＃xff0c;建议分析每层添加的文件是否有无用文件&＃xff08;因为镜像中的文件是否有用到只能由开发人员确认&＃xff09;。
• 汇总各层的无用文件&＃xff08;我们定义为.pdf .txt .doc等一些文档文件不应该出现在镜像中&＃xff09;&＃xff0c;如果超过100MB的也建议优化

总结

dive提供了对docker镜像的层的文件信息&＃xff0c;通过这些文件信息&＃xff0c;我们可以更精准的对镜像提出合理的优化建议&＃xff0c;不再是两眼摸黑乱指定。使用了上面的分析方式整改之后&＃xff0c;现有的镜像优化了30%左右。

想了解更多dive的相关使用可以至github dive上浏览&＃xff0c;至于不想安装dive只想试验的可以尝试我业余时间开发的网页版https://diving.aslant.site/。大家在使用网页版的时候&＃xff0c;可以尝试输入redis&＃xff08;镜像需要先下载&＃xff0c;如果其它未下载镜像会很慢很慢&＃xff0c;因为大家都懂的墙&＃xff09;或者使用国内的镜像源如registry.docker-cn.com/library/redis。还有大家在使用网页版的时候&＃xff0c;请手下留情&＃xff0c;不要尝试太大的镜像&＃xff0c;因为我的最低配的服务器&＃xff0c;小胳膊小脚&＃xff0c;不耐操。