生产部署实战
从"我电脑上跑得动"到"团队 24/7 稳定用",差的就是这篇的内容——多实例、持久化、备份、监控、升级、灾难恢复。全程用对话驱动,你只说诉求,龙虾负责生成配置、跑部署、做监控。
谁该读这篇
- 你要把龙虾部署到团队 / 公司环境
- 你要在一台机器上跑多个实例
- 你已经踩过"容器一重启啥都没了"的坑
先读前置
- 通过Claude安装 · 场景 C(多实例安装流程)
- 指挥中枢模式(龙虾决策、外挂执行的边界)
一、生产部署的三个目标
| 目标 | 含义 | 怎么衡量 |
|---|---|---|
| 可用性 | 服务随时能用 | 全年可用率 ≥ 99%(全年宕机不超 87 小时) |
| 可恢复 | 出事能找回数据 | RPO ≤ 1 小时(最多丢 1 小时数据)、RTO ≤ 4 小时(4 小时内恢复) |
| 可观测 | 出事能查清原因 | 日志、监控、告警齐全 |
下面所有具体配置,都是为这三个目标服务。
二、单实例 vs 多实例
单实例(个人 / 小团队)
- 一个 Docker 容器跑 gateway + cli
- 数据持久化到宿主机一个目录
- 够用,但没有冗余——容器挂了所有人都断服
多实例(团队 / 公司)
- 一台宿主机跑 N 个容器(每用户 / 每部门一个)
- 共享一个公共交换路径
- 单个实例挂了不影响其他人
什么时候必须多实例
- 多用户共用、需要权限隔离
- 单实例的对话上下文会串台(A 的对话被 B 看到)
- 单实例负载过高(token 速率限制)
- 不同业务用不同 provider(A 用 GLM,B 用 MiniMax)
三、持久化目录(5 个约束)
这是多实例部署的核心——哪些目录必须挂载到宿主机,对应 通过Claude安装 场景 C 的 5 个约束:
| 约束 | 容器内路径 | 宿主机建议路径 | 作用 |
|---|---|---|---|
| ① 程序目录支持 upgrade | /opt/openclaw | /data/openclaw/〈instance〉/app | 升级时配置不丢 |
| ② 配置/记忆/密钥持久化 | ~/.openclaw | /data/openclaw/〈instance〉/home | onboard 配置、记忆、API key |
| ③ 用户工作空间可读写 | ~/.openclaw/workspace | /data/openclaw/〈instance〉/workspace | 用户文件 |
| ④ 多实例共享交换路径 | /shared | /data/openclaw/shared | 跨实例文件交换 |
| ⑤ 每实例 SMB 隔离 | (由 SMB 服务挂载) | 每实例独立 SMB 账号 | 文件网络访问 |
四、用对话生成完整部署配置
对龙虾说:
帮我在生产环境部署 OpenClaw 多实例。目标机器:〈IP / 系统 / 配置〉
需求:
1. 部署 2 个实例(alice / bob),后面可能扩到 N 个
2. 持久化 5 个目录(参考生产部署文档的 5 个约束)
3. 每实例独立端口(alice 18789,bob 18790)
4. 时区 Asia/Shanghai(重要,否则 cron 跑偏)
5. 共享交换路径 /data/openclaw/shared 所有实例共用
6. 健康检查(HTTP 探活)
7. 日志限制(防止撑爆磁盘)
8. 自动重启(unless-stopped)
请:
1. 生成完整的 docker-compose.yml(alice + bob 两个 service)
2. 每行加注释,说明这行干什么
3. 设计成可扩展结构(加第 3 个实例只需要复制+改 3 处)
4. 生成完展示给我看,让我审一下
5. 审通过后告诉我怎么应用到目标机器
注意:不要立刻执行部署,先生成配置让我审。龙虾会生成的产物
龙虾会贴出类似这样的 docker-compose.yml:
# /data/openclaw/docker-compose.yml
# 多实例部署:以 2 个实例(alice / bob)为例
services:
# 实例 1:alice
openclaw-alice:
image: openclaw:latest
container_name: openclaw-alice
restart: unless-stopped # 总是自动重启,除非手动 stop
# 时区必须设,否则 cron 全跑偏
environment:
- TZ=Asia/Shanghai
- OPENCLAW_INSTANCE_NAME=alice
# 持久化 5 个目录(对应约束 ①②③④)
volumes:
# ① 程序目录(升级时不丢)
- /data/openclaw/alice/app:/opt/openclaw
# ② 配置/记忆/密钥
- /data/openclaw/alice/home:/home/openclaw/.openclaw
# ③ 用户工作空间
- /data/openclaw/alice/workspace:/home/openclaw/.openclaw/workspace
# ④ 共享交换路径(所有实例共用)
- /data/openclaw/shared:/shared
# 时区文件
- /etc/localtime:/etc/localtime:ro
# 端口:每实例独立端口,避免冲突
ports:
- "18789:18789" # alice 的 gateway UI
# 健康检查
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:18789/health"]
interval: 30s
timeout: 5s
retries: 3
start_period: 60s
# 日志限制
logging:
driver: json-file
options:
max-size: "50m"
max-file: "5"
networks:
- openclaw-net
# 实例 2:bob(结构同 alice,端口/路径不同)
openclaw-bob:
# ... 同 alice,改 container_name / volumes 路径 / ports 端口
networks:
openclaw-net:
driver: bridge扩到 N 个实例的规则——龙虾会告诉你复制 service 块,只改 3 处:
container_name→openclaw-〈name〉volumes里的〈name〉路径ports的宿主机端口(递增)
五、备份策略
对话让龙虾设计备份方案
帮我设计一个 OpenClaw 多实例备份方案。
需要备的:
- 每实例的配置 + 记忆(/data/openclaw/〈instance〉/home)
- 每实例的用户工作空间(/data/openclaw/〈instance〉/workspace)
- 共享交换路径(/data/openclaw/shared)
要求:
1. 每天凌晨 3 点自动跑
2. 配置/记忆保留 30 天
3. 工作空间保留 14 天
4. 共享路径保留 8 周
5. 30 天前的备份自动清理
6. 备份完写日志到 /var/log/openclaw-backup.log
请:
1. 生成备份脚本(bash)
2. 告诉我如何加到 crontab
3. 加一个"备份验证"步骤——不只是备,要验证备份能恢复
4. 设计一个"每月灾难恢复演练"的流程备份验证(必须做)
没验证的备份等于没备份
定期(至少每月一次)从备份恢复一个实例到测试机,跑一遍基本功能。备份文件能不能用,跟"有没有备份"是两回事。
让龙虾每天验证备份完整性:
帮我加一个每日备份验证任务:
时间:每天凌晨 4 点(备份完成后 1 小时)
内容:检查昨天的备份:
① tar 包能否正常解压
② 解压后关键文件是否存在(openclaw.json / memory 目录)
③ 抽样还原一个文件,验证内容完整
告警:任一失败立刻通过飞书告警
全部成功:不发消息
这是"备份的备份"——确保备份本身没坏。六、监控和告警
三个必须监控的指标
| 指标 | 阈值 | 告警 |
|---|---|---|
| 容器存活 | healthcheck 连续 3 次失败 | 立刻 |
| 磁盘空间 | /data 使用率 > 85% | 当天 |
| API 错误率 | 5xx 占比 > 5% / 10 分钟 | 立刻 |
用龙虾自己监控龙虾
让一个独立的龙虾实例(不要用被监控的那个)定期检查其他实例:
帮我建一个跨实例健康监控任务:
执行者:openclaw-monitor 实例(独立于被监控实例)
时间:每 5 分钟一次
内容:
1. 检查这些实例的健康接口:
- http://openclaw-alice:18789/health
- http://openclaw-bob:18789/health
2. 任一连续 3 次失败,立刻通过飞书告警 "⚠️ 实例 〈name〉 不可用"
3. 恢复正常也发 "✅ 〈name〉 已恢复"
4. 顺便检查 /data 磁盘空间,使用率超过 85% 时告警
关键:监控实例必须独立于被监控实例,不能用 alice 监控 alice(alice 挂了告警发不出来)。日志聚合
多实例下,分散看日志很痛苦。两种方案(让龙虾帮你选):
我有多个 OpenClaw 实例,日志分散。帮我看一下:
1. 当前每个实例的日志在哪里、大小多少
2. 推荐一个日志聚合方案,两个选项:
- 简单版:所有实例日志聚合到一个目录,用 grep 查
- 正式版:上 Loki / ELK,按 container_name 标签过滤
3. 我的规模是 〈2-10 个实例 / 10+ 个实例〉,你建议哪个七、升级流程
升级前(对话模板)
我想升级 OpenClaw 到最新版。升级前请帮我:
1. 看一下新版本的 changelog,列出 breaking change
2. 跑一次完整备份(参考备份脚本)
3. 给当前镜像打一个版本标签(方便回滚),用今天的日期作为标签名
4. 通知我这次升级预计需要多长停机时间
5. 确认升级窗口(我现在 / 等会儿 / 晚上)
先列计划,不要立刻执行。升级中(滚动升级)
开始升级。用滚动模式:
1. 先升级 openclaw-alice
2. 等 alice 健康检查通过(最多等 5 分钟)
3. alice OK 后再升级 openclaw-bob
4. bob OK 后升级完成
不要一次性升所有实例——如果一个启动失败,全部都炸。
升级过程中实时告诉我进度。升级后(烟雾测试)
升级完成了,做烟雾测试:
1. 对 alice 跑一个基础对话,确认能回复
2. 对 bob 跑一个基础对话,确认能回复
3. 看最近 30 分钟的日志,有没有 ERROR / WARN
4. 观察 token 消耗是否异常(新版本可能漏了 prompt cache)
5. 给我一个"升级是否成功"的判定回滚
升级后发现 bug,要回滚。请:
1. 用之前保留的旧镜像 openclaw: backup-〈日期〉
2. 重新打 latest 标签
3. 一个一个实例重新创建
4. 如果数据 schema 变了(新版本改了 DB 结构),光回滚镜像不够,还要从备份恢复数据——告诉我具体怎么做八、灾难恢复演练
每季度做一次真实恢复演练——让龙虾帮你设计:
帮我设计一个季度的灾难恢复演练流程:
目标:验证我们的备份和恢复流程真的能用
演练内容:
1. 在测试机上从零部署 OpenClaw
2. 从最新备份恢复一个实例(alice)
3. 跑完整的功能测试:
- onboard 能不能跑
- API Key 能不能用
- 渠道接入能不能恢复
- 历史对话能不能读
4. 记录:恢复用了多长实际时间(对照 RTO 4 小时)
5. 记录:备份文件丢失了多少数据(对照 RPO 1 小时)
6. 记录:遇到什么问题、备份是否完整
演练完写一份报告,包括:
- 实际 RTO / RPO vs 目标 RTO / RPO
- 发现的问题清单
- 改进建议
注意:演练在测试机做,不要碰生产。没演练过的恢复流程,不算真的有灾难恢复。
九、下一步
- 部署遇到具体问题:让龙虾帮忙诊断
- 多实例的 cron 任务编排:Cron Cookbook
- 完整的多 agent 业务架构:多 Agent + 外挂协同
