2026: OpenClaw на нескольких узлах clustervps
шаблоны фрагментов, изоляция workflow и канареечный сплит

Ниже — компактный operational HowTo. Базовые соглашения по тенантам и webhook разобраны в статье про фрагменты, doctor и сводку webhook; веса канареечного трафика и multi-AZ — в материале про канареечные доли и skill-пакеты. Шлюзовой контур и health на разных зонах см. в руководстве по multi-AZ шлюзам.

Каталоги конфигурации по тенантам

Зафиксируйте на каждом узле одинаковый каркас: read-only шаблоны базы (общие defaults), затем каталог оверлеев тенанта — например .../tenants/<tenant>/fragments/*.yaml и опционально .../env/<stage>/ для стадии. Итог merge пишите только в /var/lib/openclaw/merged/ рядом с .sha256; редактировать merged вручную запрещено — иначе расходится репозиторий и рантайм.

Изоляция workflow: у каждого тенанта свой префикс очереди, свой набор launchd-лейблов воркеров и отдельный корреляционный префикс в JSONL. Так инцидент на одном пайплайне не маскируется метриками соседа. Слияние выполняйте в временный файл и завершайте атомарным rename, чтобы процесс шлюза никогда не читал «обрезанный» YAML.

Стратегия слияния шаблонов фрагментов

Задайте строгий порядок слоёв: base → tenant → env. Конфликт одинаковых ключей без явного merge-правила в CI — повод для fail, а не «тихого» последнего победителя. Версионируйте скрипт merge и входные шаблоны через versions.lock или digest в артефакте; продвижение конфигурации начинайте только после openclaw validate на собранном файле.

В пайплайне храните не сам merged, а его SHA256 и ссылку на коммит; на узле после успешной проверки хеша выполняйте controlled reload шлюза (см. ниже про границы hot reload). Любая ошибка валидации или несовпадение digest → без переключения LB и без сигнала «healthy» наружу.

Практично завести отдельную ветку templates/ в репозитории инфраструктуры и запретить прямой push в main: только MR с двумя ревью для изменений, влияющих на маршрутизацию или секреты. Для каждого релиза merge-скрипта публикуйте changelog в том же PR, чтобы on-call мог сопоставить регрессию с версией слияния. На стороне узла держите симлинк current → merged-<sha> и переключайте его после успешной пробы — так откат сводится к возврату ссылки на предыдущий digest без копирования больших файлов по сети.

Выбор канареечных узлов и откат

Назначьте один или два Mac с меткой openclaw_canary=true, избегая узлов с единственной копией критичного stateful-сервиса. На балансировщике задайте малый вес (например 5–15 %) на канареечный пул и наблюдайте задержку, долю 5xx и глубину очереди 20–40 минут перед расширением доли.

Откат: если деградация локальна — достаточно обнулить вес канареечного узла и оставить прежний артефакт на остальной сетке. Если проблема в самом merged (семантика маршрутов, несовместимость плагинов) — откатите на предыдущий известный-good SHA256 на всех узлах из одного runbook-коммита, затем снова прогоните составную пробу. Держите рядом команду «заморозить merge» в CI, чтобы не усугубить расследование параллельными выкладками.

Слияние doctor и health-проверок

Наружу отдавайте один маршрут (например /healthz/composite): внутри последовательно выполняются проверки диска, launchd, глубины очереди, исходящего TLS к зависимостям и сводка openclaw doctor --json. Ответ — единый JSON с tenant, az, merged_sha и статусами подсистем; LB и дежурные видят одно состояние, без зоопарка curl.

#!/usr/bin/env bash
set -euo pipefail
/usr/bin/openclaw doctor --tenant "${TENANT}" --json >"/tmp/d.json"
/usr/bin/test "$(/usr/bin/jq -r '.ok' </tmp/d.json)" = "true"
/usr/bin/curl -fsS --max-time 4 "${WEBHOOK_PING_URL}" >/dev/null
/usr/bin/jq -c --arg sha "$(/bin/cat /var/lib/openclaw/merged/.sha256)" \
  '. + {merged_sha:$sha,queue_depth:0}' /tmp/d.json

Границы горячей перезагрузки шлюза (линейка 2026): типичные изменения маршрутов, таймаутов и upstream без смены корневого TLS-контекста и без смены пути к merged-файлу шлюз может подхватить через механизм reload без полного рестарта процесса. Смена bind-адреса/порта, корневого сертификата клиента mTLS, смена корневого пути к артефакту или включение нового listener — трактуйте как канареечный рестарт сервиса на одном узле с последующим расширением, а не как «мгновенный reload всей сетки». Так вы избегаете окна, когда половина узлов читает старый listener, а половина — новый merged.

Минимально воспроизводимый чек-лист (HowTo)

1. Скелет каталогов на двух непродовых Mac и одной канареечной площадке; проверка идентичности путей через diff manifest.
2. Merge в CI: слои base→tenant→env, артефакт + SHA256, падение при конфликте ключей.
3. Канарея: выкладка merged только на узел с меткой, малый вес LB, контроль метрик и doctor.
4. Расширение: поэтапное увеличение доли или пометка следующей группы узлов в runbook.
5. Composite health на всех ролях; убедитесь, что JSON содержит merged_sha для сверки с деплоем.
6. Документируйте, какие поля шлюза у вас в зоне hot reload 2026, а какие требуют рестарта — и приложите это к on-call wiki.

FAQ: коротко

Два тенанта в одном merged? Только если явно разведены префиксы и очереди; иначе разделяйте артефакты.Канарея без LB? Используйте DNS или внутренний split на уровне сервис-меша, но сохраняйте тот же принцип малых долей.Reload «завис»? Считайте это сигналом к рестарту на канарейке и откату доли до разборки.

Если команда выравнивает многоузловой OpenClaw на выделенных Mac, заранее посмотрите публичные тарифы и справочный центр — так проще согласовать ёмкость канареечных площадок и jump-доступ без входа в консоль. Готовы закрепить план в закупке — откройте страницу покупки и главную clustervps.