2026 OpenClaw MeshMac — практика для мультиузловой сетки: шаблоны переменных окружения и изолированная инъекция секретов (dev / staging / prod)

Материал рассчитан на платформенных инженеров и владельцев CI, которые держат несколько удалённых Mac как воркеры, шлюзы или смешанные роли в одной сетке OpenClaw. Вам нужна предсказуемая конфигурация и доказуемая история изменений, иначе инцидент на одном узле не воспроизвести на остальных.

Три частых корня проблем:

• Теневые export в SSH. Разработчик экспортировал переменную в интерактивной сессии — она не попала в Git, а на следующем хосте поведение другое.
• Перетекание стенда. Файл с меткой .env скопировали на prod-бокс без смены префикса путей; очередь и webhook начинают бить в staging.
• Провалы аудита. В логах нет template_revision, deployment_id или версии пакета секретов — невозможно доказать, какой именно шаблон крутился на узле во время сбоя.

Общую картину развёртывания на кластере можно согласовать с руководством по мультиузловому развёртыванию OpenClaw MeshMac и с коллаборацией на Mac mesh. Синхронизацию очередей и выката — с материалом о едином развёртывании и очереди задач.

Среда — это не только имя каталога, а политика: где лежат секреты, какой blast radius допустим, как быстро можно менять шаблон и какие токены узкие. Зафиксируйте это в runbook до автоматизации.

В Git храните только несекретные шаблоны и оверлеи; значения ключей — в хранилище секретов или в файлах на узле, которые не коммитятся. Запишите короткий идентификатор ревизии шаблона, чтобы при старте процесса OpenClaw он попадал в структурированный лог.

Пример структуры каталогов:

openclaw-config/
  templates/
    openclaw.env.base.tpl
    overlay.dev.env
    overlay.staging.env
    overlay.prod.env
  nodes/
    worker-01.patch.env
    gateway-01.patch.env

Команды (рабочая станция сопровождения или CI):

cd openclaw-config
git rev-parse --short HEAD > templates/.template_revision

Проверка: файл ревизии непустой и короткий.

test -s templates/.template_revision && wc -c templates/.template_revision

Ожидайте небольшое ненулевое число байт (обычно 6–8 символов плюс перевод строки). Если команда завершилась с ошибкой — вы не в корне репозитория или Git недоступен агенту CI.

Экспортируйте MESH_ENV явно из пайплайна или systemd/LaunchAgent окружения; не выводите среду только из hostname — это источник скрытых ошибок при клонировании дисков и переименовании Mac.

Склейте базовый шаблон и оверлей среды, затем подставьте плейсхолдеры так, чтобы в env попадали пути к файлам секретов, а не сами секреты в открытом виде (если ваш стек это поддерживает — предпочтительно читать значение из файла при старте процесса).

export MESH_ENV=staging
export TEMPLATE_REVISION="$(cat templates/.template_revision)"
cat templates/openclaw.env.base.tpl \
  templates/overlay.${MESH_ENV}.env \
  | envsubst > /tmp/openclaw.${MESH_ENV}.env

Проверка: в срендеренном файле присутствуют ожидаемые маркеры среды и ревизии.

grep -E '^(MESH_ENV|TEMPLATE_REVISION)=' /tmp/openclaw.${MESH_ENV}.env

Для безопасной смены брокера очереди и таймаутов согласуйте окно работ с настройкой очереди и повторов.

На каждом узле заведите отдельный каталог на среду. Режимы по умолчанию: каталог 0750, файлы 0440, владелец root и группа учётной записи сервиса openclaw (замените на фактическую группу у себя). Разделяйте файлы по роли: например webhook_hmac только на ingress-узлах, queue_password — на воркерах очереди.

sudo install -d -o root -g openclaw -m 0750 /etc/openclaw/secrets.d/staging
sudo install -m 0440 -g openclaw ./staging_api_token /etc/openclaw/secrets.d/staging/api_token
sudo chmod o-rwx /etc/openclaw/secrets.d/staging/*

Проверка: пользователь сервиса читает файл, посторонний — нет.

sudo -u openclaw test -r /etc/openclaw/secrets.d/staging/api_token && echo OK_readable
sudo -u nobody test -r /etc/openclaw/secrets.d/staging/api_token 2>/dev/null || echo OK_blocked_for_nobody

Эту модель согласуйте с деталями RBAC и ротации в руководстве по секретам с минимальными правами.

После слияния base + overlay среды добавьте маленький patch по стабильному NODE_ID из инвентаря или по NODE_ROLE. Сюда кладите только отличия: URL локальной очереди, флаги GPU, региональный endpoint — но не новые «тайные хранилища», чтобы не размножать поверхности атаки.

NODE_ID="$(scutil --get ComputerName | tr ' ' '-')"
test -f "templates/nodes/${NODE_ID}.patch.env" && \
  cat "templates/nodes/${NODE_ID}.patch.env" >> /tmp/openclaw.${MESH_ENV}.env

Проверка: идентификатор узла в файле совпадает с инвентарём; сравните отрендеренный env с другим узлом той же роли — отличаются только ожидаемые ключи.

grep '^NODE_ID=' /tmp/openclaw.${MESH_ENV}.env
diff -u /tmp/openclaw.peer-a.env /tmp/openclaw.peer-b.env | head -n 40

Ориентир: если в patch больше примерно двенадцати уникальных ключей, чаще выгоднее ввести новую роль узла в инвентаре, чем разрастать индивидуальные файлы.

Перед копированием env в постоянный путь и перезапуском сервиса докажите полноту ключей: сравните множество имён переменных с эталоном из репозитория (golden-keys.txt), маскируя значения в артефактах CI.

awk -F= '/^[A-Z0-9_]+=/ {print $1"=<redacted>"}' /tmp/openclaw.${MESH_ENV}.env \
  | sort | diff -u golden-keys.txt -

Затем выполните диагностику от пользователя демона (подставьте поддерживаемую вашей сборкой команду):

sudo -u openclaw openclaw doctor --config /tmp/openclaw.${MESH_ENV}.env || true

Проверка: doctor завершается без ошибок отсутствующих обязательных переменных; в логах CI нет строк с длинными токенами — только имена ключей и хеши файлов секретов.

Откат — это не ручная правка на одном Mac, а повторный выкат известной хорошей пары: Git SHA шаблонов + версия пакета секретов (SECRET_BUNDLE_VERSION в метаданных деплоя). Храните предыдущий отрендеренный артефакт в защищённом объектном хранилище или в системе релизов не дольше, чем позволяет политика.

git checkout <known_good_sha> -- templates/
./scripts/render-all.sh staging
sudo cp /tmp/openclaw.staging.env /etc/openclaw/openclaw.env
sudo launchctl kickstart -k system/org.openclaw.worker

(Если используете другой label LaunchDaemon — подставьте свой из runbook.)

Чеклист аудита и эксплуатации

• Каждый деплой пишет в централизованные логи: deployment_id, короткий Git SHA шаблонов, LDAP/GitHub login актора, MESH_ENV, NODE_ID.
• Для каждого скопированного секретного файла фиксируется контрольная сумма или версия из vault; при ротации монотонно увеличивается SECRET_BUNDLE_VERSION.
• Раз в квартал — учения: восстановить staging из шаблона «prod минус один» и засечь время до зелёного health по SLA.
• Break-glass доступ к prod-секретам только с id тикета, который попадает в журнал sudo/MDM или сессии хранилища.
• Срок хранения строк аудита деплоя в системе запросов — не менее 90 дней, если иное не требует регуляторика.

Канареечный выкат шаблонов: сначала один воркер и один шлюз, затем остальная сетка после зелёных смоук-задач — так вы уменьшаете blast radius при ошибке в переменных окружения.