摘要：
为什么要清理服务器上docker容器的日志？ &... 为什么要清理服务器上docker容器的日志？
因为是服务器的磁盘空间资源有限，由于docker容器在启动的时候没有限制，导致运行的docker容器随着时间的推移产生的日志越来越多，最后把服务磁盘资源耗尽，服务器的磁盘满了会导致服务器的应用无法正常运行
说到docker容器的日志文件，docker默认位于/var/lib/docker/containers/容器ID/容器ID_json.log 。在目录/var/lib/docker/containers 这里面存放了docker容器的元数据(包括镜像数据，配置数据等，如果删除了这个目录，则容器也就没有了),如果想要修改docker默认的配置元数据的地方，则继续往下看
docker容器日志限制
2.1 容器范围内
docker run 或 dokcer create 时添加参数
如创建并运行
docker run --log-opt max-size=10m --log-opt max-file=3
#有一个地方需要注意一下，老版本的docker使用的 journald ，如果需要报错先看下/etc/sysconfig/docker 配置文件，–log-driver=json-file 是否是等于json-file，不是的话需要修改一下;;修改完 重启dokcer加载配置文件
systemctl daemon-reload && systemctl restart docker
如果想要修改docker默认的配置元数据的地方，或者限docker日志大小，在全局范围内编辑 /etc/docker/daemon.json,在文件添加
"data-root": "" # 输入修改元数据配置的目录
"log-driver": "json-file" # 日志样式为json
"log-opts": {"max-size": "10M", "max-file": "3"} # 限制docker日志大小为10M，保留3份日志文件
修改后，docker需要重新加载配置文件和重启。
CentOS7的操作
systemctl daemon-reload
systemctl restart docker
注意：新创建的容器会生效，原有容器不生效。
参数说明
log-opts max-size 容器日志文件上限大小
log-opts max-file 窗口日志文件上限个数
3.删除Docker容器日志的正确姿势
3.1 方式一
编写shell脚本，然后执行
[root@ecs-62ed ~]# cat clean_docker_log.sh #!/bin/sh echo "======== start clean docker containers logs ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $logs do echo "clean logs : $log" cat /dev/null > $log done echo "======== end clean docker containers logs ========"
3.2 方式二
执行如下命令：
sudo find /var/lib/docker -name ‘*.log’ -exec rm {} ;
下面是对删除 /var/lib/docker 目录后 Docker 的行为和状态的一个详细分析过程
前提说明
/var/lib/docker 是 Docker 在默认配置下用于存储几乎所有数据的根目录，包括镜像层、容器元数据、网络信息、卷数据等。
Ubuntu 20.04 (ARM) 与 x86 并没有本质上的区别，主要影响的是 Docker 的镜像架构，但 Docker 本身的工作逻辑一致。
分析从Docker程序与服务运行逻辑的角度着手，而不是从文件系统角度简单考虑。
1. Docker Daemon 运行概览
在正常情况下，当 Docker daemon （dockerd）启动时，它会检查 /var/lib/docker 目录下的内容：
镜像层与元数据：Docker 会从 /var/lib/docker/image/ 目录中读取存储的镜像信息和元数据，用来列出本地镜像并用于后续容器创建。
容器信息：在 /var/lib/docker/containers/ 目录下存有已创建容器的元数据、日志文件和状态文件。当 dockerd 启动时，它会扫描这些目录，将之前已存在但未运行的容器标记为已停止状态，可以通过 docker ps -a 查看。
网络信息：在 /var/lib/docker/network/files 中存放网络配置信息与驱动信息。
卷信息：在 /var/lib/docker/volumes/ 中存放卷的元数据与挂载点，用以恢复或保持数据持久化的状态。
当 Docker daemon 启动时，它会加载这些信息从而快速恢复到上一次停止时的状态，以确保用户的容器、镜像、网络和卷配置信息不丢失。
2. 直接删除 /var/lib/docker 的影响（在 Docker 停止或运行中的情况）
如果在 Docker daemon 停止状态下删除 /var/lib/docker：
当下次启动 Docker 时，daemon 会尝试访问 /var/lib/docker 目录读取数据。此时，该目录已不存在或为空，Docker 会视之为“全新状态”。
Docker 会在启动时自动重新创建 /var/lib/docker 目录和所需的默认子目录结构（如 overlay2、containers、image、network、volumes），但内容为空。
因为数据已经被完全清空，Docker 不会加载到任何现存的镜像、容器、网络或卷——相当于刚刚安装好 Docker 的初始状态。
在这种情况下，Docker daemon 理论上能够正常启动并运行，因为它没有数据可加载，只是没有用户定义的任何资源。
如果在 Docker daemon 运行中直接删除 /var/lib/docker：
这种情况更复杂，因为 Docker daemon 可能正在访问这些目录。
Daemon 在运行中会尝试读写 /var/lib/docker 下的文件。例如：当您执行 docker run 命令时，Docker 会在 /var/lib/docker 下创建容器目录并写入元数据。
如果此时突然 rm -rf /var/lib/docker，正在访问该目录的读写操作将失败。
这可能导致 Docker daemon 出现错误或异常行为（例如在日志中报错，无法访问镜像层或容器元数据）。
某些正在运行的容器内的挂载可能会出现异常或变为不可用，因为底层数据已被删除。
不过，一旦您重启 Docker daemon，它会在下次启动时发现 /var/lib/docker 不存在，然后像上面提到的那样当做全新状态处理。
因此，为了避免混乱和潜在数据损坏，通常应该先停止 Docker daemon (sudo systemctl stop docker)，然后再删除 /var/lib/docker。
3. 删除后的最终状态
假设删除完成后，您重启 Docker daemon (sudo systemctl start docker)：
镜像： /var/lib/docker/image 中为空，无镜像数据。docker images 显示为空列表。
容器： /var/lib/docker/containers 中无容器信息。docker ps -a 显示无容器。
网络： 内置默认网络（如 bridge 网络）会重新以默认配置生成，但用户自定义的网络丢失。
卷： 自定义卷的元数据和数据已经被删除，docker volume ls 列表为空。
从用户视角看，相当于刚刚安装好 Docker 且从未运行过任何镜像和容器的初始状态。
4. Docker 是否能够正常运行？
在绝大多数情况下，答案是肯定的。Docker 没有依赖外部系统性文件存储于 /var/lib/docker 中，这里主要是 Docker 自身的数据存放地点。删除后下次启动时 Docker daemon 会将其初始化为一个空白状态。这不会阻止 Docker 正常启动和运行，只是会丢失之前的所有数据。
除非你对 Docker 的默认配置或路径进行了特殊更改（例如在 daemon.json 中设置了自定义 data-root），否则 Docker 会按照默认逻辑进行初始化。也就是说，最终 Docker 会“干净”地启动，所有之前的容器、镜像、网络、卷以及相关数据都会消失，Docker 就如同全新安装般的状态。
总结
删除 /var/lib/docker 等同于彻底清空 Docker 的本地数据存储。
在下一次 Docker daemon 启动时，Docker 会自动重建该目录和基本结构，出现无任何用户数据的全新运行状态。
Docker daemon 能够正常运行，只是从逻辑上已经恢复到初始安装完成后的状态。
