为一个运行 Docker 的服务器清理硬盘空间，常规的 docker image prune, docker system prune 执行过之后，硬盘使用量仍然很高，但这个机器基本只作为 Docker host 使用，理论上不该有其他的服务产生大量数据。
排查思路是从上至下寻找数据量最大的目录。于是从 / 开始用 du -sh */ 来逐层向下查找，最终定位到 /var/lib/docker/containers 足有 140G。这个目录下存放的是 container 运行过程产生的各种数据，但为什么在 prune 清理过已停止的 containers 之后还有这么大呢？通过子目录名所对应的 container id 进行
总结：
- 纠正了一个思维误区，不是只有历史容器占用空间，正在运行的容器有可能才是大头
- 清理正在运行的容器的日志存储可以首先使用 docker inspect --format='{{.LogPath}}' <container id> 定位日志位置，再用 truncate -s 0 <filepath> 将文件内容安全置空，由于 inode 不会被改变因此也不会影响容器的运行
排查思路是从上至下寻找数据量最大的目录。于是从 / 开始用 du -sh */ 来逐层向下查找，最终定位到 /var/lib/docker/containers 足有 140G。这个目录下存放的是 container 运行过程产生的各种数据，但为什么在 prune 清理过已停止的 containers 之后还有这么大呢？通过子目录名所对应的 container id 进行
docker inspect，发现原来是一个正在运行的容器的 stdout 所产生的日志占用主要空间。清理这个日志文件后硬盘空间恢复正常。总结：
- 纠正了一个思维误区，不是只有历史容器占用空间，正在运行的容器有可能才是大头
- 清理正在运行的容器的日志存储可以首先使用 docker inspect --format='{{.LogPath}}' <container id> 定位日志位置，再用 truncate -s 0 <filepath> 将文件内容安全置空，由于 inode 不会被改变因此也不会影响容器的运行