

大家好,我是 Tinywan,一个在 Docker + PHP 生态里摸爬滚打好几年的老油条。
过去几年,我的 PHP 容器(Nginx + PHP-FPM + cron + 一些小脚本)几乎清一色用 supervisord 来管理多进程。配置简单,一个 ini 文件搞定所有服务,启动、重启、日志查看都挺顺手。很多老项目、公司内部镜像也都是这么玩的,稳定不出大问题,我就一直没换。
但从 2025 年下半年开始,我陆续迁移了几个核心服务到新镜像时,突然发现自己有点“跟不上时代”了。
[program:xxx] 的 stdout_logfile=syslog 或者重定向,才能让 docker logs 看到实时输出。配置一多就乱。/etc/s6-overlay/s6-rc.d/
├── nginx/
│ ├── run # #!/usr/bin/execlineb -PW with-contenv nginx -g "daemon off;"
│ └── notification-fd # 内容:3
├── php-fpm/
│ ├── run
│ └── notification-fd
├── init-permissions/ # oneshot 类型,启动前跑权限脚本
│ ├── run
│ └── type # 内容:oneshot
└── user/ # 默认 bundle
└── contents.d/
├── php-fpm
└── nginx
迁移后,镜像体积反而小了 20–40MB,docker stop 时间从 15s+ 降到 1–2s,docker logs 干净实时,健康检查也更准。
拉取镜像
docker pull tinywan/docker-php-webman:8.4.16-s6
挂载启动webman
docker run --name webman-s6 --rm -it -p 8787:8787 -v /home/www/webman:/app tinywan/docker-php-webman:8.4.16-s6
输出日志
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
Workerman[start.php] start in DEBUG mode
Master pid:67 is not alive
-------------------------------------------- WORKERMAN ---------------------------------------------
Workerman/5.1.6 PHP/8.4.16 (JIT off) Linux/6.6.87.2-microsoft-standard-WSL2
--------------------------------------------- WORKERS ----------------------------------------------
event-loop proto user worker listen count state
event tcp root webman http://0.0.0.0:8787 16 [OK]
event tcp root monitor none 1 [OK]
----------------------------------------------------------------------------------------------------
Press Ctrl+C to stop. Start success.
查看进程
$ docker top webman-s6 acxf
PID TTY STAT TIME COMMAND
60483 ? Ss 0:00 \_ s6-svscan
60515 pts/0 Ss+ 0:00 \_ rc.init
60566 pts/0 S+ 0:00 | \_ php
60568 pts/0 S+ 0:00 | \_ php
60569 pts/0 S+ 0:00 | \_ php
60570 pts/0 S+ 0:00 | \_ php
60571 pts/0 S+ 0:00 | \_ php
60572 pts/0 S+ 0:00 | \_ php
60573 pts/0 S+ 0:00 | \_ php
60574 pts/0 S+ 0:00 | \_ php
60575 pts/0 S+ 0:00 | \_ php
60576 pts/0 S+ 0:00 | \_ php
60577 pts/0 S+ 0:00 | \_ php
60578 pts/0 S+ 0:00 | \_ php
60579 pts/0 S+ 0:00 | \_ php
60580 pts/0 S+ 0:00 | \_ php
60581 pts/0 S+ 0:00 | \_ php
60582 pts/0 S+ 0:00 | \_ php
60583 pts/0 S+ 0:00 | \_ php
60584 pts/0 S+ 0:00 | \_ php
60516 ? S 0:00 \_ s6-supervise
60519 ? Ss 0:00 | \_ s6-linux-init-s
60526 ? S 0:00 \_ s6-supervise
60533 ? Ss 0:00 | \_ s6-ipcserverd
60527 ? S 0:00 \_ s6-supervise
supervisord 没有错,它在 2015–2024 年几乎是 Docker 多进程的事实标准。但到了 2025–2026 年,容器哲学更纯粹了:容器应该像单个进程一样行为。s6-overlay 更贴合这个理念,轻、准、现代。
如果你还在维护老项目,supervisord 继续用没问题。但新项目、特别是 PHP + Nginx/FPM + cron 的组合,我现在是 100% 推荐 s6-overlay。
你最近有没遇到 supervisord 的痛点?或者已经在用 s6 了?欢迎交流~