Deployer 的 Website Recipe 详解：基于 Caddy 的服务器网站供给与日志任务

DevOpsCI/CDCLI开发工具运维【免费下载链接】deployerThe PHP deployment tool with support for popular frameworks out of the box项目地址https://gitcode.com/gh_mirrors/de/deployer点击查看免费下载本指南围绕 Deployer 供给Provision体系中的 Website Recipe 展开它由 recipe/provision/website.php 实现负责在完成系统、用户、PHP 等基础供给之后为服务器生成并激活 Caddy 网站配置同时提供访问日志与 Caddy 系统日志的实时查看任务。读完本文你将掌握domain、public_path两个配置项的作用与交互式取值机制理解provision:server、provision:website、logs:access、logs:caddy四个任务的执行流程与源码细节并能在自己的部署脚本中正确引入、配置与排错。Website Recipe 在供给流程中的位置在 Deployer 的供给体系中recipe/provision.php通过一个名为provision的组任务Group Task把整个服务器初始化过程串联起来其任务顺序定义在 recipe/provision.phpprovision:check → provision:configure → provision:update → provision:upgrade → provision:install → provision:ssh → provision:firewall → provision:user → provision:php → provision:node → provision:databases → provision:composer → provision:server → provision:website → provision:verify其中最后两个供给动作正是本文的主角provision:server与provision:website它们全部来自 Website Reciperecipe/provision/website.php。也就是说Website Recipe 依赖前置任务已经把deployer用户、PHP-FPM、Caddy Web 服务器等组件准备好它只负责网站这一层。完整流程说明可参考 provision 供给指南官方文档的对应页面为 Website Recipe 文档。需要说明的是该供给方案面向 Ubuntu 系统recipe/provision.php 会检测发行版与版本号仅当系统为 Ubuntu 且版本号不低于 20 时才放行这一点同样适用于 Website Recipe 的运行前提。引入 Recipe 与配置参数引入方式在deploy.php中引入即可require recipe/provision/website.php;由于 Website Recipe 通常作为recipe/provision.php的组成部分被加载后者会require该文件因此当你已经require recipe/provision.php时无需重复引入。配置参数domaindomain是网站供给的核心参数默认值定义如下recipe/provision/website.phpset(domain, function () { return ask( Domain: , get(hostname)); });它是一个延迟求值lazy配置只有在任务真正读取get(domain)时才会执行该闭包默认值取自hostname配置即部署目标主机的别名/主机名在执行时 Deployer 会弹出交互式提示Domain:等待用户输入或直接回车采用默认值该交互依赖 src/functions.php 中的ask()函数。从源码看ask()在非交互模式WillAskUser::$noAsk为真下会抛出WillAskUser异常这正是 CI 或无输入场景下 Deployer 会把缺失参数上报出来、提示用户在配置中显式写死的原因因此若要实现全自动供给不交互应在deploy.php中对主机显式设置例如-set(domain, example.com)。配置参数public_pathpublic_path指定网站根目录相对于{{deploy_path}}/current的子目录recipe/provision/website.phpset(public_path, function () { return ask( Public path: , public); });交互提示为Public path:默认值public即标准的current/publicWeb 根目录布局对 Symfony/Laravel 等框架默认public即可若入口目录不同如web可在主机配置中覆盖public_path。这两个参数不仅被 Website Recipe 自身使用也会被provision:configure统一收集——recipe/provision.php 会把sudo_password、domain、public_path、php_version、db_type等参数集中询问一遍并在缺失时打印一段可直接粘贴回deploy.php的host(...)-set(...)配置片段方便把交互式供给固化为可重复执行的声明式配置。任务详解provision:serverprovision:server负责为整个服务器做网站相关的系统级准备recipe/provision/website.phpdesc(Configures a server); task(provision:server, function () { set(remote_user, get(provision_user)); run(usermod -a -G www-data caddy); run(mkdir -p /var/deployer); $html file_get_contents(__DIR__ . /404.html); run(echo $$html /var/deployer/404.html); })-oncePerNode();具体做三件事set(remote_user, get(provision_user))把远端执行用户切换为供给用户默认root见 recipe/provision.php。供给任务需要 root 权限修改用户组与系统目录usermod -a -G www-data caddy将 Caddy 进程加入www-data组使其能够读取由 PHP-FPMwww-data用户写入的站点文件与日志写入 404 页面创建/var/deployer目录并把仓库自带的 recipe/provision/404.html 作为服务器级兜底 404 页部署过去。该页面是一个带 Deployer Logo 与Not Found提示的精简 HTML后续provision:website生成的 Caddyfile 会引用这个路径。任务末尾通过-oncePerNode()标记确保同一节点在并行主机上只执行一次详见 src/Task/Task.php 中的oncePerNode语义。任务详解provision:websiteprovision:website是核心任务负责在{{deploy_path}}下生成 Caddyfile 并激活它recipe/provision/website.php。其执行步骤可以拆解为五个阶段。阶段一切换到 deployer 用户并准备目录$restoreBecome become(deployer); run([ -d {{deploy_path}} ] || mkdir -p {{deploy_path}}); run(chown -R deployer:deployer {{deploy_path}}); set(deploy_path, run(realpath {{deploy_path}})); cd({{deploy_path}}); run([ -d log ] || mkdir log); run(chgrp caddy log);become(deployer)来自 src/functions.php它临时把become配置切换为deployer并返回一个闭包用于恢复原值。任务结尾调用$restoreBecome()恢复通过mkdir -p保证{{deploy_path}}存在并chown给deployer:deployer使后续部署与网站文件操作在 deployer 用户下进行使用realpath把deploy_path规范化为绝对路径支持~展开等写法避免后续拼接路径歧义创建log目录并把组设为caddy这样 Caddy 写入访问日志时具备目录权限。阶段二渲染 Caddyfile 模板并做冲突协商$caddyfile parse(file_get_contents(__DIR__ . /Caddyfile)); if (test([ -f Caddyfile ])) { run(echo $$caddyfile Caddyfile.new); $diff run(diff -U5 --coloralways Caddyfile Caddyfile.new, nothrow: true); if (empty($diff)) { run(rm Caddyfile.new); } else { info(Found Caddyfile changes); writeln(\n . $diff); $answer askChoice( Which Caddyfile to save? , [old, new], 0); if ($answer old) { run(rm Caddyfile.new); } else { run(mv Caddyfile.new Caddyfile); } } } else { run(echo $$caddyfile Caddyfile); }模板文件是 recipe/provision/Caddyfile其中的{{domain}}、{{deploy_path}}、{{public_path}}、{{php_version}}占位符由parse()src/functions.php本质是配置值的{{ }}解析见 src/Configuration.php渲染成真实值若站点目录下已存在 Caddyfile则生成Caddyfile.new并与旧文件做diff -U5对比完全一致则删除新文件有差异则打印彩色 diff并通过askChoicesrc/functions.php让用户选择保留old还是new。这是一个非常实用的配置漂移协商机制保证重复执行供给任务不会静默覆盖人工修改test()src/functions.php本质是在远端执行if command; then echo 随机标记; fi并检查输出用于判断 Caddyfile 是否存在。阶段三注册到 Caddy 主配置并重载$restoreBecome(); if (!test(grep -q import {{deploy_path}}/Caddyfile /etc/caddy/Caddyfile)) { run(echo import {{deploy_path}}/Caddyfile /etc/caddy/Caddyfile); } run(service caddy reload); info(Website {{domain}} configured!);先恢复become为原用户root因为写/etc/caddy/Caddyfile与重载服务需要特权用grep -q幂等地把import {{deploy_path}}/Caddyfile追加到 Caddy 主配置末尾——若已存在则不再重复追加配合前面的 diff 协商整个任务可安全地重复执行最后service caddy reload让新站点配置即时生效并以info()src/functions.php输出Website domain configured!作为成功信号。阶段四节点执行限制任务末尾标注-limit(1)结合oncePerNode类语义确保该任务在多主机并行时只会在受限范围内执行一次避免多台服务器同时争夺/etc/caddy/Caddyfile的写入。Caddyfile 模板解读供给生成的 Caddy 配置模板位于 recipe/provision/Caddyfile其核心片段如下{{domain}} { root * {{deploy_path}}/current/{{public_path}} encode zstd gzip file_server php_fastcgi * unix//run/php/php{{php_version}}-fpm.sock { resolve_root_symlink } log { output file {{deploy_path}}/log/access.log { mode 0644 } } handle_errors { 404 { expression {http.error.status_code} 404 } rewrite 404 /404.html encode zstd gzip file_server { root /var/deployer } } }要点站点根目录root指向{{deploy_path}}/current/{{public_path}}与 Deployer 的符号链接指向 current 版本发布模型见 部署流程 release 任务天然衔接发布新版本后无需改动 Caddy 配置压缩与静态文件encode zstd gzip启用 zstd/gzip 内容编码file_server提供静态文件服务PHP 转发php_fastcgi指向unix//run/php/php{{php_version}}-fpm.sock其中{{php_version}}由 recipe/provision/php.php 中的php_version配置提供默认读取项目composer.json中require.php约束并回退为 8.4交互时可选 5.6/7.4/8.2/8.3/8.4/8.5resolve_root_symlink保证 FastCGI 能正确解析current符号链接后的真实路径访问日志写入{{deploy_path}}/log/access.log且权限0644配合provision:website阶段一中chgrp caddy log的目录权限Caddy 才能落盘写入404 兜底handle_errors捕获 404 状态码并重写到/var/deployer/404.html——这正是provision:server预置的服务器级 404 页面。日志查看任务logs:access 与 logs:caddy供给完成后日常运维最常用的是两个日志任务desc(Shows access logs); task(logs:access, function () { run(tail -f {{deploy_path}}/log/access.log); })-verbose(); desc(Shows caddy syslog); task(logs:caddy, function () { run(sudo journalctl -u caddy -f); })-verbose();logs:accessrecipe/provision/website.php以tail -f实时跟踪站点访问日志对应 Caddyfile 中配置的{{deploy_path}}/log/access.loglogs:caddyrecipe/provision/website.php通过journalctl -u caddy -f实时查看 Caddy 服务的系统日志启动错误、证书签发、配置加载等两个任务均带-verbose()标记适合在部署或排障时以dep logs:access、dep logs:caddy直接运行。与整体供给流程的协同验证供给流程的收尾任务provision:verifyrecipe/provision.php会用fetch({{domain}}, ...)对{{domain}}发起 HTTP 请求若返回码为404则说明 Caddy 已正确接管该域名并命中服务器级 404 页面/var/deployer/404.html从而判定供给成功。这直接印证了 Website Recipe 的输出Caddyfile、404 页面是供给验收的关键依据。此外Website Recipe 正常工作还依赖前置的用户供给provision:userrecipe/provision/user.php会创建deployer用户并将其加入www-data与caddy组这正是provision:server中usermod -a -G www-data caddy与become(deployer)得以成立的前提。实战建议与注意事项交互参数提前固化domain、public_path等参数由ask()驱动在 CI 或无人值守环境会触发WillAskUser异常见 src/functions.php。建议在deploy.php中通过-set(domain, example.com)-set(public_path, public)显式声明以 root/供给用户运行provision:server、provision:website会切换remote_user为provision_user默认 rootlogs:caddy需要 sudo 权限请确保 SSH 登录身份具备相应权限重复执行安全Caddyfile 的 diff 协商、grep -q幂等追加、mkdir -p、[ -d ... ] || mkdir等写法使整个 Website Recipe 可以反复运行而不会破坏已有配置版本与平台前提供给体系仅支持 Ubuntu 20recipe/provision.php且依赖ppa:ondrej/php与 Caddy 官方源provision:update任务中配置请确保目标机可访问这些源发布与日志配合站点根目录指向current/{{public_path}}发布新版本使用标准 release/symlink 流程即可排障时可先logs:caddy看服务状态再logs:access看请求链路。延伸阅读Website Recipe 官方文档 与 Provision Recipe 文档配套模板Caddyfile、404 页面依赖的前置供给用户供给 user.php、PHP 供给 php.php供给主流程recipe/provision.php任务与配置函数底层实现src/functions.php、src/Configuration.php部署发布流程release 任务、symlink 任务赞分享DevOpsCI/CDCLI开发工具运维【免费下载链接】deployerThe PHP deployment tool with support for popular frameworks out of the box项目地址https://gitcode.com/gh_mirrors/de/deployer点击查看免费下载相关推荐Deployer Cleanup Recipe 详解自动清理旧版本 release保持服务器整洁Deployer Cleanup Recipe 详解自动清理旧版本 release保持服务器整洁 导读 在 Deployer 基于符号链接symlinkDevOpsCI/CDCLI开发工具运维Caddy服务器中错误处理与日志跳过的技术解析Caddy服务器中错误处理与日志跳过的技术解析 在Caddy服务器配置中开发者经常需要处理反向代理场景下的错误响应和日志记录问题。本文深入探讨了Caddyfi后端API网关网络Deployer Provision Recipe 详解从裸机到可部署 Web 服务器的全自动配置指南Deployer Provision Recipe 详解从裸机到可部署 Web 服务器的全自动配置指南 Provision Recipe 是 DeployerDevOpsCI/CDCLI开发工具运维创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考