系统运维之docker磁盘爆满-搭配解决方法-Toy模板网

这篇具有很好参考价值的文章主要介绍了系统运维之docker磁盘爆满-搭配解决方法。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

问题描述：日常巡检发现本地registry仓库磁盘爆满，如何解决？

解决步骤分析：

确定哪个文件或者目录爆满？
什么原因引起的爆满？
确认此目录或者文件作用？
确认解决方式？
配置预防手段

直接上图，查看哪里满了？
此处看出为/var/lib/docker/overlay2目录爆满

看到这里应该心理应该有个概念：此次磁盘爆满和docker有关了，一般docker占用磁盘过多有以下几种情况（拿纸笔圈起来记）：
1. docker镜像占用磁盘空间过多
2. docker日志占用磁盘过多
3. /var/lib/docker/overlay2下的容器文件过多（大部分是这种情况）
往下看今天遇到的情况符合那种嘞？
继续深入查看具体哪个文件竟然占用如此大的空间！
此处发现是/containers目录爆满了
进入看到，/containers这个目录高达27G文件，不满才怪，
这里给大家讲解一下：
/var/lib/docker 是 Docker 默认的数据存储位置，包括 Docker 镜像、容器和卷。该目录下的子目录包括：
/containers：存储容器相关的数据和元数据，包括容器的配置文件和日志文件；
/image：存储 Docker 镜像的文件系统和元数据；
/volumes：存储 Docker 卷的数据和元数据。
图上发现/containers目录占用磁盘高达27G，如下图：已知/containers目录下有若干个<container_id>，每个容器都有一个唯一的标识符<container id> ，在每个容器目录中，有以下文件和目录:
由上图可以看出是某个容器占用磁盘过高，开始下一步分析，看看什么原因引起的爆满，继续深入！
看到这里各位应该都能发现了，是由于json.log这个日志文件太多，这里对这个文件分析一下：此日志是容器生成的所有输出，该输出保存在主机计算机上的日志文件中。这些日志文件可以帮助您了解Docker容器的健康状况、调试问题，并监视应用程序行为，但是dokcer日志文件可以变得很大，因为他们会持续记录容器生成的所有输出。不过不定期清理这些日志文件，他们将占用大量的磁盘空间。当Docker容器日志过大时，可能会导致调试问题过于复杂或深度使用Docker日志分析工具成为不可避免的任务。
到目前为止，问题原因，位置，都已经确定，应该讨论解决办法，目前的解决办法我个人分析分为两种：
删除和清空
为什么有两种解决办法？这里解释一下，删除的话，是直接把文件删除，这是最快速，最简单的方式，当然也有一定的风险：有时候如果贸然删除了日志文件，可能正在跑的服务日志就没地方写，但是该服务如果一直打开了该文件，那么写的时候，服务只认文件描述符，虽然你把文件删除了，但是之前建立的文件描述符一直存在，该服务还可以一直在该文件描述符的位置上写log，即便是你删除后，重新创建一个同样命名的文件，该服务也不会将log写到重新创建的文件中，还是因为文件描述符已经存在了，重新创建文件后，不是原来的文件描述符。这个具体看你有没有服务在调用日志文件，同时，这也是另一个解决方法-清空存在的理由
清空：即清空文件，保留原文件，只将原文件的内容清空。
下面介绍几个清空的命令，注意：慎用！慎用！
```
手动清空：
1.>/logs/file.log
2.cat /dev/null > /logs/file.log

脚本常用清空方式：
3.echo "">/logs/file.log

冒号清空：
4. :>/logs/file.log
```
附上解决问题图片：
注意：在执行指令的时候，虽然有时候文件确实被清空了，但是使用或者1s 指令查看的时候，文件的大小并没有变化，但是在指令输入前后如果使用df -h指令查看log文件所在盘符的大小，发小og文件所在盘符的空间确实被释放了。或者在log所在文件夹使用du -sh指令，查看，也会发现log文件的大小变了，之所以使用I 或者ls 指令查看时，文件大小没有变化，可能是该文件一直被进程占用，或者是查看的逻辑有一些不同吧
预防手段会在评论区发布，敬请期待~
最后：如果大家对关于docker其他原因造成的磁盘空间不足的问题，欢迎留言，看到就会回复，后面也会出解决镜像，容器文件等原因磁盘空间不足的帖子。谢谢支持~文章来源地址https://www.toymoban.com/news/detail-793833.html