COMPOSE_PROJECT_NAME · 独立数据卷与端口表 · env_file 与容器内 env 对齐核对
在同一台VPS上并行跑两套OpenClaw时，最常见事故是端口占用、默认网络与卷名撞车、以及宿主有 API Key 但容器内 env 为空。本文用单实例基线 vs 多实例最小差异集对照表梳理 COMPOSE_PROJECT_NAME、数据目录与端口表，说明 env_file 与 environment 的注入路径，并给出六步核对清单与回滚单实例条件。可与Docker Compose 生产基线、Exit 137 与起步排障交叉阅读。
复制一份 docker-compose.yml 改几个端口并不等于隔离：默认工程名会让网络与匿名卷继续撞名；宿主 export 不会自动进容器；反代 upstream 仍可能指向旧容器 IP。下列信号出现时，应回到对照表逐项打勾而不是继续加容器。
只改端口不改 COMPOSE_PROJECT_NAME：默认 bridge 网络与内部 DNS 仍可能解析到另一栈的容器名。
数据目录软链接或挂载重叠：两套 ~/.openclaw 或 workspace 实际落在同一块磁盘前缀，升级脚本互相改写。
API Key 只在 shell profile：docker compose up 子进程读不到 compose 期望的 env_file 路径。
healthcheck 过短：第二实例冷启动更慢，被 orchestrator 误判重启并与第一实例抢锁。
反代仍指向 127.0.0.1 旧端口：两套 Gateway 轮换时，边缘层仍把流量打到已停止的实例。对齐方式见反代与 TLS 文。
下列字段是同一宿主机双栈最常见的「最小差异集」。若你只准备开短期试验实例，至少完成工程名、数据目录、宿主机端口、env_file 路径四件事再谈自动化。资源上限与日志轮转仍须遵守生产基线文。
| 字段 | 单实例基线 | 多实例必须拆分 | 常见踩坑 |
|---|---|---|---|
COMPOSE_PROJECT_NAME | 默认目录名 | 每栈唯一短名（如 oc_a / oc_b） | 只改文件夹不改工程名导致匿名卷复用 |
| 数据卷路径 | 单宿主绑定路径 | /srv/openclaw-a 与 /srv/openclaw-b 完全分离 | 子路径软链指向同一上级目录 |
| 宿主机端口 | 单组 3000:3000 | 映射到不同宿主端口并写入端口表文档 | 第二栈启动失败仍被 systemd 拉起抖动 |
| 环境注入 | 单 .env | 每栈 .env.oc-a 并在 compose 显式 env_file | 宿主 export 未写入 compose 解析范围 |
| 健康检查 | 单份 start_period | 冷启动更慢时上调 start_period 与 retries | 双栈同时重启造成 CPU 尖峰 |
工程名与数据目录先于端口宣传；顺序反了会在第一次升级脚本时把两套状态写进同一前缀。
以下步骤假设你已能单机跑通官方或团队的 Compose 片段；目标是让第二栈的配置渲染结果与运行时 env可对照审计。
写入工程名与目录：导出 COMPOSE_PROJECT_NAME，创建独立数据目录并确认无嵌套软链。
固定端口表：为 Gateway、Control UI、附加通道端口分配未占用宿主端口，写入运维表。
拆分 env_file：每栈一份密钥文件路径，避免共用 .env；用 docker compose --project-directory 明确工作目录。
渲染检查：执行 docker compose -f ... config 比对两栈的 networks、volumes 与 ports 是否仍出现同名挂载。
运行时验证：docker compose exec 进入容器打印目标变量，确认与宿主 grep -v 脱敏结果一致。
健康与日志：按基线文设置 start_period 与 json-file 上限，避免双栈同时打满磁盘。
export COMPOSE_PROJECT_NAME=oc_b docker compose --env-file ./.env.oc-b -f docker-compose.yml config > /tmp/oc-b.rendered.yml docker compose --env-file ./.env.oc-b -f docker-compose.yml up -d docker compose --env-file ./.env.oc-b exec -T openclaw-gateway sh -lc 'env | grep -E "ANTHROPIC|OPENAI" | sed "s/=.*/=***MASK***/"'
提示：config 子命令只解析合成结果，不启动容器；先保存渲染 diff 再 up，便于与第一栈对照。
下列条目为值班与复盘起点，请用你们真实 compose 片段与宿主监控替换具体阈值；不得直接宣称为对外 SLA。出现「偶发连错实例」时，至少同时保存两栈的渲染配置、容器 inspect 网络段与反代 upstream 快照。
ss -lntp 或等价命令，输出保存到工单附件。json-file 写入时，inode 与带宽先于 CPU 成为瓶颈；见基线文中的巡检节奏。| 症状 | 优先怀疑字段 | 建议命令或证据 |
|---|---|---|
| 容器内无 API Key | env_file 路径、compose 工作目录 | docker compose config 与 exec env 对照 |
| 健康检查抖动重启 | start_period、CPU steal | 宿主 dmesg / cgroup 统计与容器日志时间线 |
| 请求打到错误实例 | 反代 upstream、旧容器残留 | 反代 reload 前后 docker ps -a 与 upstream 文件 diff |
注意：在未停止第一栈前用同一路径覆盖 .env，会把两栈密钥轮换顺序打乱；永远先复制新文件再切换引用。
在同一台小内存 VPS 上硬塞两套生产级 OpenClaw，往往先输在磁盘与日志而不是算力；若缺少独立数据目录与端口表，排障会退化成「猜连接到哪一个 Gateway」。纯手动改 compose 而不保留渲染 diff，也会让后续升级无法回答「是谁改了哪条环境变量」。
相较之下，需要稳定宿主机、可预期带宽与可隔离工作目录的团队，把 OpenClaw 跑在可订购的云 Mac 或专用 VPS 套餐上更利于执行上述清单；对要把多实例试验与生产隔离放在同一运维故事里的场景，VpsMesh 的 Mac Mini 云端租赁通常是更优解：节点角色可拆分、链路可审计，让 compose 差异集与队列策略同样可验收。
请按正文对照表核对匿名卷、默认网络名、宿主端口与 env_file是否仍与第一栈重叠；仅改目录名不改工程名时最常见。更多 healthcheck 与 restart 细节见Compose 生产基线文。
多半是 compose 未加载正确的 env_file、工作目录不一致、或变量只在 build 段声明；按正文六步用 docker compose config 与 exec 对齐。起步阶段可对照Exit 137 与起步排障文的环境变量段落。