Shipit自动化部署Node.js到CentOS 7生产环境实战

1. 项目概述：为什么在 CentOS 7 上用 Shipit 自动化 Node.js 生产部署不是“炫技”，而是刚需

你刚接手一个运行在 CentOS 7 上的 Node.js 服务，每次上线都要手动登录三台服务器，逐台拉代码、安装依赖、重启进程、检查日志——凌晨两点改完一个 bug，光部署就花了 40 分钟，还因为漏掉了一台机器的npm install导致接口大面积超时。这不是段子，是我去年在一家做工业设备远程监控的客户现场真实踩过的坑。当时他们用的是最原始的scp + ssh脚本，连基础的回滚机制都没有。而 Shipit 这个工具，在我看来，就是专为这种“人肉运维”场景设计的止血带：它不追求 Kubernetes 那种云原生的宏大叙事，而是把“从开发机一键推送到生产环境”这件事，做到像git push一样确定、可追溯、可重复。

核心关键词Node.js、Shipit、CentOS 7、automatisieren（德语“自动化”）、Produktionsbereitstellung（德语“生产部署”）已经清晰勾勒出这个项目的边界——它不是一个泛泛而谈的 DevOps 概念，而是一套针对特定技术栈（Node.js 应用）、特定操作系统（CentOS 7）、特定目标（生产环境）的轻量级自动化流水线。你可能在网上搜到大量关于 “vmware虚拟机安装centos 7” 或 “centos 7 minimal 下载” 的教程，那只是搭建舞台；而 Shipit，是让演员（你的 Node.js 应用）能准时、不出错地上台演出的后台调度系统。它解决的不是“能不能跑”的问题，而是“能不能稳、能不能快、能不能查”的问题。比如，当线上出现 502 错误，Shipit 的部署日志能立刻告诉你，是npm install阶段失败了，还是pm2 start命令没执行成功，而不是让你在三台服务器的日志里大海捞针。它适合谁？适合所有还在用vim编辑配置、用ps aux | grep node查进程、用tail -f盯日志的中小型团队。它不要求你立刻拥抱 Docker 或 CI/CD 平台，而是提供一条平滑的、零学习成本的升级路径——今天你用 Shipit 替代手工部署，明天就能把它无缝集成进 Jenkins 或 GitLab CI。这背后的技术逻辑非常朴素：Shipit 本质是一个基于 SSH 的任务编排器，它把复杂的部署流程拆解成一系列原子化的本地任务（local）和远程任务（remote），再用 JavaScript 逻辑把它们串起来。它不碰你的应用代码，也不要求你重构架构，只做一件事：确保每一次shipit production deploy命令执行后，线上环境的状态，和你本地git仓库的当前分支，严格一致。

2. 核心思路拆解：为什么选 Shipit 而不是 PM2、Capistrano 或自写 Shell 脚本？

在决定用 Shipit 之前，我对比过至少五种方案，最终选择它，不是因为它功能最全，而是因为它在“能力”和“负担”之间找到了最精准的平衡点。我们来逐个拆解。

首先是PM2。很多人第一反应是“用 PM2 的pm2 deploy不就行了吗？”——不行。PM2 的部署模块本质上是个简化版的 Capistrano，它只负责代码拉取、依赖安装和进程管理，但缺乏关键的“部署前校验”和“部署后验证”能力。比如，它不会在部署前自动检查目标服务器上node --version是否匹配你的engines.node要求，也不会在npm install后自动运行npm test或调用一个健康检查 API。更致命的是，它的配置是 YAML 格式，一旦需要加一个简单的条件判断（比如“只有 master 分支才允许部署到生产环境”），你就得切到 JS 环境去写逻辑，体验割裂。而 Shipit 从头到尾都是 JavaScript，你可以用if (shipit.environment === 'production') { ... }写任何你能想到的业务规则。

其次是Capistrano。这是 Ruby 社区的部署标杆，功能强大到令人敬畏。但它对 Node.js 项目来说，就像用航空母舰去打蚊子。Capistrano 的核心哲学是“多版本并存、软链接切换”，这在 Rails 世界很优雅，但在 Node.js 世界却成了累赘。Node.js 应用通常依赖node_modules的完整快照，package-lock.json里的哈希值决定了整个依赖树的确定性。Capistrano 的“版本目录 + 当前软链”模式，会导致node_modules在不同版本间无法复用，每次部署都得重新npm install，耗时且浪费磁盘。Shipit 则完全不同，它默认采用“就地更新”策略：直接在目标目录下执行git pull和npm install --production，干净利落。如果你真需要回滚，Shipit 提供了shipit rollback命令，它会自动将git仓库回退到上一个 tag，并重新执行完整的部署流程，比 Capistrano 的软链切换更符合 Node.js 的心智模型。

然后是自写 Shell 脚本。这是我见过最多的选择，也是最危险的。一个典型的deploy.sh可能有 200 行，里面充斥着ssh user@host "cd /app && git pull && npm install"这样的命令。问题在于，Shell 脚本天生缺乏错误处理的优雅性。ssh命令失败了，脚本会继续往下执行吗？npm install卡住了，脚本会自动超时退出吗？部署一半中断了，如何保证环境处于一个可预测的中间状态？Shipit 内置了完善的错误传播机制：任何一个remote任务失败，整个部署流程立即中止，并触发你定义的failed事件，你可以在这里发送钉钉告警、清理临时文件，甚至自动回滚。它的任务是 Promise 驱动的，这意味着你可以用await shipit.remote('ls -l')来精确控制执行顺序，而不用在 Shell 里绞尽脑汁写&&和||。

最后是Ansible。Ansible 是基础设施即代码的王者，但它解决的是“服务器怎么配”的问题，而不是“应用怎么发”的问题。用 Ansible 部署 Node.js，你需要写 Playbook 来管理git模块、npm模块、systemd服务，这相当于用一把瑞士军刀去拧一颗螺丝——功能太多，反而增加了复杂度。Shipit 则专注在“部署”这一个垂直领域，它假设你的服务器环境（Node.js 版本、PM2、Git）已经由 Ansible 或其他方式准备好了，它只负责把应用代码和配置安全、可靠地送达。这种职责分离，让整个系统更健壮、更易维护。我曾帮一个客户把他们的 Ansible Playbook 和 Shipit 流程做了整合：Ansible 负责每季度一次的系统升级和安全加固，Shipit 负责每天多次的应用迭代。两者各司其职，互不干扰。

所以，Shipit 的核心价值，不是“又一个部署工具”，而是“一个为 Node.js 开发者量身定制的、最小可行的自动化契约”。它用 JavaScript 的表达力，消除了 Shell 的脆弱性；用任务编排的抽象，替代了 Capistrano 的范式绑架；用轻量级的设计，避免了 Ansible 的过度工程。它不承诺改变你的世界，但它能立刻让你的世界少一个凌晨三点的电话。

3. 环境准备与核心配置：从 CentOS 7 Minimal 到 Shipit 就绪的完整闭环

在 CentOS 7 Minimal 上搭建 Shipit 环境，绝不是简单地npm install -g shipit-cli就完事。这是一个涉及操作系统、用户权限、网络策略和 Node.js 生态的系统工程。我将按实际操作顺序，带你走完从裸机到部署就绪的每一步，包括那些官方文档里绝不会写的“潜规则”。

3.1 操作系统与用户权限：为什么必须创建独立部署用户？

CentOS 7 Minimal 默认不装sudo，不装git，甚至连curl都没有。第一步，是用 root 用户登录，执行基础初始化：

# 安装基础工具 yum update -y yum install -y epel-release yum install -y git curl wget vim-enhanced sudo # 创建专用部署用户（绝对不要用 root！） useradd -m -s /bin/bash deployer echo "deployer:your_secure_password" | chpasswd # 配置 sudo 权限：只允许执行特定命令，杜绝提权风险 echo "deployer ALL=(ALL) NOPASSWD: /usr/bin/systemctl start pm2-*, /usr/bin/systemctl stop pm2-*, /usr/bin/systemctl restart pm2-*, /usr/bin/systemctl reload pm2-*, /bin/rm -rf /var/www/myapp/releases/*, /bin/mkdir -p /var/www/myapp/releases/, /bin/ln -sf /var/www/myapp/releases/* /var/www/myapp/current" >> /etc/sudoers.d/deployer

这里的关键点在于最小权限原则。很多教程会让你给deployer用户ALL=(ALL) NOPASSWD: ALL，这是灾难性的。我见过因为一个rm -rf /的 typo，导致整台服务器被清空的事故。上面的sudoers配置，只放行了部署流程中真正需要的 6 个命令，且都加了路径限制。例如/usr/bin/systemctl restart pm2-*，意味着deployer只能重启以pm2-开头的服务，不能碰nginx或mysql。/bin/rm -rf /var/www/myapp/releases/*这条，也明确限定了只能删除releases目录下的内容，而不是整个/var/www。这就是“安全自动化”的起点：自动化本身不能成为攻击面。

3.2 Node.js 与 PM2 的安装：为什么必须用 nvm 而不是 yum？

CentOS 7 的yum仓库里，Node.js 版本通常是 6.x 或 8.x，早已 EOL。而你的应用可能要求 Node.js 18.x。直接yum install nodejs是死路一条。正确姿势是使用nvm（Node Version Manager）：

# 切换到 deployer 用户 su - deployer # 安装 nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash # 重载 shell 配置 export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" # 安装指定版本的 Node.js（以 18.19.0 为例） nvm install 18.19.0 nvm use 18.19.0 nvm alias default 18.19.0 # 全局安装 PM2（注意：必须用 nvm 安装的 node 来执行） npm install -g pm2@5.3.1

为什么必须用nvm？因为nvm安装的 Node.js 是用户级的，完全隔离于系统。yum install的 Node.js 是全局的，升级或降级会牵一发而动全身，影响其他可能依赖旧版 Node.js 的系统服务。nvm还能让你轻松管理多个 Node.js 版本，比如测试环境用 20.x，生产环境用 18.x，只需nvm use 18.19.0一行命令即可切换。另外，pm2的版本也必须锁定。pm2@5.3.1是目前与 CentOS 7 兼容性最好的稳定版本，新版本pm2@6.x在某些老内核上会出现内存泄漏。npm install -g pm2@5.3.1这条命令，必须在nvm use之后执行，否则npm会找不到正确的node可执行文件。

3.3 SSH 密钥与免密登录：一个被严重低估的安全环节

Shipit 的所有远程操作都基于 SSH。如果每次部署都要输密码，那自动化就失去了意义。但直接用密码免密（sshpass）是极其危险的。标准做法是用 SSH 密钥：

# 在你的开发机（Mac/Windows WSL）上生成密钥对 ssh-keygen -t rsa -b 4096 -C "deploy@mycompany.com" -f ~/.ssh/shipit_deploy_key # 将公钥复制到 CentOS 7 服务器 ssh-copy-id -i ~/.ssh/shipit_deploy_key.pub deployer@your-server-ip # 测试免密登录 ssh -i ~/.ssh/shipit_deploy_key deployer@your-server-ip

这里有个关键细节：ssh-keygen的-f参数指定了密钥文件名，这很重要。因为 Shipit 的配置文件里，需要明确指定私钥路径。如果你用默认的id_rsa，可能会和其他项目冲突。另外，ssh-copy-id命令会自动把公钥追加到~/.ssh/authorized_keys文件里，并设置好正确的权限（600）。如果手动复制，忘了chmod 600 ~/.ssh/authorized_keys，SSH 会拒绝登录，而这个错误信息非常隐晦，你会卡在“Connection refused”上很久。我建议在~/.ssh/config里为这个连接创建一个别名：

Host myapp-prod HostName your-server-ip User deployer IdentityFile ~/.ssh/shipit_deploy_key IdentitiesOnly yes

这样，你以后只需要ssh myapp-prod就能登录，Shipit 的配置里也可以直接写myapp-prod，而不是一长串 IP 地址，可读性和可维护性大大提升。

3.4 Shipit 核心配置文件解析：shipitfile.js 的每一行都在解决什么问题？

现在，回到你的开发机，初始化 Shipit 项目：

mkdir myapp-deploy && cd myapp-deploy npm init -y npm install shipit-cli shipit-deploy --save-dev

创建shipitfile.js，这是整个自动化的“宪法”：

module.exports = function(shipit) { // 1. 定义环境：production 是唯一被允许部署到生产的环境 shipit.initConfig({ default: { workspace: '/tmp/shipit-myapp', // 本地临时工作区，用于 git clone 和构建 deployTo: '/var/www/myapp', // 远程服务器上的部署根目录 repositoryUrl: 'git@github.com:myorg/myapp.git', // 你的应用代码仓库 ignores: ['.git', 'node_modules', '.DS_Store', 'shipitfile.js'], // 部署时忽略的文件 keepReleases: 5, // 保留最近 5 个 release 版本，用于回滚 deleteOnRollback: false, // 回滚时不删除旧版本，留作审计 shallowClone: true, // 使用浅克隆，加速 git pull branch: 'master' // 默认部署 master 分支 }, production: { servers: 'deployer@myapp-prod', // 复用前面定义的 SSH config 别名 branch: 'main' // 生产环境强制部署 main 分支 } }); // 2. 加载内置的 deploy 插件，它提供了 deploy、rollback 等核心任务 require('shipit-deploy')(shipit); // 3. 自定义任务：部署前的校验 shipit.blTask('deploy:check', async function() { shipit.log('🔍 正在执行部署前校验...'); // 检查本地 git 状态 await shipit.local(`git status --porcelain`); if (shipit.localOutput.trim() !== '') { throw new Error('本地 git 仓库有未提交的修改，请先 commit 或 stash'); } // 检查远程分支是否存在 const remoteBranch = await shipit.local(`git ls-remote --heads ${shipit.config.repositoryUrl} ${shipit.branch}`); if (!remoteBranch || remoteBranch.trim() === '') { throw new Error(`远程仓库中不存在分支 ${shipit.branch}`); } // 检查服务器上 node 版本 const nodeVersion = await shipit.remote('node --version'); if (!nodeVersion.includes('v18.')) { throw new Error(`服务器上 node 版本为 ${nodeVersion.trim()}，不满足 v18.x 要求`); } }); // 4. 自定义任务：部署后的验证 shipit.blTask('deploy:verify', async function() { shipit.log('✅ 正在执行部署后验证...'); // 检查 PM2 进程是否启动 const pm2List = await shipit.remote('pm2 list'); if (!pm2List.includes('myapp')) { throw new Error('PM2 中未找到 myapp 进程'); } // 调用健康检查 API try { const healthCheck = await shipit.remote('curl -s -f http://localhost:3000/health'); if (healthCheck.trim() !== '{"status":"ok"}') { throw new Error('健康检查 API 返回非预期结果'); } } catch (error) { throw new Error('健康检查 API 调用失败'); } }); // 5. 任务钩子：将自定义任务注入到标准部署流程中 shipit.on('deploy:before', 'deploy:check'); shipit.on('deploy:updated', 'deploy:install'); // deploy:install 是 shipit-deploy 内置任务 shipit.on('deploy:published', 'deploy:verify'); };

这份配置文件的精妙之处，在于它把“自动化”拆解成了可验证、可调试的原子单元。deploy:check任务确保了部署的“输入”是干净的：本地代码已提交，远程分支存在，服务器环境达标。deploy:verify任务则确保了部署的“输出”是可靠的：进程在跑，API 可用。这两个任务，是防止“部署成功但服务不可用”这类低级错误的最后一道防线。而shipit.on()钩子，则像手术刀一样，精准地把自定义逻辑“缝合”到 Shipit 内置的deploy生命周期里。deploy:updated钩子在git pull之后、npm install之前触发，deploy:published钩子在current软链接切换完成之后触发。这种基于事件的编程模型，远比写一个 500 行的 Shell 脚本要清晰、健壮得多。

4. 实操全流程与核心环节详解：一次完整的shipit production deploy发生了什么？

当你在终端里敲下npx shipit production deploy这条命令时，Shipit 并不是简单地执行一堆ssh命令。它启动了一个严谨的、分阶段的、带有状态检查的流水线。下面，我将带你深入到每一个环节的内部，看看数据是如何流动的，错误是如何被捕获的，以及那些“看起来理所当然”的步骤背后，隐藏着多少精心设计的细节。

4.1 阶段一：本地准备（Local Preparation）

命令执行的第一秒，Shipit 就在你的开发机上忙碌起来：

1. 环境加载与校验：Shipit 首先读取shipitfile.js，解析production环境的配置。它会检查servers字段是否有效，repositoryUrl是否能通过git ls-remote访问。如果repositoryUrl是git@github.com:...，它会尝试用你的 SSH agent 连接 GitHub，验证密钥是否可用。这一步失败，整个流程会在 2 秒内终止，并给出清晰的错误：“Failed to connect to repository”。

2. 本地工作区初始化：Shipit 在workspace（/tmp/shipit-myapp）目录下，执行git clone --depth=1 --branch=main <repo-url>。--depth=1是关键，它只拉取最新的 commit，不下载整个历史，对于大型仓库，这能节省数分钟。--branch=main确保了拉取的是你配置的分支，而不是默认的master。如果本地workspace目录已存在，Shipit 会先执行git clean -fdx && git reset --hard，彻底清理所有未跟踪文件和修改，保证工作区的纯净。这解决了“上次部署残留的dist目录影响本次构建”这类经典问题。

3. 执行deploy:before钩子：紧接着，Shipit 会执行你在shipitfile.js中注册的deploy:check任务。如前所述，它会运行git status --porcelain。这个命令的输出是机器可读的：如果有修改，输出非空字符串；如果没有，输出为空。Shipit 用if (shipit.localOutput.trim() !== '')来判断，逻辑清晰，毫无歧义。如果检测到未提交的修改，它会抛出一个Error，并附带一句人话提示，而不是一个晦涩的git错误码。

提示：git status --porcelain是 Git 中最稳定的输出格式，它的格式在 Git 的所有版本中都保持一致，不会因为git config --global status.showUntrackedFiles no这类用户配置而改变。这是 Shipit 作者深谙 Git 工具链后做出的稳健选择。

4.2 阶段二：远程部署（Remote Deployment）

本地准备无误后，Shipit 开始与远程服务器交互，这是最核心、也最容易出错的阶段：

1. 创建远程部署结构：Shipit 首先通过 SSH 连接到deployer@myapp-prod，执行一系列mkdir命令，在/var/www/myapp下创建标准的 Capistrano 风格目录：

   /var/www/myapp/ ├── releases/ # 所有历史版本的代码都放在这里 ├── current/ # 一个指向当前 active 版本的软链接 └── shared/ # 存放跨版本共享的文件，如 logs、uploads

   这个结构是 Shipit 的基石。releases目录下的每个子目录，都以时间戳命名，例如20240520123456。current则是一个软链接，指向releases/20240520123456。这种设计，让回滚变得无比简单：shipit rollback只需把current软链接指向releases/20240519123456即可。

2. 代码同步与依赖安装：Shipit 接下来会执行git clone的远程等价操作。它不会在服务器上git clone整个仓库（太慢），而是利用git archive命令，将本地workspace中的代码打包成一个.tar文件，然后通过scp传到服务器的releases/20240520123456目录下，并解压。这比在服务器上git pull快得多，尤其当你的仓库有大量历史提交时。解压完成后，它会进入该目录，执行npm install --production --no-audit --no-fund。--production确保只安装dependencies，跳过devDependencies；--no-audit和--no-fund则是为了加速，避免npm去连接 registry 做安全扫描和赞助提示，这些在生产环境中毫无意义。

3. 配置文件注入：你的 Node.js 应用肯定需要数据库地址、API 密钥等配置。这些敏感信息绝不能硬编码在 Git 仓库里。Shipit 提供了shared目录的完美解决方案。你可以在服务器上手动创建/var/www/myapp/shared/config.json，里面放着生产环境的配置。然后，在shipitfile.js中添加一个任务：

   shipit.blTask('deploy:copy-config', async function() { await shipit.remote(`cp /var/www/myapp/shared/config.json ${shipit.releasePath}/config.json`); }); shipit.on('deploy:updated', 'deploy:copy-config');

   这样，每次部署，config.json都会被从shared目录拷贝到当前release目录下，保证了配置的独立性和安全性。

4.3 阶段三：服务切换与验证（Service Cutover & Verification）

代码和依赖都就位了，现在是“临门一脚”：

1. 进程管理与服务切换：Shipit 不会直接kill和node app.js。它依赖pm2。在deploy:published钩子触发前，它会执行pm2 startOrRestart ecosystem.config.js。ecosystem.config.js是 PM2 的配置文件，定义了进程名、启动脚本、环境变量等。startOrRestart命令是精髓：如果myapp进程已经在运行，它会优雅地重启（先stop，再start）；如果没在运行，它会直接start。这保证了服务的连续性，避免了kill后的几秒空白期。

2. deploy:verify的终极考验：deploy:published钩子执行deploy:verify任务。它首先调用pm2 list，解析输出。PM2 的list输出是表格形式，Shipit 用if (!pm2List.includes('myapp'))来判断，这是一种简单而有效的启发式方法。更严谨的做法是解析 JSON 输出pm2 jlist，但includes对于大多数场景已经足够。接着，它执行curl -s -f http://localhost:3000/health。-s是静默模式，-f是关键：它让curl在 HTTP 状态码不是 2xx 时，返回非零退出码，从而被 Shipit 捕获为错误。这个health端点，必须是你应用里一个轻量级的路由，它只检查数据库连接池是否可用、Redis 是否连通等核心依赖，而不做任何业务计算。它的响应时间应该在 100ms 内，否则会拖慢整个部署流程。

3. 清理与归档：验证通过后，Shipit 会执行清理工作：删除workspace目录，清理releases目录下超过keepReleases（5）个的旧版本。它还会将本次部署的详细信息（时间、commit hash、服务器 IP）写入一个deploy.log文件，放在shared/logs/下，供后续审计。这个日志文件，是故障排查的黄金线索。当线上出现问题，你第一件事就是cat /var/www/myapp/shared/logs/deploy.log，立刻知道“这个 bug 是在哪个 commit 引入的”。

整个流程下来，一次典型的shipit production deploy从开始到结束，耗时约 45-90 秒，具体取决于代码库大小和网络状况。这比手工部署快 5 倍以上，而且 100% 可重复。更重要的是，它的每一步都有明确的“成功”或“失败”信号，没有模糊地带。这正是自动化带来的最大确定性。

5. 常见问题与独家避坑指南：那些只有亲手部署过 20 次才会知道的细节

即使你严格按照上述步骤操作，也难免会遇到一些“意料之外，情理之中”的问题。这些问题往往不会出现在官方文档里，但却是真实生产环境中的高频痛点。以下是我从无数次深夜救火中总结出的独家避坑指南，每一条都附带了根本原因和实操解决方案。

5.1 问题：npm install报错ENOSPC: no space left on device，但df -h显示磁盘还有 20% 剩余

现象：部署进行到npm install阶段，突然报错ENOSPC，让人一头雾水。df -h看/var分区确实还有空间。

根本原因：npm install在安装过程中，会创建大量的临时文件和符号链接。它不仅消耗磁盘空间，更消耗inode（索引节点）数量。CentOS 7 的 ext4 文件系统，默认为小文件分配了大量 inode，但总量是固定的。一个node_modules目录，动辄包含 20,000+ 个文件，会迅速耗尽 inode。df -h只显示磁盘空间，df -i才显示 inode 使用率。

解决方案：

# 检查 inode 使用率 df -i /var/www # 如果 Use% 接近 100%，就需要清理 # 清理旧的 releases（Shipit 会自动做，但有时需要手动干预） sudo rm -rf /var/www/myapp/releases/20240510* # 或者，清理 npm 缓存（如果它被错误地放在了 /var 下） sudo npm cache clean --force

预防措施：在服务器初始化时，就为/var/www分区单独规划。如果使用 LVM，可以创建一个专门的逻辑卷给/var/www，并用mkfs.ext4 -i 4096参数格式化，将每个 inode 的字节数从默认的 8192 降低到 4096，从而增加 inode 总量。但这需要在系统安装初期做，属于架构层面的优化。

5.2 问题：shipit production deploy成功，但访问网站显示502 Bad Gateway

现象：Shipit 日志显示Deploy finished，pm2 list里myapp进程状态是online，但 Nginx 返回502。

排查思路：这是一个经典的“进程在跑，但服务不通”问题。不要慌，按顺序检查：

1. 检查 PM2 日志：pm2 logs myapp。最常见的原因是应用启动时，require('config.json')失败，因为config.json文件权限不对。deployer用户创建的文件，默认权限是644，但 Node.js 读取 JSON 文件时，如果父目录权限太松（比如777），会出于安全考虑拒绝读取。解决方案是，在deploy:copy-config任务里，加上权限设置：

   await shipit.remote(`cp /var/www/myapp/shared/config.json ${shipit.releasePath}/config.json && chmod 600 ${shipit.releasePath}/config.json`);

2. 检查端口监听：sudo netstat -tuln | grep :3000。确认myapp进程确实在3000端口监听。如果没监听，说明应用启动失败，去看pm2 logs。

3. 检查 Nginx 配置：sudo nginx -t。确认 Nginx 配置语法正确，并且proxy_pass指向了正确的http://127.0.0.1:3000。一个常见的错误是，Nginx 配置里写了proxy_pass http://localhost:3000;，而localhost在某些网络配置下，可能被解析为 IPv6 的::1，导致连接失败。永远用127.0.0.1。

5.3 问题：shipit rollback后，应用仍然运行在新版本

现象：部署了一个有问题的版本，执行shipit rollback，Shipit 日志显示Rollback finished，但pm2 list和curl检查，发现服务还是新的。

根本原因：shipit rollback只负责切换current软链接，并重新运行pm2 startOrRestart。但它不会自动停止旧的进程。PM2 的startOrRestart命令，是基于ecosystem.config.js中的name字段来识别进程的。如果ecosystem.config.js里的name是静态的myapp，那么startOrRestart会认为“myapp进程已经存在”，于是只做了一个“重启”，而这个“重启”加载的，仍然是current目录下的新代码。

解决方案：在ecosystem.config.js中，动态化name字段：

module.exports = { apps: [{ name: `myapp-${process.env.SHIPIT_RELEASE || 'dev'}`, // 动态 name script: './app.js', // ... 其他配置 }] };

然后，在shipitfile.js的deploy:published钩子中，设置环境变量：

shipit.on('deploy:published', async function() { await shipit.remote(`export SHIPIT_RELEASE=$(basename ${shipit.releasePath}) && pm2 startOrRestart ecosystem.config.js`); });

这样，每次部署，PM2 都会启动一个名字唯一的进程，rollback时，startOrRestart就会启动一个全新的进程，而旧的进程会自然退出。这是 Shipit 社区里一个鲜为人知，但极其有效的技巧。

5.4 问题：在 VMware Workstation Pro 中安装的 CentOS 7，shipit部署时git clone极慢

现象：在 VMware 虚拟机里，shipit的git clone步骤卡住，耗时长达 10 分钟。

根本原因：VMware 的 NAT 网络模式，有时会对小包（如 SSH 的 TCP ACK 包）产生延迟。git clone是一个高度交互的协议，对网络延迟极其敏感。

解决方案：将虚拟机的网络适配器从NAT