不能直接在nginx容器中运行logrotate，因其依赖cron和持久化状态，而nginx容器单进程前台运行、无cron服务，且重启后logrotate状态丢失，易致重复或漏切；sidecar模式通过独立容器共享日志卷并发送reopen信号实现可靠切割。
在 Docker 容器中，Nginx 默认将日志写入 stdout/stderr 或挂载的文件（如 /var/log/nginx/access.log），但容器本身不支持传统 cron 或 logrotate 的长期运行，因此需借助 sidecar 模式实现可靠、可维护的日志切割。
为什么不能直接在 Nginx 容器里跑 logrotate？
logrotate 依赖定时任务（cron）和文件系统持久性。而 Nginx 容器通常以单进程前台方式运行（PID 1），不带 cron 服务；若强行安装 cron 并启动，会破坏容器设计原则，增加攻击面与维护成本。更关键的是：容器重启后未持久化的 logrotate 状态（如 last rotated 时间、轮转计数）会丢失，导致重复切割或漏切。
Sidecar 方案的核心思路
用一个轻量、专用的 sidecar 容器（如 alpine:latest + logrotate）与 Nginx 容器共享日志卷，并由它定期执行切割。Nginx 主动重载日志（nginx -s reopen）是关键——sidecar 切割后必须通知 Nginx 关闭并重新打开日志文件，否则新日志仍会写入旧文件句柄。
- 两个容器共用同一
volume（如./logs:/var/log/nginx:rw） - sidecar 容器内安装
logrotate，配置按天/大小切割access.log和error.log - logrotate 的
postrotate脚本通过docker exec或 Unix socket（推荐）向 Nginx 发送reopen信号 - sidecar 使用
crond或sleep循环 +logrotate实现定时触发（避免依赖宿主机 cron）
具体实现示例（Docker Compose）
以下是一个最小可行的 docker-compose.yml 片段：
services:
nginx:
image: nginx:alpine
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
- nginx-logs:/var/log/nginx
# 不暴露 80 给宿主机，仅供 sidecar 访问
expose:
- "80"
<p>logrotator:
image: alpine:latest
volumes:</p>
- nginx-logs:/var/log/nginx:rw
若需 exec 进 nginx 容器，挂载 docker.sock（生产慎用）
- /var/run/docker.sock:/var/run/docker.sock:ro
entrypoint: ["/bin/sh", "-c"] command: | apk add --no-cache logrotate && echo "/var/log/nginx/*.log { daily missingok rotate 30 compress delaycompress notifempty create 0644 nginx nginx sharedscripts postrotate
方式一：通过 docker exec（需挂载 docker.sock，开发可用）
docker exec nginx-nginx-1 nginx -s reopen 2>/dev/null || true
方式二：更安全——向 Nginx 的 80 端口发 reload 请求（需 nginx 配置 stub_status 或自定义 endpoint）
curl -s https://www.php.cn/link/520153c8d5554c183aec530ebcd35a85 > /dev/null 2>&1 || true
方式三（推荐）：使用命名管道或共享内存？不现实。最稳妥是让 Nginx 容器监听本地 socket 并响应 reopen
所以实际常用：sidecar 直接向 Nginx 容器的 PID 1 发信号 —— 需要共享 PID namespace
}" > /etc/logrotate.d/nginx && while true; do logrotate /etc/logrotate.d/nginx sleep 86400 # 每天一次 done volumes: nginx-logs:
⚠️ 注意：
- 若选
docker exec方式，logrotator 必须能访问 Docker daemon（挂载docker.sock），存在安全风险，不建议生产环境使用。
- 更优解是启用
pid_mode: container:nginx，使 logrotator 与 nginx 共享 PID namespace，然后用kill -USR1 1（Nginx 的 USR1 信号即 reopen）——前提是 Nginx 容器以--pid=host或明确指定pid_mode启动。
- 生产中常结合
init: true（使用 tini）和pid_mode: "container:nginx"，再在 logrotator 中执行kill -USR1 1即可安全 reopen。
替代方案：用 Fluentd / Filebeat + 外部日志系统
如果目标是归档与分析而非本地文件管理，可跳过切割，直接让 Nginx 输出到 stdout，再用 Fluentd/Filebeat sidecar 收集、打标、按时间切片转发至 Elasticsearch/S3。这种方式更云原生，规避了文件切割的所有边界问题（权限、inode 复用、reopen 时序等），也便于统一治理。
不复杂但容易忽略：Nginx 容器输出到 stdout 时，access log 格式需适配结构化（如 JSON），且务必关闭 buffer（access_log /dev/stdout json; open_log_file_cache off;），避免日志延迟或丢失。
