Docker Compose怎样用日志轮转避免容器日志占满磁盘

Docker 容器日志持续增长，最后把宿主机磁盘占满，常见原因不是 Compose 本身“失控”，而是服务仍使用没有轮转上限的默认日志配置。解决方法是在目标 service 下配置 logging，用 max-size 限制单个日志文件，用 max-file 限制保留数量，再重建容器让新配置真正生效。

官方文档地址：https://docs.docker.com/engine/logging/configure/。本文只讲 Docker Compose 的服务级配置，不修改 Docker daemon 全局默认值，也不手工改 Docker 数据目录。下面的界面图均为原创静态说明图，不是 Docker Desktop 或终端截图。

最小可用配置是 driver: json-file 加上 options.max-size 与 options.max-file。修改 Compose 文件后必须重新创建容器；只执行普通的 docker compose restart，不会把旧容器的日志配置替换成新值。

先把配置放在目标 service 下

打开项目的 compose.yaml，定位需要限制日志的服务，例如 api。操作路径可以按“项目目录 → compose.yaml → services → api → logging”理解。logging 是服务级字段，不能和 services 平级，也不要把它误写到 build 或 deploy 里面。

先保存一个只影响单个服务的配置。这样可以让高输出的 api 服务拥有明确上限，而不会在本文任务中改变同一 Docker 主机上其他项目的全局行为。

设置 json-file 的轮转上限

在目标 service 下加入下面的配置。YAML 的 options 值建议写成字符串，避免把容量或数量当成其他类型解析。

services:
  api:
    image: example/api:latest
    logging:
      # 使用 Docker 默认兼容性较好的 JSON 日志驱动
      driver: json-file
      options:
        # 单个日志文件达到 10 MB 后开始轮转
        max-size: "10m"
        # 保留当前文件之外的 3 个轮转文件
        max-file: "3"

这个示例的近似保留量是 10 MB × 4，实际占用还会受到日志格式、文件系统和其他容器影响。max-size 与 max-file 是轮转参数，不等于集中式日志系统的长期归档策略；如果业务需要检索很久以前的日志，应另行设计收集和保留链路。

重建服务，让配置进入新容器

修改文件后，在项目目录打开 Compose 操作入口，执行“项目目录 → compose.yaml → 目标服务 → 重建并后台启动”。命令行等价操作如下：

# 强制重新创建 api，让新的 LogConfig 写入容器配置
docker compose up -d --force-recreate api

# 查看 Compose 识别到的服务状态，确认 api 已重新启动
docker compose ps api

--force-recreate 用于明确触发容器替换；如果项目还有依赖服务，可按实际拓扑决定是否一起启动。不要把“Compose 文件已保存”当成“旧容器已更新”，两者是两个状态。

用 inspect 核对实际生效值

为了确认检查的是新容器而不是旧配置，可读取目标容器的 HostConfig.LogConfig。先取得容器名，再执行下面的命令：

# 只取 Compose 项目中 api 服务对应的容器名
container_id="$(docker compose ps -q api)"

# 从容器配置中读取实际使用的驱动和轮转参数
docker inspect "$container_id" \
  --format '{{json .HostConfig.LogConfig}}'

预期能看到类似下面的字段结构：

{"Type":"json-file","Config":{"max-size":"10m","max-file":"3"}}

这里的关键验收点是 Type、max-size 和 max-file 同时出现。若输出为空，先检查 docker compose ps -q api 是否返回了容器 ID；若参数仍是旧值，通常说明只重启了旧容器，或实际执行的 Compose 文件不是刚修改的那一份。

常见误区与回退方式

1. 只改 daemon.json：这是 Docker 主机的全局默认策略，影响范围更大；本文任务优先使用 Compose 的服务级 logging。
2. 只运行 restart：重启会复用原容器配置，修改日志驱动或选项后应使用 up -d --force-recreate。
3. 直接删除日志文件：不要在 Docker 正在管理日志时手工改数据目录；先降低输出、配置轮转，再安排符合运行环境的清理策略。
4. 把轮转当成备份：轮转只控制本地保留量，不保证日志长期可检索，也不替代集中式收集。

如果新参数不适合当前环境，可以删掉服务级 logging 块并重新执行一次 docker compose up -d --force-recreate api，让服务回到 Docker daemon 的默认驱动设置。回退后仍应重新用 docker inspect 读取实际配置。

速查表

相关问题

为什么改了 compose.yaml，日志参数还是旧的？

Compose 文件是后续创建容器的输入，已经存在的容器不会因为文件保存自动改写。使用 docker compose up -d --force-recreate 服务名 重建后，再用 docker inspect 核对。

max-size 和 max-file 怎么估算磁盘占用？

可以先用单文件大小乘以保留文件总数做粗略估算；示例中的 10m 与 3 大致对应当前文件加三个轮转文件。宿主机上还要为其他服务、镜像和系统保留空间。

服务级 logging 会修改所有 Compose 项目吗？

不会，它只写入该 service 创建出的容器配置。Docker daemon 的全局默认值仍然由主机级配置决定，两者不要混为一谈。