LaravelForge如何部署_LaravelForge服务器管理流程【详解】-php教程-PHP中文网

forge是服务器自动化配置与部署触发器的组合体，它通过ansible风格脚本自动创建云服务器、配置php/mysql/nginx等环境，并在代码推送后按自定义脚本执行部署流程，但不直接运行composer或artisan命令。

laravelforge如何部署_laravelforge服务器管理流程【详解】

Forge 不是部署工具，而是服务器自动化配置 + 部署触发器的组合体。它本身不执行 composer install 或 php artisan migrate，而是帮你把执行这些命令的环境和流程「稳稳地搭好」——一旦你推送代码，它就按你定义的脚本自动跑完整套流程。

创建服务器时 Forge 实际干了什么

你点下“Create Server”后，Forge 并不是简单起个云主机，而是通过 Ansible 风格脚本远程执行一整套初始化：

在 DigitalOcean/Linode 等平台调用 API 创建 Ubuntu 22.04/24.04 实例
禁用 root 密码登录，只保留 SSH 密钥认证
安装并配置 nginx、php8.2-fpm、mysql-server、redis-server、supervisor
设置 UFW 防火墙，默认只开放 22、80、443 端口
创建非 root 部署用户（如 forge），并赋予 sudo NOPASSWD 权限用于后续部署脚本

这意味着你根本不需要手动连服务器敲 apt update —— 但也要注意：Forge 不装 Node.js、不配 Docker、不处理自定义内核模块。超出 PHP+Web+DB 栈的部分，得自己写「启动后脚本」补上。

部署流程中哪些步骤可被覆盖或跳过

Forge 默认部署脚本（Deploy Script）是可编辑的文本框，内容类似：

cd /home/forge/example.com
git pull origin main
$PHP_BINARY composer install --no-dev --quiet --optimize-autoloader
$PHP_BINARY artisan migrate --force --quiet
$PHP_BINARY artisan config:cache
$PHP_BINARY artisan route:cache
$PHP_BINARY artisan view:cache
sudo systemctl reload nginx

关键点：

Laravel Creem Agent

Creem 支付商店助理 — 查询订阅、客户、交易、产品，执行心跳检查，管理本地 Laravel支付商店。

下载

$PHP_BINARY 是 Forge 自动注入的路径（如 /usr/bin/php8.2），别硬写 php，否则可能调到系统默认旧版本
git pull 前不会自动 git checkout，如果你用 production 分支，就得把那行改成 git checkout production && git pull origin production
artisan migrate 加了 --force 才能在生产环境跑，漏掉会静默失败
前端构建（如 npm run build）默认不包含，必须手动加在 composer install 后面，并确保已装 Node.js
Supervisor 管理的队列监听器不会自动重启 —— 要加 sudo supervisorctl restart example-worker: 这类行

SSL 证书自动续期为什么有时失效

Forge 用 Let’s Encrypt 的 certbot 配置定时任务（crontab -u root -l 可查），但常见失效原因不是证书过期，而是验证环节卡住：

域名 DNS 解析未指向该服务器 IP（尤其刚换服务器时，TTL 未过期）
Nginx 配置里漏了 location ^~ /.well-known/acme-challenge/ 块，导致 certbot HTTP 验证 404
站点启用了 Cloudflare 代理，且没关「Always Use HTTPS」或没设「Full (strict)」SSL 模式，导致验证请求被拦截
防火墙（UFW）误封了 80 端口 —— Forge 虽然开了，但你后来手动改过规则可能覆盖掉

检查方式很简单：SSH 登录后运行 sudo certbot renew --dry-run，看输出里是否出现 failed validation 或 connection refused。

Forge CLI 和 SDK 的权限边界在哪

Forge CLI（forge deploy）和 SDK（Forge::createServer()）都依赖同一个 API Token，但能操作的资源受 Forge 后台权限控制：

Token 在 Forge 控制台生成时，可限定「仅读」或「读写」；选错就无法调用 deploy 或 restart queue
CLI 默认操作的是「当前激活服务器」（forge server:current 查），切换需 forge server:switch staging，不是所有服务器都自动可见
SDK 中 ManagesSites.php 只能管理该 Token 所属团队下的站点，跨团队不行；也不能直接读取 .env 内容或下载日志文件
所有 CLI/SDK 操作都会在 Forge 控制台的「Activity Log」里留痕，但不会记录脚本执行的具体 stdout —— 错误还得看部署日志页里的实时输出

真正容易被忽略的是：Forge 的「部署脚本」运行在 forge 用户下，而 CLI/SDK 发起的操作（如 queue:restart）走的是 Supervisor 的 socket 接口，两者权限模型不同，不能假设「脚本能做的事，CLI 一定也能做」。