Docker 应用安装脚本

install_workerman3524_base_docker.sh

创建 app 和 logs 目录,仅在缺失时写示例应用和 composer.json,每次覆盖 Dockerfile。基于可变 PHP 7.2/Composer 标签构建后强制替换同名容器,仅挂载 logs。

一键命令

curl -fL 'https://www.helper.sh/install_workerman3524_base_docker.sh' -o './install_workerman3524_base_docker.sh'

此命令只下载本站文件,不会执行。请先检查保存的源码并核对版本,再决定是否运行。

核对已下载文件

与本页面构建时内置的确切字节比较。文件只在当前标签页处理,此工具不上传、不持久化文件。上限 2 MiB。

预期 SHA-256
e3f40b68c2dc6cc4c865d7498000d73352f373a589362c141e485e3567f7bbb4

内置文件字节数: 5729

保存校验文件

将脚本和校验文件保存在同一目录。Linux 安装 GNU Coreutils 后可用下方命令只检查字节,不运行脚本;使用此命令时需保留原文件名。

sha256sum --check './install_workerman3524_base_docker.sh.sha256'

尚未比较。

校验值与脚本来自同一网站,不是独立签名。一致不证明安全、上游依赖真实可信或适合本机;可变远程依赖需单独审阅。

查看验证与限制

运行要求

  • Linux 主机
  • Docker 已安装并运行
  • 需要 root 权限或 sudo
  • 2345 端口可用
  • /data 目录可写

适用场景

  • 在已经具备 Docker 环境的主机上快速拉起一个 Workerman 3.5.24 HTTP 服务
  • 把 Workerman 应用文件和日志统一保存在 /data/workerman3.5.24 下
  • 为仍然依赖 Workerman 3.x 的老 PHP 常驻服务提供标准化的一键启动入口

脚本亮点

  • 自动创建 /data/workerman3.5.24/app 和 logs
  • 默认写入一个最小 Workerman 启动脚本和 composer.json
  • 基于 php:7.2-cli 构建本地 helper-workerman:3.5.24 镜像
  • 启动一个可自动重启的容器,并暴露一个简单 HTTP 接口用于验证

推荐流程

  1. 先确认 Docker 已安装可用,且宿主机的 2345 端口没有被占用。
  2. 使用 sudo 或 root 执行 helper.sh 提供的一键命令。
  3. 等待脚本准备 /data/workerman3.5.24、构建本地镜像,并创建容器。
  4. 后续可以直接修改 /data/workerman3.5.24/app 下的示例 Workerman 应用,再按需重建或替换为正式服务。

安全提示

  • Workerman 3.x 和 PHP 7.2 都属于老版本组件,请只在兼容性确实需要时使用。
  • 不要在没有流量控制和代码审阅的情况下,把基于老版本 PHP 的事件服务直接暴露到公网。
  • 如果这是生产实例,替换或重建容器前请先备份 /data/workerman3.5.24。

兼容范围与限制

  • 需要使用 systemd 的 Linux、Docker 构建能力、root、可写 /data 及所选空闲宿主机端口(默认 2345)。这是旧 Workerman 3.5.24/PHP 7.2 兼容示例,PHP 7.2 已停止支持。
  • 接受 --data-dir、--container-name 和 --port。没有 dry-run、备份或自动回滚。php:7.2-cli 与 composer:2.2 是可变上游标签;生成的 Dockerfile 会在镜像构建内禁用归档元数据过期校验,并允许不安全的 APT 仓库。
  • composer install 前仅复制 composer.json,宿主已有 composer.lock 不会固定该安装阶段。既有 composer.json 会保留,可能改变所请求的 Workerman 版本。上游字节变化后需要重新核验依赖。

受影响的文件、服务和数据

  • 创建 /data/workerman3.5.24/app 和 logs;仅在缺失时写 app/start.php 与 composer.json。每次都会无备份覆盖 DATA_DIR/Dockerfile,包含你的自定义修改。
  • 先构建 helper-workerman:3.5.24,再强制删除同名容器并重建,将所选宿主机端口映射到容器 2345。只有 logs 是 bind mount,应用文件被复制进镜像;修改宿主 app 后需重新构建和替换。
  • 无备份复用宿主文件;挂载 logs 不保证自定义应用把日志写到那里。没有配置 TLS 或公开访问范围限制。

只读核验

  • 如修改名称或路径,请替换示例。检查 `docker inspect workerman3524 --format '{{json .Mounts}} {{json .HostConfig.PortBindings}}'`、`docker ps --filter name=workerman3524` 和 `docker logs --tail 100 workerman3524`。
  • 用 `docker exec workerman3524 php -v` 和 `docker exec workerman3524 composer show workerman/workerman` 查看实际运行时与已安装依赖版本。
  • 对于未修改的示例,另行核验回环 HTTP 响应。curl 状态成功不等于业务验证;自定义请求处理器需要独立审阅测试。HTTP 就绪失败或缺少 curl 时,脚本仍会在警告后输出完成。

失败后的下一步

构建失败发生在删除旧同名容器之前,但 Dockerfile 可能已被覆盖。保全宿主文件及旧镜像、容器证据,检查依赖和归档错误。替换后失败时先查端口冲突、镜像版本和日志,再考虑重建。备份自定义 Dockerfile 和 app;脚本不会自动恢复旧容器。

PHP · Composer

先下载、审阅并核对版本,再决定是否执行。哈希只能标识这一版字节,不能证明安全。pipe 命令会立即执行远程内容;上游依赖也可能变化。

相关文章

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

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

相关专题

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

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

查看专题

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

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

查看专题

问题页面

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

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

打开页面