DevOpsCI/CDCLI开发工具运维【免费下载链接】deployerThe PHP deployment tool with support for popular frameworks out of the box项目地址https://gitcode.com/gh_mirrors/de/deployer点击查看免费下载本文是 DeployerPHP 部署工具的入门实战教程。你将在其中学会三件事如何用dep init初始化项目配方recipe、如何用provision配方把一台全新 Ubuntu 服务器自动装好运行环境PHP、Caddy、数据库、防火墙等以及如何用dep deploy完成首次部署并理解部署后的目录结构与常见运维操作。读完本文你可以独立完成一台裸机 → 一个可访问网站的全流程并掌握部署失败排查、版本回滚、自定义构建任务等进阶能力。1. 准备工作安装 Deployer 并初始化项目1.1 三种安装方式Deployer 支持全局安装、项目安装和 Phar 三种方式详见 docs/installation.md全局安装日常开发推荐通过 Composer 或 Phive 安装可在任意目录使用dep命令。composer global require deployer/deployer或phive install deployer安装后需确保 Composer 的全局 bin 目录在PATH中如~/.composer/vendor/bin在.bashrc/.zshrc中追加后执行source生效。项目安装CI/CD 推荐将 Deployer 版本按项目锁定适合流水线场景composer require --dev deployer/deployer alias depvendor/bin/depPhar 单文件无需 Composer直接下载deployer.phar后提交到仓库即可锁定版本用php deployer.phar init初始化。此外还可以安装 shell 自动补全覆盖任务名、选项、主机与配置项dep completion bash /etc/bash_completion.d/deployer # Bash dep completion zsh ~/.zsh/completion/_deployer # Zsh dep completion fish ~/.config/fish/completions/deployer.fish # Fish1.2dep init生成了什么在项目目录下运行dep init交互式回答提示配方语言、项目模板、仓库地址、主机列表等后Deployer 会在当前目录生成deploy.phpPHP 配方或deploy.yaml/deploy.mamlMAML 配方其中定义了主机hosts、任务tasks和导入的配方。从 src/Command/InitCommand.php 的源码可以看到初始化过程的细节它会自动读取git remote get-url origin作为默认仓库地址并以当前目录名作为默认项目名生成 PHP 配方时默认结构如下对应php()方法?php namespace Deployer; require recipe/common.php; // Config set(repository, gitgithub.com:you/project.git); add(shared_files, []); add(shared_dirs, []); add(writable_dirs, []); // Hosts host(example.org) -set(remote_user, deployer) -set(deploy_path, ~/project); // Hooks after(deploy:failed, deploy:unlock);其中require recipe/common.php是关键框架配方如 Laravel、Symfony、WordPress 等都会继承 common 配方它汇总了部署全流程的子任务与核心配置。1.3 配方与 CLI 的基本概念Deployer 的核心是两个概念hosts与tasks见 docs/basics.md。CLI 的用法是dep task selector配方只有一个主机时自动选中不传 selector 时会询问选择哪个主机传all表示所有主机默认加载当前目录的deploy.php可用-f/--file指定其他文件。2. 第二步初始化一台全新的服务器Provision如果服务器已经配好可以跳过本节直接看第 3 节。provision配方的目标是把一台全新的Ubuntu服务器变成可直接部署网站的环境。2.1 准备工作VPS 与 SSH在 Linode、DigitalOcean、Vultr、AWS、GCP 等平台创建一台UbuntuVPS。provision配方以 Ubuntu 为目标平台。Provisioning 过程需要root 用户 SSH 密钥认证而新版 Ubuntu 镜像默认禁用需手动开启provisioning 完成后可再次关闭 root SSH。建议将 DNS 记录指向服务器 IP以便通过域名 SSH 连接。2.2 在deploy.php中定义主机定义主机至少需要两个配置项remote_user— SSH 用户名deploy_path— 服务器上的部署路径。host(example.org) -set(remote_user, deployer) -set(deploy_path, ~/example);如果服务器上只有root用户也没关系provision配方会自动创建并配置deployer用户。SSH 私钥建议放在~/.ssh/config中而不是写进配方Host * IdentityFile ~/.ssh/id_rsa2.3 执行 Provisioningdep provision常用选项覆盖-o即 override详见 docs/cli.mddep provision -o provision_useryour-user # 以非 root 用户连接 dep provision -o becomeroot # 通过 sudo 提权为 root整个流程约5 分钟交互式询问 PHP 版本、数据库类型等参数最终在deploy_path安装好服务网站所需的一切。2.4provision背后做了什么源码级解析从 recipe/provision.php 可以看到provision是一个group task组任务按顺序执行 15 个子任务task(provision, [ provision: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, ]);关键子任务的职责对应 docs/recipe/provision.md子任务职责provision:check检查系统是否为 Ubuntu 且版本 ≥ 20否则告警并可中止provision:configure收集domain、public_path、php_version、db_type等必需参数provision:update添加软件源ondrej/php PPA、Caddy 官方源并apt-get updateprovision:upgradeapt-get upgrade -ytimeout 900 秒provision:install安装 acl、git、nodejs、redis、fail2ban、ufw、caddy 等约 25 个软件包provision:ssh禁用 SSH 密码认证、重启 sshd、生成/root/.ssh/authorized_keysprovision:firewall用 ufw 放行 22/80/443 并强制启用provision:user创建deployer用户并配置provision:php安装所选 PHP 版本与扩展provision:databases按db_type安装 MySQL / PostgreSQL / SQLite 等provision:server/provision:website配置 Caddy 服务器与网站站点provision:verify请求{{domain}}期待返回 404 判定 provisioning 成功值得注意的是provision:check的 OS 校验逻辑它读取/etc/os-release非 Ubuntu 或版本低于 20 都会打印警告并要求二次确认体现了配方对 Ubuntu 平台的强绑定。provision:user、provision:php等子任务由 recipe/provision/ 下的独立配方文件提供。2.5 网站相关配置项provision:website涉及两个交互式配置见 docs/recipe/provision/website.mddomain— 默认值为ask( Domain: , get(hostname))即询问域名public_path— 默认public即网站的公共根目录。Caddy 会自动配置好并从public_path提供服务这也是第 4 节中 Nginx 示例里current/public的由来。3. 第三步dep deploy完成首次部署3.1 执行部署dep deploy3.2deploy任务的执行链deploy本身也是一个组任务定义在 recipe/common.phptask(deploy, [ deploy:prepare, deploy:publish, ]);其中deploy:prepare准备新发布依次执行deploy:info、deploy:setup、deploy:lock、deploy:release、deploy:update_code、deploy:env、deploy:shared、deploy:writabledeploy:publish发布依次执行deploy:symlink、deploy:unlock、deploy:cleanup、deploy:success。整个链路的完整说明见 docs/recipe/common.md。这里挑两个有代表性的子任务看实现deploy:setuprecipe/deploy/setup.php在服务器上创建标准的发布目录结构并做一次安全校验task(deploy:setup, function () { run(EOF [ -d {{deploy_path}} ] || mkdir -p {{deploy_path}}; cd {{deploy_path}}; [ -d .dep ] || mkdir .dep; [ -d releases ] || mkdir releases; [ -d shared ] || mkdir shared; EOF, ); // current_path 必须是符号链接而非目录否则拒绝部署 if (test([ ! -L {{current_path}} ] [ -d {{current_path}} ])) { throw error(There is a directory (not symlink) at {{current_path}}.\n Remove this directory so it can be replaced with a symlink for atomic deployments.); } });deploy:releaserecipe/deploy/release.php负责版本号管理从.dep/latest_release读取上次版本号并自增把release_name、时间戳、用户、target 等元信息追加写入.dep/releases_logJSON 行格式然后创建releases/n目录并将{{deploy_path}}/release软链到新版本。3.3 部署失败怎么办部署失败时Deployer 会打印错误信息以及导致失败的那条命令。常见原因是缺少.env文件或凭据数据库密码、API Key 等。就地修改服务器文件SSH 登录服务器直接编辑Deployer 会沿用配方中的主机配置别名、端口、私钥、remote_user等dep ssh连接后工作目录位于{{deploy_path}}若{{current_path}}存在则为其。从指定步骤继续执行修复问题后不必重头再来可以直接从失败的步骤续跑dep deploy --start-from deploy:migrate3.4 部署失败钩子deploy.php末尾生成的after(deploy:failed, deploy:unlock)保证部署失败时自动释放锁deploy:unlock避免锁文件残留导致后续部署被阻塞。deploy:failed钩子本身定义于 recipe/common.php 中。4. 第四步部署后的目录结构与服务器配置4.1 服务器目录布局首次部署成功后~/example即deploy_path下的结构如下~/example // deploy_path |- current - releases/1 // 指向当前版本的软链 |- releases // 存放所有历史版本 |- 1 // 最新版本 |- ... |- .env - shared/.env // 软链到共享的 .env |- shared // 版本间共享的文件 |- ... |- .env // 共享的 .env |- .dep // Deployer 配置/状态文件这种release 目录 current 软链的结构是原子部署atomic deployment的基础current只是一条符号链接切换版本就是重定向链接不会出现发布到一半的状态。.dep目录中的关键状态文件从 recipe/deploy/release.php 源码可确认包括.dep/latest_release— 当前最新版本号.dep/releases_log— 每次发布的元信息日志JSON 行releases命令与回滚逻辑都依赖它。4.2 Web 服务器配置把 Web 服务器指向current目录即可。Nginx 示例root /home/deployer/example/current/public; index index.php; location / { try_files $uri $uri/ /index.php?$query_string; }若使用provision配方则无需手动配置——Caddy 已被自动配置好从public_path提供网站服务。4.3 常用配置项速查来自 docs/recipe/common.md以下配置在部署流程中高频出现配置项默认值说明deploy_path无未设置则抛异常部署路径必填可用~/{{alias}}一次设置多主机current_path{{deploy_path}}/current当前版本路径可覆盖为/var/public_html等repository要部署的 Git 仓库keep_releases10releases目录中保留的版本数由deploy:cleanup清理default_timeout300run()/runLocally()的默认超时秒设null可禁用env[]远端环境变量可按run()调用单独覆盖dotenvfalse每次run()前加载的.env文件路径user自动推断部署者名字CI 环境优先读取GITLAB_USER_NAME、GITHUB_ACTOR等变量bin/php、bin/git自动探测PHP / Git 可执行文件路径指定php_version时用/usr/bin/php{{php_version}}use_relative_symlink自动探测是否用ln --relative创建相对软链bin/symlinkln -nfs [--relative]软链命令sudo_askpass.dep/sudo_pass临时 sudo 密码脚本路径用完即删5. 第五步添加自定义构建任务前端资源如 npm 打包通常放在代码更新之后执行。在deploy.php中定义任务并挂到deploy:update_code之后task(build, function () { cd({{release_path}}); run(npm install); run(npm run prod); }); after(deploy:update_code, build);要点说明{{release_path}}是本次发布的新版本目录在部署过程中由deploy:release创建的软链{{deploy_path}}/release解析而来源码见 recipe/deploy/release.php构建产物会写入新版本而不是current保证构建失败不影响线上版本。after(deploy:update_code, build)是 Deployer 的钩子机制任务编排的完整说明见 docs/tasks.md。可以用dep tree deploy直观查看任务树确认build被正确挂载在deploy:update_code之后详见 docs/cli.md 中的 tree 命令示例。6. 查看与回滚部署6.1 查看发布列表dep releases输出示例时间自动按本地时区转换------------------------------ deployer.org -------------------------- | Date (UTC) | Release | Author | Target | Commit | --------------------------------------------------------------------- | 2021-11-05 14:00:22 | 1 (current) | Anton Medvedev | HEAD | 943ded2be | ---------------------------------------------------------------------从源码看该命令读取.dep/releases_log并按时间渲染表格状态列支持三种标记(current)— 当前线上版本(bad)— 已被回滚逻辑标记为坏版本存在BAD_RELEASE文件(dirty)— 存在DIRTY_RELEASE标记的版本。Commit 列来自各版本目录中的REVISION文件。6.2 回滚到上一个版本dep rollback回滚逻辑见 recipe/deploy/rollback.php分为三步读取releases/并挑选current之前最近的一个未标记BAD_RELEASE的版本作为候选将current软链重新指向该候选版本在旧版本目录中写入BAD_RELEASE文件内容为时间戳与用户使其在后续回滚中被自动跳过。也可以显式指定回滚目标dep rollback -o rollback_candidate1236.3 开发期快速同步dep push日常开发中频繁部署很繁琐docs/recipe/deploy/push.md 提供的push任务会把本地改动打包成 patch 直接推送到主机并应用到current_path不经过 Git可多次执行专供开发环境使用dep push7. 常用辅助命令更多 CLI 能力见 docs/cli.md这里列出与部署工作流强相关的几个覆盖配置dep deploy -o ssh_multiplexingtrue -o branchmaster-o可多次使用覆盖任意配置项任意命令执行dep run uptime -p all在选中主机上跑一次性命令支持-t/--timeout、-r/--raw查看解析后的配置dep config all输出各主机解析后的配置支持--formatjson/--formatmaml适合排查变量插值问题预览执行计划dep deploy --plan all打印每个主机的任务执行表而不实际执行方便确认任务编排与并行限制查看日志dep logs:app跟踪应用日志需配置log_files。总结从本文可以看出Deployer 把服务器初始化和应用部署两条链路都做成了可组合的任务体系初始化链路由provision组任务驱动15 个子任务覆盖系统检查、软件安装、SSH 加固、防火墙、PHP/Node/数据库、Caddy 网站配置与最终验证部署链路由deploy:preparedeploy:publish两个阶段组成以release 目录 current 软链实现原子切换并配套版本回滚BAD_RELEASE标记、开发期快速推送dep push与失败续跑--start-from等机制。掌握了dep init→dep provision→dep deploy这条主线再结合dep releases、dep rollback、dep ssh、dep config等辅助命令你就拥有了从零到一部署并长期运维 PHP 项目的基础能力。更深入的配置项如shared_files、writable_dirs、env、dotenv与各框架专属配方可在 docs/recipe/common.md 及各框架文档如 docs/recipe/laravel.md、docs/recipe/symfony.md中继续查阅。赞分享DevOpsCI/CDCLI开发工具运维【免费下载链接】deployerThe PHP deployment tool with support for popular frameworks out of the box项目地址https://gitcode.com/gh_mirrors/de/deployer点击查看免费下载相关推荐Prisma 入门实战将首个 Prisma 服务部署到 Demo Server 的完整指南Prisma 入门实战将首个 Prisma 服务部署到 Demo Server 的完整指南 本文以 Prisma 1.x 时代的经典入门工作流为主线带你完成后端数据库GraphQLMCP服务器实战指南从入门到精通的完整教程MCP服务器Model Context Protocol Servers正在彻底改变AI开发的工作方式它们为大型语言模型提供了安全可控的数据访问能力。无论MCP 服务AI 应用后端Redwood 服务器部署入门SSH 连接远程服务器的完整实战指南Redwood 服务器部署入门SSH 连接远程服务器的完整实战指南 如果你打算使用 Redwood 的 Baremetal裸机部署方案把应用部署到一台真后端前端Web框架开发工具上一篇Godot游戏开发新手必看GGT模板让你30分钟启动项目下一篇MCP Python SDK 入门指南从零构建、运行并测试你的第一个 MCP 服务器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
