如何不重启地接管一个已经跑起来的应用
Adopt 模式 6 步:只读探测 → M1-M9 问答 → 警告分级 → 签字 → 镜像配置 + 接管前快照 → 写 ADOPTED 标记。绝不动你已经在跑的进程。
大多数 DevOps 工具默认你「从零开始」。但真实场景里,你的应用早就跑起来了 — 可能是去年自己 ssh 上服务器装的 Next.js 博客,也可能是某个客户半年前部署、现在你接手要维护的 FastAPI 服务。强行让这些应用走「全新部署」流程,意味着停机、迁移、重装,折腾且高风险。
我们做的是 Adopt 模式 — 把「已经在跑」的应用纳入管理,但绝不重启它的进程,绝不改任何已有文件,绝不装新软件。
ADP-1 ~ ADP-6:6 步流程
整个 Adopt 过程拆成 6 步,每一步都可以单独中止、不留痕迹。
ADP-1 只读探测
服务端 SSH 上去跑一组白名单只读命令收集 server_inventory:OS / runtime / pm2 进程列表 / nginx vhost / certbot 证书 / 数据库 / 端口占用 / sshd 加固 / cron 任务。.env 文件只算 sha256 不读内容。
cat /etc/os-release
node -v
pm2 jlist
ls /etc/nginx/sites-enabled/
certbot certificates
sha256sum /var/www/blog/.env.productionADP-2 M1-M9 接管映射
针对探测结果问 9 个问题(要接管的应用名 / 根目录 / 启动命令 / nginx vhost / SSL 续签由谁负责 / 数据库连接 / 这台服务器还有什么不要碰 / .env 路径 / cron 接管否)。默认值都从 ADP-1 自动猜,用户只需确认或改。
ADP-3 警告分级
扫到 SSH 弱配置(PermitRootLogin yes / 密码登录 / 无 fail2ban)给 warning,SSL 21 天内到期 给 warning,SSL 7 天内 给 blocking,数据库无 .ailaunch/backups 目录给 blocking。Blocking 必须解决才能继续。
ADP-4 独立签字单 + ICP 主体
7 条法律护栏 + ICP 备案号 + 主体填写 + 输入「我确认接管」。所有勾选状态 + IP + UA + 时间戳进 deploy_signoffs 表 3 年留存。
ADP-5 不破坏式镜像
6 个原子操作:
- 1. mkdir /var/www/.ailaunch/{project_id} 创建影子目录
- 2. cat 用户授权的 .env 文件 → 写入 Vault 引用
- 3. cat /etc/nginx/sites-available/<vhost> → 镜像到影子目录(只读)
- 4. pm2 jlist → 镜像到影子目录(只读)
- 5. tar czf backups/{ts}-before-adopt.tar.gz 应用目录 + 数据库 dump
- 6. 写 ADOPTED 标记文件
我们从不重启你的进程。镜像的 nginx / pm2 配置都是用户原文照搬,不修改 — 哪怕你的配置有错也是你的错,我们不替你做决定。
ADP-6 首次 Update 加强模式
接管完成后,你的第一次 Update 会强制健康窗口 ×2(≥ 60s),Deployment.is_first_update_after_adopt=True 留证。第二次 Update 起进入常规流程。
为什么这么设计?
因为你不会信任一个 30 秒前才认识的工具,让它去 reload nginx 重启你跑了一年的应用。所以我们设计成:接管这件事本身可以让你随时反悔(影子目录可以一键删,什么都没改),只有当你后续主动选 Update 时,我们才开始真正「动」你的服务。
试试看 — Free 层每月 5 次 AI 引导,接管一个 demo 应用刚好够。