生产部署实战

从"我电脑上跑得动"到"团队 24/7 稳定用",差的就是这篇的内容——多实例、持久化、备份、监控、升级、灾难恢复。全程用对话驱动,你只说诉求,龙虾负责生成配置、跑部署、做监控。

谁该读这篇

  • 你要把龙虾部署到团队 / 公司环境
  • 你要在一台机器上跑多个实例
  • 你已经踩过"容器一重启啥都没了"的坑

先读前置

一、生产部署的三个目标

目标含义怎么衡量
可用性服务随时能用全年可用率 ≥ 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〉/homeonboard 配置、记忆、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 处:

  1. container_nameopenclaw-〈name〉
  2. volumes 里的 〈name〉 路径
  3. 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
- 发现的问题清单
- 改进建议

注意:演练在测试机做,不要碰生产。

没演练过的恢复流程,不算真的有灾难恢复

九、下一步

正文导航

打开抖音
有问题点击我