基于源码的故障排查

为什么修改宿主机应用后 Workerman 容器没有更新

分清本站 Workerman 示例中的构建输入和运行时挂载，保护自定义 Dockerfile，并确认实际运行的镜像与依赖。

阅读约 3 分钟 · 2026-03-23

更新日期: 2026-10-30

返回博客查看脚本页

app 被复制，只有 logs 被挂载

生成的 Dockerfile 把 app/ 复制进镜像。docker run 只挂载 DATA_DIR/logs，所以修改 DATA_DIR/app/start.php 不会改变运行中的容器。先检查 Mounts，再判断旧响应是否与 Docker 缓存有关。

因此，经审阅的代码更新需要重新构建镜像并替换容器。安装脚本在构建后强制删除旧同名容器，每次还会覆盖宿主 Dockerfile。选择维护步骤前，保全自定义构建说明、应用文件和适当的恢复镜像。

重建前先确认实际版本

这是旧 PHP 7.2 兼容示例。php:7.2-cli 和 composer:2.2 标签可变，归档构建还放宽了 APT 校验。composer install 阶段只接收 composer.json，没有使用宿主 lock 文件；镜像名称本身不能证明依赖可复现或安全。

下方只读检查需使用实际容器名。记录镜像 ID、挂载、PHP 和已安装 Workerman 版本。回环 HTTP 状态成功不能证明修改后的代码或业务事务已经执行；测试自定义请求前先审核其行为。

docker inspect workerman3524 --format '{{.Image}} {{json .Mounts}}'
docker exec workerman3524 php -v
docker exec workerman3524 composer show workerman/workerman

相关脚本

install-workerman3524.sh

查看脚本页

相关专题

Docker 服务：检查接口和保留状态

按协议、数据目录和替换影响区分 HTTP、SQL、缓存、FastCGI 或镜像内应用。

旧 PHP：区分运行时兼容性和应用就绪

PHP 7.2/Workerman 3.5.24 示例用于有升级计划的遗留兼容工作。

问题页面

Workerman 显示完成但 HTTP 就绪检查失败

再次替换容器前，区分构建、容器启动、curl 探针与业务验证。